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

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> > In particular, I don't see a way for the LANGUAGE command with an argument
> > to return the available language list.

> You are correct regarding LANGUAGE responses in response to various
> forms of the LANGUAGE command. However the LANGUAGE response is an
> untagged response and in theory can be returned by the server in
> response to any other command. So there is still an issue of identifying
> the exact meaning of the response if it is sent in unexpected context.

I wasn't entirely buying the "it's hard to track the context of the response
without complicating your parser" assertions but this justification makes
complete sense to me.

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

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

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.

				Ned