[Top] [All Lists]

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

2006-01-19 12:03:45

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.


-----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:

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 
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

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


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>