[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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 think it is worth adding some text to describe correct behaviour for your case.

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.

Anyway, the inconvenience of doing this may be unavoidable, but I did want to point out that there are reasonable ways the i-default-only case can arise in
practice.