I've stayed out of this thread up to now. Reason codes are great, but they are often not easily mapped into specific internal states. The extra text is useful because it allows the *programmers* to describe exactly what is going on.
It should *not* be localized for a few reasons:
1. the locale of the person running the gateway/end-point might not match the
locale of the person running the initiating client.
We went through this with SMTP. Telling *me* in Russian that the account
is full is useless. We went 4xx/5xx codes, then text, then did these
enhanced mail systems status codes (RFC3463).
It's only useful if all the codes mean the same thing on every system, and
all possible error conditions are covered, ideally, uniquely.
2. Neither the client end-user, nor the gateway operator, regardless of what
languages they speak, are going to have any idea what to with either code
or the text strings.
The text strings *might* be searchable and result in useful things.
But not if they are localized.
3. The most likely situation is that a support ticket is opened with the text.
If it's not obvious, when it is escaladed, the programmers will search
their source code for that text. The text is *not* localized. Localized
text will just result in ticket going to bottom of pile.
{If it's open source, anyone can do this search}
The error might also be searchable in the gateway system's logs, which are
sometimes localized; but every single place I've seen where they do that,
they go back to english, because the translations are wrong/useless.
During bakeoffs^Winterop sessions, it has often been the case that you can
not fix anything without reading lots from both ends. Sometimes requiring an
expert.
Some people worry that too detailed errors will tell the bad guys too much.
Bullshit I say: They already know. If there something too revealing, then
programmers can put in something unique to the situation, or even unique
period. ("Guru Meditation Error 123498345, please search logs")
and then depend upon people searching the logs for the details.
Not being able to fix errors leads to people turning off the security, which
benefits the bad guys way more in my opinion.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
