Thanks for the note, Ned. It leads me to two more specific questions:
Does the document need to describe the issues noted below in an
Internationalization Considerations section? It might make sense.
Are there any normative dependencies to existing i18n RFCs or I-Ds? I'm not
so sure.
-Scott-
-----Original Message-----
From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: Thursday, January 19, 2006 12:36 PM
To: Scott Hollenbeck
Cc: ietf-mta-filters(_at_)imc(_dot_)org
Subject: Re: IESG Review of draft-ietf-sieve-vacation
The discuss that has been shared with the document shepherd
is still in
place. I need text from Cyrus (the document shepherd,
coordinated as
appropriate) to resolve that minor issue. Details in the
I-D tracker:
https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=1300
5
Perhaps more importantly, an AD asked about internationalization
considerations. What are the i18n implications of
displaying the fields
specified in the protocol?
As posed the question is next to impossible to answer. The
vacation extension
provides a means of constructing a fairly arbitary email
message, one which can
include, among other things, multipart/alternative objects
containing material
in different languages. "Displaying the fields" therefore
equates to how email
messages in general are displayed, and you could write a
thousand pages on that
particular topic and not even scratch the surface.
Now, as it happens our implementation of vacation sees heavy
use with various
ISPs and enterprises that have serious multilingual support
requirements. So
internationalized use of vacation is something I happen to
have a large amount
of experience with. The main internationalization issue that
actually arises
in practice is given the availability of vacation responses
in multiple
languages, what's the best way to select one to use?
One way to do it is to use out-of-band information, such as a
preferredlanguage
attribute in an LDAP entry associated with the message
originator, to generate
a one-time sieve script containing appropriately selected
text. This only works
when such out-of-band information is available, of course,
and it fails to deal
with the fact that selecting appropriate text also needs to
be able to cope
with things like sending different text to a fellow employee
versus to a total
stranger.
This then argues strongly for handling internationalized text
selection in the
sieve script itself. It is a trivial matter to have a script test the
preferred-language or content-language header field and take action
accordingly. These tests can then be coupled with additional
decision-making
logic as needed to generate an appropriate vacation resonse
(or not, as the
case may be).
GUI interfaces that generate sieve scripts can be used to
hide the complexity
of much of this from end users. Figuring out the right set of
options to
present in a GUI is a nontrivial proposition, but more
because of the need to
send different sorts of responses to different classes of
people than because
of the issues involved in selecting a response in an
appropriate language.
Of course one approach is to simply use
multipart/alternative, as I mentioned
previously. For whatever reason this approach isn't terribly
popular with our
customers. I could speculate at length as to why this is so,
but I don't see
such speculation as relevant to the matter at hand. The key
point here is that
in practice we successully use sieve vacation in very demanding
internationalized environments all the time.
Ned
P.S. A legitimate question to ask is whether or not end users
are actually
prepared to write their messages in multiple languages. AFAIK
we don't see much
of that with US customers - no surprise there - but you'd be
surprised how many
end users take advantage of the capability in countries like Japan.