Re: Tim Polk's DISCUSS on draft-ietf-imapext-i18n-15.txt

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> Ned Freed wrote:

> >> > Now, if this corner case does exist the cleanest solution would be to
> >> > have two separate responses.
> >
> >> Right.
> >
> >> > But that might break existing implementations.
> >
> >> Indeed.
> >
> >> After reading all responses on this subject I still tend to think that
> >> Tim's proposal is the best one: I can't see any good reason why a server
> >> would implement LANGUAGE command and only support i-default, as this is
> >> pointless.
> >
> > Hmm. Well, the one possibility that occurs to me os that quite a lot of
> > software implements i18n support by having a separate
> > directory/file/container
> > for each supported language. That way new languages can be added or
> > removed on
> > the fly. And when a given language is requested a check is made to see if
> > there's a corrresponding directory/file/container for it.
> >
> > This makes it fairly easy to end up in a situation where the only
> > directory/file/container is the i-default one - in fact the usual way
> > this
> > works is i-default is the built-in default that doesn't have a
> > directory/file/container associated with it, so this corresponds to
> > the fairly
> > common "I deleted all those nasty i18n files in order to save  space"
> > behavior.

> Ok, so you are talking about misconfiguration case, while I was thinking
> about implementing LANGUAGE without implementing any languages case.

I realize with all the attention i18n gets in the IETF it's likely to be
considered an aberrant attitude, but there are plenty of cases where people
don't want any i18n support on their systems. So I wouldn't call it
misconfiguration per se.

> I think it is worth adding some text to describe correct behaviour for
> your case.

IMO that's an acceptable way to handle it. Of course one way to deal with it
would be to hard code one additionaal language code other than i-default for
whatever the built in language support is.

> > This requirement would force such an implementation to check and see
> > whether or
> > not non-i-default material is available before even offering the
> > extension. (Or
> > you can have a extension enable/disable configuration variable, but of
> > course
> > this can lead to a silly state.)

> Yes. This is similar to STARTTLS, which shouldn't be advertised unless
> server can create a TLS context.

Exactly, and unfortunately what we've seen in practice is plenty of server
implementations that do not check this and offer STARTTLS even when they don't
have the necessary certificate(s) installed. This effectively killed
opportunistic use of TLS in SMTP back when it was first standardized -  we had
to advise all our customers not to enable "use TLS if available" mode on
Internet-facing relay clients because it blocked message tranfer in too many
cases. Overall email security didn't exactly benefit from this...

Now, of course this odd corner case isn't remotely as important as the lost
opportunity to encrypt a significant fraction of email on the wire, But it
still needs to be dealt with.

				Ned