Patrik Fältström
2003-11-11 13:30:03 UTC
Here are the preliminary minutes. Thanks to Chris Newman for being a
scribe.
If anyone have comments, let me know asap. I intend to publish these at
the end of this week.
Regards, paf
Internationalized Email Addresses BOF Minutes IETF 58, 2003-11-10.
Chairs: Pete Resnick, Patrick Faltstrom
Minute taker: Chris Newman
Agenda Bash: Dave Crocker and Paul Hoffman presentations added.
Paul Hoffman presentation, draft-hoffman-imaa-03.txt
See proceedings (or jabber logs) for Paul's Presentation, highlights of
comments below:
Has been out for a month. Author believes this draft is near complete.
Author
knows of working prototype and one "real" implementation.
Problem with left-hand-side delimiters (e.g. for sub-addresses), have
three
choices of solution (details in presentation). One choice is in the
draft, but
author could do any of the three choices.
John Klensin presentation, draft-klensin-emailaddr-i18n-01.txt
See proceedings (or jabber logs) for John's Presentation.
Clarification Questions: (none)
Paul Hoffman - Thoughts on ESMTP-protected internationalizing of email
See proceedings (or jabber logs) for Paul's Presentation.
Clarification Questions: (none)
Dave Crocker presentation - Structure and Scope of Internet Mail
Addresses
See proceedings (or jabber logs) for Dave's Presentation.
Clarification Questions: (none)
Pete Resnick: clarification comment. Dave's presentation assumes that
this
discussion is about how to internationalize the local part. That may
not be
what we decide is the right bite to take.
Keith Moore comment (paraphrased): The local part is not globally
opaque, it is
only opaque to transport.
Michel Suignard - IRI and IEA, draft-duerst-iri-05.txt
See proceedings (or jabber logs) for Michel's Presentation.
Ted Hardy clarification issue: IRI is a new protocol element syntax.
Not
allowed in existing protocol elements. Are we trying to change the
syntax of
an existing protocol element, or are we trying to create a new protocol
element? This question is critical and a lot harder than it looks.
Open Discussion
Do we want to just solve the problem for local part, or do something
grander?
John's draft chooses the latter, but is not a complete specification.
Nothing
we do is going to take a couple months -- three years at best after we
agree on
an approach.
Keith Moore: Don't think it's acceptable to have a solution that only
people
who don't correspond with other languages can use the new syntax. May
have to
vary on a per-recipient basis. Email addresses aren't just used by
email
(e.g., authentication protocols). An analysis of just email protocols
may not
be adequate. Keith doesn't buy the deployment arguments in John's
document.
Question: is matching of people's names similar enough that we can use
the same
solution? People's names may be a worse problem.
Steve Bellovin: Another requirement from security area: S/MIME for email
requires an IA5 string with an email address with an exact match. This
causes
issues with PKIX and S/MIME WGs.
Michael Mealling: We are exposing protocol elements as user interface.
Should
we create protocol features to translate between protocol elements and
user
interface.
Pete Resnick: We have conflated the two for many years, not a clean
break.
Dave Crocker: Believe we have agreement that we want to move towards
Unicode
characters for email addresses. Given this agreement we can then work
on
syntax issues.
Pete Resnick: Is this limited only to email addresses.
Larry Masinter: Used to think that URLs could be protocol element only
and
translated or looked up, but IRI strategy assumes that won't happen.
Perhaps
white pages directory would work for email addresses, however.
Jeff Hutzelman: If we require a "new format MTA" to translate to "old
format
MTA" then some of them will not do it in the real world. Some MTAs
claim to
support 8BITMIME and fail to down-convert or bounce it in violation of
spec and
refuse to change this behavior.
John Klensin: We have to accept that some things are not going to work
with
un-upgraded systems. We can do this cleanly or uncleanly.
Nico Williams: People will want to use i18n addresses. But with
business
cards, there will be secondary addresses in non-internationalized form.
John Klensin: Would be nice if secondary address on business card is
readable.
Marshall Rose: Request to poll the room to see if this is a research
problem or
engineering problem.
Nico Williams: If people are going to have two forms of email address
and one
is not going to be an ACE-encoding, then S/MIME encoding issues come up
(attributes for both).
Ienup Sung: Email addresses are already cryptic in non-English
countries.
Don't necessarily have glyphs for all Unicode characters, but may still
have
cut&paste problem.
Paul Hoffman: When we started on IMAA, we looked at a very narrow
protocol
problem. John's document moves from just left hand to full email
address. But
people are waiting for us to fix a bigger problem. But why don't we
just go to
UTF-8 headers altogether. Perhaps have "new headers" vs. "old
headers". This
would solve a lot of people's problems. With IMAA we can have 3
encodings in
the From header. Well worth it to make the headers a single sane piece
of text.
John Klensin: Doing all of UTF-8 might be better than ASCII sometimes
and
encodings sometimes.
Keith Moore: We may not want two similar formats, one UTF-8, one not.
But we
may want to redesign MIME and RFC 822 so the new format is very
different.
Nathanial Borenstein: Spam issue also drives a desire to change to a new
system. But we have to be careful because our user community can't
wait ten
years. We may need to do both: a quick hack, and a redesign.
Dave Crocker: If we talk about using bits that are illegal or making
changes to
MTA, then we talk about replacing the email infrastructure with a new
one. If
we talk about encoding, then we're not talking about breaking things.
The
point about timeliness is more significant than we believe. But it
could take
15 years. We need to do something that is near term 3-5 years. Debate
of
ugliness is important but different.
John Klensin: If it's a negotiated option, then it's not breaking the
infrastructure. It's a transition strategy.
Pete Resnick: 8BITMIME spec says you can downgrade or bounce. At
beginning
people bounced, then people downgraded. Most people now do 8BITMIME.
People
who can't deal with it get reasonably downgraded stuff. And it's about
ten
years.
Dave Crocker: Breakage comes in different forms.
Nico: If we know users will have two names on business cards, that may
determine which of three choices Paul mentioned that we should take.
Keith Moore: We don't understand the problem yet. We need to continue
the
discussions.
Ted Hardy: Nathanial had concrete suggestion: 1. quick hack and 2. long
term
upgrade. We should poll the room to see which have energy.
Ienup Sung: We may not have the right sample of Internet users to
address the
problem properly.
Straw Polls:
Lots of people have read at least one of the drafts.
How many people are willing to work on ASCII encoding of addresses?
About 1
dozen.
How many people willing to work on a grander proposal -- transport
related,
actually changing mail transport? About 15.
Continuing Discussion:
Observation: There are points in between.
Does the grander proposal belong in the IETF or IRTF?
John Klensin suggests it is a reasonably understood problem. A hard
problem
with many details, but it is an engineering problem.
Nico Williams: If we have both romanized and pretty forms, perhaps have
MTA
headers use romanized names and pretty forms in new headers and S/MIME.
Chair: that issue is out-of-bounds at the moment, but is an approach
that can
be talked about.
Nico Williams: We need to research if two name forms are what users are
going
to do.
Chair: move this to list, after reading documents.
Nathaniel Borenstein: Email protocols are over 30 years old and have
lots of
cruft. Strongly supports either extreme, but not the middle. John's
proposal
may be an undesirable middle ground that changes too much to be a hack,
but not
enough to be a revolution.
Chair: If we did the grand start all over, should we do it in IETF?
Nathanial Borenstein: Would prefer to see the hack in the IETF and the
grand
plan in the IRTF.
Jeffry Altman: Many organizations already provide users with random
name forms
and presentation name forms for the same mailbox. On subject of hack
and
long-term proposal: if we have both, people will never migrate to the
long-term
proposal. And therefore we should not do the hack.
Dave Crocker: John Klensin has a well understood goal. But the rest of
us may
not have an equally clear sense of the goal, as demonstrated by desire
to
expand the goal. Cost benefit analysis is worth pursing.
Keith Moore: Don't think we can abandon the near term issue due to
danger of
second system syndrome.
Leslie Daigle: Beware of local minimum analysis for email only. Other
identifier addresses have modeled themselves on email addresses (e.g.,
SIP
addresses). Need to take this into account in cost-benefit analysis
Mark Crispin: We face a fairly stark choice. Is preserving existing
facility
highest goal? Or is the idealized possibility for i18n the overriding
goal?
Can't be reconciled. Perhaps either extreme is better than the middle.
Let's
make a decision. Pick one extreme or another, do not try to do
something in
the middle.
Keith Moore: Convinced there are middle-term solutions better than
either
extreme and we haven't explored that space enough.
scribe.
If anyone have comments, let me know asap. I intend to publish these at
the end of this week.
Regards, paf
Internationalized Email Addresses BOF Minutes IETF 58, 2003-11-10.
Chairs: Pete Resnick, Patrick Faltstrom
Minute taker: Chris Newman
Agenda Bash: Dave Crocker and Paul Hoffman presentations added.
Paul Hoffman presentation, draft-hoffman-imaa-03.txt
See proceedings (or jabber logs) for Paul's Presentation, highlights of
comments below:
Has been out for a month. Author believes this draft is near complete.
Author
knows of working prototype and one "real" implementation.
Problem with left-hand-side delimiters (e.g. for sub-addresses), have
three
choices of solution (details in presentation). One choice is in the
draft, but
author could do any of the three choices.
John Klensin presentation, draft-klensin-emailaddr-i18n-01.txt
See proceedings (or jabber logs) for John's Presentation.
Clarification Questions: (none)
Paul Hoffman - Thoughts on ESMTP-protected internationalizing of email
See proceedings (or jabber logs) for Paul's Presentation.
Clarification Questions: (none)
Dave Crocker presentation - Structure and Scope of Internet Mail
Addresses
See proceedings (or jabber logs) for Dave's Presentation.
Clarification Questions: (none)
Pete Resnick: clarification comment. Dave's presentation assumes that
this
discussion is about how to internationalize the local part. That may
not be
what we decide is the right bite to take.
Keith Moore comment (paraphrased): The local part is not globally
opaque, it is
only opaque to transport.
Michel Suignard - IRI and IEA, draft-duerst-iri-05.txt
See proceedings (or jabber logs) for Michel's Presentation.
Ted Hardy clarification issue: IRI is a new protocol element syntax.
Not
allowed in existing protocol elements. Are we trying to change the
syntax of
an existing protocol element, or are we trying to create a new protocol
element? This question is critical and a lot harder than it looks.
Open Discussion
Do we want to just solve the problem for local part, or do something
grander?
John's draft chooses the latter, but is not a complete specification.
Nothing
we do is going to take a couple months -- three years at best after we
agree on
an approach.
Keith Moore: Don't think it's acceptable to have a solution that only
people
who don't correspond with other languages can use the new syntax. May
have to
vary on a per-recipient basis. Email addresses aren't just used by
(e.g., authentication protocols). An analysis of just email protocols
may not
be adequate. Keith doesn't buy the deployment arguments in John's
document.
Question: is matching of people's names similar enough that we can use
the same
solution? People's names may be a worse problem.
Steve Bellovin: Another requirement from security area: S/MIME for email
requires an IA5 string with an email address with an exact match. This
causes
issues with PKIX and S/MIME WGs.
Michael Mealling: We are exposing protocol elements as user interface.
Should
we create protocol features to translate between protocol elements and
user
interface.
Pete Resnick: We have conflated the two for many years, not a clean
break.
Dave Crocker: Believe we have agreement that we want to move towards
Unicode
characters for email addresses. Given this agreement we can then work
on
syntax issues.
Pete Resnick: Is this limited only to email addresses.
Larry Masinter: Used to think that URLs could be protocol element only
and
translated or looked up, but IRI strategy assumes that won't happen.
Perhaps
white pages directory would work for email addresses, however.
Jeff Hutzelman: If we require a "new format MTA" to translate to "old
format
MTA" then some of them will not do it in the real world. Some MTAs
claim to
support 8BITMIME and fail to down-convert or bounce it in violation of
spec and
refuse to change this behavior.
John Klensin: We have to accept that some things are not going to work
with
un-upgraded systems. We can do this cleanly or uncleanly.
Nico Williams: People will want to use i18n addresses. But with
business
cards, there will be secondary addresses in non-internationalized form.
John Klensin: Would be nice if secondary address on business card is
readable.
Marshall Rose: Request to poll the room to see if this is a research
problem or
engineering problem.
Nico Williams: If people are going to have two forms of email address
and one
is not going to be an ACE-encoding, then S/MIME encoding issues come up
(attributes for both).
Ienup Sung: Email addresses are already cryptic in non-English
countries.
Don't necessarily have glyphs for all Unicode characters, but may still
have
cut&paste problem.
Paul Hoffman: When we started on IMAA, we looked at a very narrow
protocol
problem. John's document moves from just left hand to full email
address. But
people are waiting for us to fix a bigger problem. But why don't we
just go to
UTF-8 headers altogether. Perhaps have "new headers" vs. "old
headers". This
would solve a lot of people's problems. With IMAA we can have 3
encodings in
the From header. Well worth it to make the headers a single sane piece
of text.
John Klensin: Doing all of UTF-8 might be better than ASCII sometimes
and
encodings sometimes.
Keith Moore: We may not want two similar formats, one UTF-8, one not.
But we
may want to redesign MIME and RFC 822 so the new format is very
different.
Nathanial Borenstein: Spam issue also drives a desire to change to a new
system. But we have to be careful because our user community can't
wait ten
years. We may need to do both: a quick hack, and a redesign.
Dave Crocker: If we talk about using bits that are illegal or making
changes to
MTA, then we talk about replacing the email infrastructure with a new
one. If
we talk about encoding, then we're not talking about breaking things.
The
point about timeliness is more significant than we believe. But it
could take
15 years. We need to do something that is near term 3-5 years. Debate
of
ugliness is important but different.
John Klensin: If it's a negotiated option, then it's not breaking the
infrastructure. It's a transition strategy.
Pete Resnick: 8BITMIME spec says you can downgrade or bounce. At
beginning
people bounced, then people downgraded. Most people now do 8BITMIME.
People
who can't deal with it get reasonably downgraded stuff. And it's about
ten
years.
Dave Crocker: Breakage comes in different forms.
Nico: If we know users will have two names on business cards, that may
determine which of three choices Paul mentioned that we should take.
Keith Moore: We don't understand the problem yet. We need to continue
the
discussions.
Ted Hardy: Nathanial had concrete suggestion: 1. quick hack and 2. long
term
upgrade. We should poll the room to see which have energy.
Ienup Sung: We may not have the right sample of Internet users to
address the
problem properly.
Straw Polls:
Lots of people have read at least one of the drafts.
How many people are willing to work on ASCII encoding of addresses?
About 1
dozen.
How many people willing to work on a grander proposal -- transport
related,
actually changing mail transport? About 15.
Continuing Discussion:
Observation: There are points in between.
Does the grander proposal belong in the IETF or IRTF?
John Klensin suggests it is a reasonably understood problem. A hard
problem
with many details, but it is an engineering problem.
Nico Williams: If we have both romanized and pretty forms, perhaps have
MTA
headers use romanized names and pretty forms in new headers and S/MIME.
Chair: that issue is out-of-bounds at the moment, but is an approach
that can
be talked about.
Nico Williams: We need to research if two name forms are what users are
going
to do.
Chair: move this to list, after reading documents.
Nathaniel Borenstein: Email protocols are over 30 years old and have
lots of
cruft. Strongly supports either extreme, but not the middle. John's
proposal
may be an undesirable middle ground that changes too much to be a hack,
but not
enough to be a revolution.
Chair: If we did the grand start all over, should we do it in IETF?
Nathanial Borenstein: Would prefer to see the hack in the IETF and the
grand
plan in the IRTF.
Jeffry Altman: Many organizations already provide users with random
name forms
and presentation name forms for the same mailbox. On subject of hack
and
long-term proposal: if we have both, people will never migrate to the
long-term
proposal. And therefore we should not do the hack.
Dave Crocker: John Klensin has a well understood goal. But the rest of
us may
not have an equally clear sense of the goal, as demonstrated by desire
to
expand the goal. Cost benefit analysis is worth pursing.
Keith Moore: Don't think we can abandon the near term issue due to
danger of
second system syndrome.
Leslie Daigle: Beware of local minimum analysis for email only. Other
identifier addresses have modeled themselves on email addresses (e.g.,
SIP
addresses). Need to take this into account in cost-benefit analysis
Mark Crispin: We face a fairly stark choice. Is preserving existing
facility
highest goal? Or is the idealized possibility for i18n the overriding
goal?
Can't be reconciled. Perhaps either extreme is better than the middle.
Let's
make a decision. Pick one extreme or another, do not try to do
something in
the middle.
Keith Moore: Convinced there are middle-term solutions better than
either
extreme and we haven't explored that space enough.