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

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> Ned Freed writes:
> >> Ned Freed writes:
> >> >> 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.
> >>
> >> Unless the software in question... hm... there are two ways to finish
> >> this sentence...
> >>    - sucks enough to break subtly when it can't find it i18n files.
> >>    - is documented to require its i18n files.
> >> Personally I lean towards the first phrasing. And if we implement
> >> LANGUAGE we'll check that we have >1 language before announcing it.
> >
> > I'm sorry, but I quite simply disagree with this assessment.

> Are you sure?

I'm completely sure.

> Let me put it another way. If a piece of software needs a file and the
> file isn't there, then IMNSHO there are exactly three possibilities:
> Either the software says so at startup and quits, or it says so and
> adjusts its configuration so it doesn't need the file, or it sucks.

Hogwash. Our product uses literally hundreds of files in dozens of directories,
there are many similar products that use thousands. Messaging servers typically
spend more time running that they does being shut down, and full-on startups
are in any case rare - in our case we've had systems remain continuously
available for periods most easily measured in years.

Files can be deleted, moved, or modified at any time, and in practice these
sorts of actions happen routinely as a part of normal product reconfiguration.
But for every legitimate reconfiguration actitivity a vast number of harmful or
nonsensical actions are possible, and sufficient user cluelessness to screw
things up abounds despite numerous warnings and whatnot in the documeentation.

Indeed, only yesterday we had a case of someone creating files with
inappropriate names in a reserved directory that tricked a check we
periodically do into some bad behavior.  (And please note the irony - this was
a check we specifically make to see if certain files are present that went
wonky, not a problem caused by a check we didn't do.)

Code written to check and see if all is well at the filesystem level at
frequent enough intervals to catch all such problems would never do anything
else. (Actually, it's worse than that. There are cases where figuring the set
of files necessary is at least NP-hard, if not halting problem hard.) It
follows that it is entirely reasonable for code to only perform file presence
checks when ther's a compelling argument for doing so. In fact it's a practical
necessity that things be coded this way.

In this particular case the argument, such as it is, for this particular check
is that doing it prevents a wierd corner case from arising that most readers of
a specification aren't going to catch. And that in turn meands absent a
specific admonition in the specification it is entirely reasonable to expect
developers not too perform such a check.

> Breaking subtly when it's time to use a particular feature puts it into
> the third category.

Any the sorts of checks necessary to truly insure the sort of safety you're
talking about would put it in a fourth category - pararnoiaware. (Although if
you manage to crack NP in the process, it would definitely be worth it...)

				Ned