ietf-mta-filters
[Top] [All Lists]

Re: IESG Review of draft-ietf-sieve-vacation

2006-01-19 12:01:52


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=view_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.

<Prev in Thread] Current Thread [Next in Thread>