Well, since I won't be able (most likely -- I have a class to give
the day before on Kerberos) to go to Copenhagen, here are my two
cents worth (or 2 croner) in advance:
| 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.
I disagree. X/Open, the X Consortium, several vendors, and a few
other groups have chosen ISO 8859-1 as their default character set.
While this is a bit chauvanistic for Western Europe and the Americas,
that accommodates most of the World's electronic mail (for the
moment).
Further, because 8859-1 is a subset of ISO 10646 (or will be when
it is approved), it provides an easy transition path to a broader
encoding scheme. If one simply defines G/P/R as 32/32/32, and
Compaction Mode 1 as the default for our profile, then we are
inherently ISO 10646 compatible.
| 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.
And we have done well to avoid doing so. National registries are
recognized by both ECMA and ISO. I believe that any country wanting
to register its character set may do so, though the advantages for
aligning itself with an existing standard are obvious (ie. why would
Spain chose not to use the same character set as Portugal, if it
meets their needs?). An exception to this may be China/Taiwan,
given that (a) the character sets are large and complex and (b) they
seem unwilling to cooperate on the issue without outside help or
motivation.
It is easier to say we will align ourselves with 10646 (for example)
and then let that standard dictate the profiles.
| 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.
Hmm. Having characters overlap in multiple sets presents a real
headache for collation, name/directory service, spelling checkers,
etc. I would avoid such a situation like the plague.
| 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.
Why make it more complicated than it needs to be?
| 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.
Well, having an IETF representative (or more correctly, an observer)
at the ISO meetings would be useful. Not that I am volunteering to
be him...
| 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.
As I said, unlikely, but will try to be there.
-Philip
P.S. Sorry for the delay in responding. I have too many courses
this year and not enough time to prepare for them. Thursday
I give a course on Multimedia, and I haven't started my
slides yet...