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

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 19 Jan 2006 12:00:23 -0500

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?

-Scott-

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 19 Jan 2006 13:46:00 -0500

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:[email-masked]] 
> Sent: Thursday, January 19, 2006 12:36 PM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: Re: IESG Review of draft-ietf-sieve-vacation
> 
> 
> 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.
>

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Jan 2006 09:36:24 -0800 (PST)

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

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 24 Jan 2006 19:46:39 -0500

Hi Scott,

> Internationalization Considerations section?  It might make sense.

My feeling is that what Ned described would be better off being put in the 
base spec revision rather than vacation, since its is applicable to base 
spec actions and other extensions too. i.e. we don't need to add this 
directly to vacation itself.

What do others on the list think?

-- 
Cyrus Daboo

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 24 Jan 2006 20:40:13 -0500

> From: Cyrus Daboo [mailto:[email-masked]] 
> Sent: Tuesday, January 24, 2006 7:47 PM
> To: Scott Hollenbeck; 'Ned Freed'
> Subject: RE: IESG Review of draft-ietf-sieve-vacation
> 
> Hi Scott,
> 
> My feeling is that what Ned described would be better off 
> being put in the base spec revision rather than vacation, 
> since its is applicable to base spec actions and other 
> extensions too. i.e. we don't need to add this directly to 
> vacation itself.
> 

That seems like a reasonable approach.  If others agree, can it be captured
as an issue to be addressed?

-Scott-