Subject: [EAI] IESG evaluation record for -framework

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Feb 2007 10:06:10 +0100

Just for your information, here is the current state of play wrt the 
-framework document.
I am replying to the two outstanding DISCUSSes.

                     Harald

To: Internet Engineering Steering Group <[email-masked]>
From: IESG Secretary <[email-masked]>
Reply-To: IESG Secretary <[email-masked]>
Subject: Evaluation: draft-ietf-eai-framework-05.txt to Informational RFC 
--------

Evaluation for draft-ietf-eai-framework-05.txt can be found at 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14701&rfc_flag=0 

Last Call to expire on: 2007-01-26

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Jari Arkko           [   ]     [   ]     [ X ]     [   ]
Ross Callon          [   ]     [ X ]     [   ]     [   ]
Brian Carpenter      [   ]     [ X ]     [   ]     [   ]
Lisa Dusseault       [   ]     [   ]     [   ]     [   ]
Lars Eggert          [   ]     [   ]     [ X ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ted Hardie           [ X ]     [   ]     [   ]     [   ]
Sam Hartman          [ X ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [ X ]     [ . ]     [   ]
Cullen Jennings      [   ]     [ X ]     [   ]     [   ]
David Kessens        [   ]     [   ]     [ . ]     [ X ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Dan Romascanu        [   ]     [ X ]     [   ]     [   ]
Mark Townsley        [   ]     [   ]     [   ]     [   ]
Magnus Westerlund    [   ]     [ X ]     [   ]     [   ]

"Yes" or "No-Objection" positions from 2/3 of non-recused ADs, 
with no "Discuss" positions, are needed for approval.

DISCUSSES AND COMMENTS:
======================
Jari Arkko:

Discuss [2007-02-08]:
I believe this is important work and long overdue.
I do have a question abou the server downgrade
behaviour, however:

> Since the final delivery SMTP server (or, to be more specific, its
> corresponding mail storage agent) cannot safely assume that agents
> accessing email storage will always be capable of handling the
> extensions proposed here, it MAY either downgrade internationalized
> emails or specially identify messages that utilize these extensions,
> or both.  If this done, the final delivery SMTP server SHOULD include
> a mechanism to preserve or recover the original internationalized
> forms without information loss to support access by UTF8SMTP-aware
> agents.

Does this suggest that the final server downgrades mails
without knowing that the client is uncapable of reading
them in the internationalized form? This seems surprising.
Can you elaborate why? And what is the identification mechanism,
and how does it affect POP/IMAP access to the messages?

Comment [2007-02-08]:
> US-ASCII character repertoire, use of punycode on the right hand

The term Punycode is used here without reference or definition.

Brian Carpenter:

Comment [2007-02-02]:
Some changes expected following Gen-ART review at
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-eai-framework-04-sparks.txt

[anchor...] notes need to be removed

Lars Eggert:

Discuss [2007-02-05]:
Section 6.5., paragraph 1:
>    [[anchor16: WGLC, "Framework 7": This section tentatively added to
>    keep track of the relevant text.  There may not be consensus for it
>    in this form (or at all).]]

  DISCUSS: I didn't expect such a comment in a document that makes it to
  the IESG. Is there consensus and the anchor should be removed, or is
  there still no consensus?

Section 6.6., paragraph 1:
>    [[anchor18: WGLC, "Framework 3": This section tentatively added to
>    keep track of the relevant text.  There may not be consensus for it
>    in this form (or at all).]]

  DISCUSS: Same issue as above.

Comment [2007-02-05]:
  Contains a bunch of other comments ("[[anchorX...]]") that should
  probably be removed.

Sam Hartman:

Comment [2007-02-08]:
me too on removing the anchors.  Besides that a really solid document.

Strong disagreement with most of David's discuss, especially the parts
that refer to the abstract.

Russ Housley:

Comment [2007-02-06]:

  I agree with Lars, the various [anchorX...] notes need to be resolved
  before IESG approval.  I'll let Lars hold the DISCUSS position on this
  point.

  Section 11 should be deleted before publication as an RFC.

Cullen Jennings:

Comment [2007-02-08]:
In section 9 it says that this work "must not leave the Internet less secure
than it is". I worry that this is too strong - I think this work inherently will
make the internet slightly less secure due to the homograph issues discussed.
However, I think that is a trade off worth making. I would hate to see the later
protocol documents held up because of this text.

David Kessens:

Comment [2007-02-09]:
>From a procedural point, I am quite unhappy that this draft changed in the
middle of the telechat review period. We specifically discourage this as it
causes us to have to do a review twice. It would have been more appropriate to
remove the defer review of this document to a telechat where it was actually
ready.

In '1.  Introduction':

 Without the extensions specified in this document, the mailbox name is
 restricted to a subset of 7-bit ASCII [RFC2821].

And this is probably a good thing as far as me concerned (note that my 
native language includes characters that cannot be represented in 7-bit 
ASCII)

In section '1.2.  Problem statement':

 If the names and initials used in email addresses can be
 expressed in the native languages and writing systems of the users,
 the Internet will be perceived as more natural, especially by those
 whose native language is not written in a subset of a Roman-derived
 script.

In addition, the use of internationaled email addresses will serve to
fragmentize the 
email name address namespace, thereby fragmenting and isolating people by
making it harder to communicate with people that use different 
charactersets and thus undermining the usefulness of email.

In section '7.  Experimental Targets':

 un-upgraded 

I cannot wait to see what kind of word the RFC editor is going to use 
instead of this one ;-).

------

Please see below for the original text of my DISCUSS:

Most people are probably aware that I am not a big fan of this effort.

However, this was unfortunately chartered as I seem to be the only AD with this
position. As such I don't believe that I can
stop this work. However, I do feel that there are inaccuracies that
need to be fixed. After that has been fixed, I will change my position to an
ABSTAIN.

In 'Abstract:':

Full use of electronic mail throughout the world requires that people
be able to use their own names, written correctly in their own
languages and scripts, as mailbox names in email addresses. 

There is absolutely no requirement to use peoples
own name to be able to fully use email. In fact, there is and
has been a long tradition to use something else than one's own name and
there are countries who use other scripts but have had no difficulties
at all to use email.

In section '4.3.  Downgrading Mechanism for Backward Compatibility'

and the selection
of potential intermediate relays is under the control of the
administration of the final delivery server.

This seems a rather optimistic assumption.

The first of these two options, that of rejecting or returning the
message to the sender MAY always be chosen.

This is a completely unacceptable approach: emails that conform to the

spec should be delivered. emails success is based on the fact that
it is an extremely robust service and delivery is almost guaranteed.
Therefore, some form of backwards compatibility will be required,
rejecting or returning messages doesn't follow that approach.

In section '9.  Security Considerations':

It should be noted that
one of the proposed fixes for, e.g., domain names in URLs, does not
work for email local parts since they are case-sensitive. 

This text is ambiguous. It is not clear what the 'they' refers to.
(and it might need more work as both domain names and local parts
are case-insensitive as far as I know - please correct me if I am wrong!)

The requirements and mechanisms documented in this set
of specifications do not, in general, raise any new security issues.

This is factually incorrect as explained in this section itself.
Internationalization has issues for domains, and it will introduce
the same issues for email while this was previously not a problem.

Dan Romascanu:

Comment [2007-02-07]:
I support Lars' DISCUSS concerning the need to remove the [anchor ...] comments
prior to IESG approval.

^L 
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>,
    RFC Editor <[email-masked]>, 
    eai mailing list <[email-masked]>, 
    eai chair <[email-masked]>
Subject: Document Action: 'Overview and Framework for 
         Internationalized Email' to Informational RFC 

The IESG has approved the following document:

- 'Overview and Framework for Internationalized Email '
   <draft-ietf-eai-framework-04.txt> as an Informational RFC

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

The IESG contact persons are Ted Hardie and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-04.txt

Technical Summary

  Full use of electronic mail throughout the world requires that people
  be able to use 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 discussion of key assumptions and issues
  in deploying fully internationalized email.

Working Group Summary

 The decision to not provide any means of "automatic
  encapsulation" of UTF-8 email addresses, but instead insist
  that the sender specify an alternate address for downgrading 
  purposes was controversial, but was definitely the decision of 
  the working group.

Document Quality

   This document is not subject to independent implementation,
   but the Chairs believe that it will be a useful tool in producing
   further specifications and guiding subsequent efforts. The Document 
   Shepherd is Harald Alvestrand. The responsible AD is Ted Hardie.Note to
RFC Editor
 
 (Insert note to RFC Editor here)

IESG Note

 (Insert IESG Note here)

IANA Note

 (Insert IANA Note here)

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima