[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.
> But that might break existing implementations.
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
Hmm. Well, the one possibility that occurs to me os that quite a lot of
software implements i18n support by having a separate
for each supported language. That way new languages can be added or
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
works is i-default is the built-in default that doesn't have a
directory/file/container associated with it, so this corresponds to
common "I deleted all those nasty i18n files in order to save space"
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
This requirement would force such an implementation to check and see
not non-i-default material is available before even offering the
you can have a extension enable/disable configuration variable, but of
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
point out that there are reasonable ways the i-default-only case can