Folks,
Below is the tentative agenda for the Internet Mail extensions working
group meeting to be held June 21 in conjunction with the INET 91
conference in Coppenhagen. Logistical details for this meeting will
be distributed as soon as they are available (Exact time and location).
This meeting will address two meta-issues. 1) Selecting character
set(s) for use in the Internet, and 2) The nature of "local enclaves"
of users. These issues do not cleanly fit into the work of either of
the two mailing list, but do impact the work of both. It is for this
reason that this note has been cross posted.
1) Character Set issues
1) Pick one or more than one?
There is a compelling reason to designate a "common" or
"preferred" character set for Internet use. Unfortunatly no clear
candidate has emerged. How to maximize interoperation is the
focus of this discussion.
2) If multiple character sets, define a mechanism for profiling
particular sets for particular communities.
The IETF traditionally has written protocols which do not
require information external to the specification to
interoperate. If an external mechanism is needed, it needs to
be well defined.
2) Enclave Issues
1) Transport conversion, Character set/ information conversion.
Two types of Email conversion have been discussed in one or
more of the discussion lists, including transport encodings
between mixed transport environments, and character sets
between groups of users who have chosen different "local"
character sets. The need for such conversions, and the relm
for which they should be used needs to be discussed, and if
necessary, an effort to engineer solutions needs to begin.
2) How should enclaves be defined? How can borders be enforced?
If enclaves of users are to be formalized, where an enclave
may share a "profile", the boundaries and identification
mechanism needs to be defined, whether this includes static
configuration, negotiation, or DNS lookup.
If there are additional topics that need discussing, please let me
know and I will revise this agenda. These two agenda topics were
chosen in part to solicit the input of participants who have a strong
ideas about possible solutions to these problems, and may be unable to
travel to an IETF Plenary meeting.
For people who will be unable to attend this meeting, please send
proposals or positions to the list before the meeting. Any ideas
circulated will be discussed at the meeting. Minutes will be prepared
from this meeting and distributed to the IETF-SMTP mailing list.
Greg Vaudreuil