Make error messages more useful: add a URI

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Make error messages more useful: add a URI

Nico Williams
Consider the error that you get from gss_init_sec_context() when there's
no ccache or the ccache is corrupted:

    No Kerberos credentials available

That's just not sufficiently informative.  Adding more information would
be nice (I'll be submitting a patch for that), but it's not always
possible or appropriate to -say- give the user advice as to how to
recover.

While we can improve some errors on a case by case basis, there will be
enough site-specific context in many cases that a way to direct users to
an appropriate web page would be handy.

The idea is to derive a reasonably stable URI local part from context
and format a URI.  If a site-local base URI is configured, then that
should be used, otherwise something like file:///${docdir}/pages/ should
be used as the base URI.

Option #1: Hash the krb5_set_error_message() format string to get a
           resource local part.

Option #2: Use the error code's symbolic name (e.g., KRB5_CC_NOTFOUND)
           to build a resource local part (e.g., cc_notfound).

Option #3: Keep a stable format string / error code to resource local
           part mapping and look that up at run time.

Option #1 would require doing something (possibly nothing) about
collisions if the hash function is not cryptographic or if a
cryptographic hash function's output is truncated.  Collisions may be
tolerable.  Running an expensive hash function at run-time probably not
really acceptable.

Option #2 would require enhancing the error table compiler to produce
code->symbol mappings.

Option #3 would affect krb5 developers too much for my tastes.

Ideally some additional information could be passed as query parameters.
That would require much more work on the codebase, but it could be done
for just those error conditions where it'd be most useful.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Greg Hudson
On 10/01/2014 05:18 PM, Nico Williams wrote:
> The idea is to derive a reasonably stable URI local part from context
> and format a URI.  If a site-local base URI is configured, then that
> should be used, otherwise something like file:///${docdir}/pages/ should
> be used as the base URI.

I am interested to hear other people's opinions on this.

In general I am an error message minimalist; I think error messages
should be useful, but also readable.  I do not generally see URIs or
unique identifiers in the error messages reported by my applications and
tools; in the rare cases where I do, it tends to make me feel like the
application is clunky.

But I am open to the possibility that I'm wrong-headed about this.
Regardless, it would be a lot of work to create a backing set of useful
documentation about each error code or format string.  Often, it's not
possible to provide useful advice without knowing more about the context
which led to the error.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Nico Williams
On Thu, Oct 02, 2014 at 03:00:03PM -0400, Greg Hudson wrote:
> In general I am an error message minimalist; I think error messages
> should be useful, but also readable.  I do not generally see URIs or
> unique identifiers in the error messages reported by my applications
> and tools; in the rare cases where I do, it tends to make me feel like
> the application is clunky.

FWIW, Solaris' SMF and FMA use URIs in their error messages.

Without a URI all you have is search engines and the text error.  The
pithier the error, the more difficult to search.  Either way you have a
search and it will take time and effort to find your way.  "Use the docs
Luke" is not a good answer for most users.

But with a URI the user just clicks (at worst cuts-n-pastes) and there,
they have all the info they need.  Site-specific pages could have
site-specific diagnostic and corrective action information.

> But I am open to the possibility that I'm wrong-headed about this.

"Wrong-headed" is a bit strong.  This shouldn't be necessary, but
site-specific Kerberos practices vary a *lot*, and that's what's causing
me to propose this at all.

I'm being asked to express error messages that I am certain you'd not
accept (e.g., "No Kerberos credentials available: KRB5CCNAME not set and
default ccache (/tmp/krb5cc_...) does not exist").

I expect you to reject such errors for the same reasons that I would
reject them were I in your shoes.  Not every environment that uses GSS
will use Kerberos, not every Kerberos shop will expect KRB5CCNAME to be
set at all times, not every Kerberos shop will use FILE ccaches, and so
on.  But you can see how a URI would allow us to customize the
information shown to users on a site-specific basis.

(In some environments not having KRB5CCNAME set is effectively an error
condition, often arising from [unfortunate] overuse of LD_LIBRARY_PATH
(and other *PATH variables) that then leads to overuse of env -i and
losing precious variables.  In such environments the absence of
KRB5CCNAME from the environment is quite indicative of erroneous wiping
of the environment, thus it's very useful diagnostic information.  In
other environments having error messages from libkrb5 say anything about
KRB5CCNAME would be distracting.)

Customizable errors (site-specific localization, as it were) would also
help (since one could then have them mention KRB5CCNAME where that's
desirable).  But that seems to be potentially more difficult to
implement, and even so would require changes to how ENOENT is handled in
ccfile.c you might still look at askance.  Though perhaps you'd prefer
this, in which case I'd be happy to take this route.

> Regardless, it would be a lot of work to create a backing set of
> useful documentation about each error code or format string.  Often,
> it's not possible to provide useful advice without knowing more about
> the context which led to the error.

You'd not have to write such pages: by default you might not generate
URIs.  And all URIs might well lead to just a common page.  But in some
environments we might gladly write such pages.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Nico Williams
In reply to this post by Greg Hudson

Roland suggests:

[libdefaults]

    err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N

where %E is whatever the error string would have been and %N is the
error code number (or symbolic name for it).

The default would be %E.

Additional contextual information could be provided with other tokens.

This would allow sites to use URIs or some other non-URI string if they
prefer.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Ken Hornstein
In reply to this post by Greg Hudson
>In general I am an error message minimalist; I think error messages
>should be useful, but also readable.  I do not generally see URIs or
>unique identifiers in the error messages reported by my applications and
>tools; in the rare cases where I do, it tends to make me feel like the
>application is clunky.

I can offer my experience being on the developer side and having to deal
with end-users as part of a big rollout.

>From an end-user perspective, the error messages are almost always
meaningless; they all boil down to "system failure" (I'm talking about
the average end-user).  In our environment users don't google the text
error message; they contact the support desk.  So they either have to
read the error message over the phone or (more sophisticated) they
can cut and paste or do a screenshot and send it via email.  I think the
majority of support happens on the phone.

Now if URIs did pop up, would users click or cut & paste them?  Maybe.
I don't have a good sense for that.  I think we'd be willing to write
custom web pages that would deal with a lot of first-level tech support
questions, which might be nice.  We'd need an easy way to provide a custom
set of URIs to Kerberos implementations, though; I don't really want to
have to patch com_err tables.  Nico's later suggestion about a line in
libdefaults looks interesting.

--Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Nico Williams
On Thu, Oct 02, 2014 at 10:57:33PM -0400, Ken Hornstein wrote:

> I can offer my experience being on the developer side and having to deal
> with end-users as part of a big rollout.
>
> >From an end-user perspective, the error messages are almost always
> meaningless; they all boil down to "system failure" (I'm talking about
> the average end-user).  In our environment users don't google the text
> error message; they contact the support desk.  So they either have to
> read the error message over the phone or (more sophisticated) they
> can cut and paste or do a screenshot and send it via email.  I think the
> majority of support happens on the phone.

Yes.  It's awful.

> Now if URIs did pop up, would users click or cut & paste them?  Maybe.
> I don't have a good sense for that.  I think we'd be willing to write
> custom web pages that would deal with a lot of first-level tech support
> questions, which might be nice.  We'd need an easy way to provide a custom
> set of URIs to Kerberos implementations, though; I don't really want to
> have to patch com_err tables.  Nico's later suggestion about a line in
> libdefaults looks interesting.

Roland's suggestion is functionally the same as my URI suggestion, but
without forcing you to use a URI.

Note that there's no need to write a page for every possible URI: you
can have one page (a 404 if you like) to handle all cases that you don't
write a specific page for.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Benjamin Kaduk-2
In reply to this post by Nico Williams
On Thu, 2 Oct 2014, Nico Williams wrote:

>
> Roland suggests:
>
> [libdefaults]
>
>     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
>
> where %E is whatever the error string would have been and %N is the
> error code number (or symbolic name for it).
>
> The default would be %E.
>
> Additional contextual information could be provided with other tokens.
>
> This would allow sites to use URIs or some other non-URI string if they
> prefer.

This seems plausible, though I still am interested in hearing more
feedback if we can get it.

I'm slightly concerned that supporting more %foo tokens for expansion
would lead to an API explosion at call sites that set the error message.
Adding N new optional positional parameters to krb5_set_error_message to
hold all the possible values seems bad.  Adding a single struct parameter
to hold them all might be bad.  A single parameter to the head of a linked
list of containers holding type-tagged data is probably too complex;
adding separate routines to add a single expandable value to the context
might make call sites too noisy, depending on how common it is to set
extra attributes.

Did you have anything in particular in mind?

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Nico Williams
On Fri, Oct 03, 2014 at 12:07:34PM -0400, Benjamin Kaduk wrote:

> On Thu, 2 Oct 2014, Nico Williams wrote:
> > [libdefaults]
> >     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
> >
> > [...]
>
> I'm slightly concerned that supporting more %foo tokens for expansion
> would lead to an API explosion at call sites that set the error message.
> Adding N new optional positional parameters to krb5_set_error_message to
> hold all the possible values seems bad.  Adding a single struct parameter
> to hold them all might be bad.  A single parameter to the head of a linked
> list of containers holding type-tagged data is probably too complex;
> adding separate routines to add a single expandable value to the context
> might make call sites too noisy, depending on how common it is to set
> extra attributes.
>
> Did you have anything in particular in mind?

I hadn't thought about it much, but here's the list of tokens I
envision:

 %E -> normal error message
 %N -> error code (numeric)
 %S -> error code (symbolic; string)
 %A -> additional context information (string)

The last item would require changes at various krb5_set_error_message()
call sites, and might not materialize.  Things I'd expect to be included
in it, if it happens at all, might be: relevant environment variables
and values, and the ccache name (if defaulted).

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Roland Mainz
In reply to this post by Nico Williams


----- Original Message -----

> From: "Nico Williams" <[hidden email]>
> To: "Greg Hudson" <[hidden email]>
> Cc: [hidden email]
> Sent: Thursday, October 2, 2014 11:15:08 PM
> Subject: Re: Make error messages more useful: add a URI
>
>
> Roland suggests:
>
> [libdefaults]
>
>     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
>
> where %E is whatever the error string would have been and %N is the
> error code number (or symbolic name for it).
>
> The default would be %E.
>
> Additional contextual information could be provided with other tokens.
>
> This would allow sites to use URIs or some other non-URI string if they
> prefer.

BTW: Three nits:
1. Some error messages carry additional information, like an errno message. How can we integrate this ?
2. How can we carry over the value of LC_MESSAGES (or better: The result of LANG/LC_MESSAGES/LC_ALL, e.g. $ printf '%s\n' "${LC_ALL:-${LC_MESSAGES:-${LANG:-"C"}}}" # in a POSIX shell) ?
3. What about intranets with no connection to the outside "world" ?

----

Bye,
Roland

--
  __ .  . __
 (o.\ \/ /.o) [hidden email]
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Benjamin Kaduk-2
Maybe I should let Nico answer for himself, but

On Mon, 6 Oct 2014, Roland Mainz wrote:

>
>
> ----- Original Message -----
> > From: "Nico Williams" <[hidden email]>
> > To: "Greg Hudson" <[hidden email]>
> > Cc: [hidden email]
> > Sent: Thursday, October 2, 2014 11:15:08 PM
> > Subject: Re: Make error messages more useful: add a URI
> >
> >
> > Roland suggests:
> >
> > [libdefaults]
> >
> >     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
> >
> > where %E is whatever the error string would have been and %N is the
> > error code number (or symbolic name for it).
> >
> > The default would be %E.
> >
> > Additional contextual information could be provided with other tokens.
> >
> > This would allow sites to use URIs or some other non-URI string if they
> > prefer.
>
> BTW: Three nits:
> 1. Some error messages carry additional information, like an errno message. How can we integrate this ?

I'm pretty sure this is included in the "%E".

> 2. How can we carry over the value of LC_MESSAGES (or better: The result of LANG/LC_MESSAGES/LC_ALL, e.g. $ printf '%s\n' "${LC_ALL:-${LC_MESSAGES:-${LANG:-"C"}}}" # in a POSIX shell) ?

I suspect this is hard to do in a concise manner, so may not end up
getting done.

> 3. What about intranets with no connection to the outside "world" ?

The proposed file:/// URLs would still work.

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Nico Williams
On Mon, Oct 6, 2014 at 10:59 AM, Benjamin Kaduk <[hidden email]> wrote:
> Maybe I should let Nico answer for himself, but

I'll be traveling the next few days, but I can answer right now.

> On Mon, 6 Oct 2014, Roland Mainz wrote:
>> BTW: Three nits:
>> 1. Some error messages carry additional information, like an errno message. How can we integrate this ?
>
> I'm pretty sure this is included in the "%E".

Correct.

>> 2. How can we carry over the value of LC_MESSAGES (or better: The result of LANG/LC_MESSAGES/LC_ALL, e.g. $ printf '%s\n' "${LC_ALL:-${LC_MESSAGES:-${LANG:-"C"}}}" # in a POSIX shell) ?
>
> I suspect this is hard to do in a concise manner, so may not end up
> getting done.

The wrapper message could be localized, and if all you want is to add
a URI then no localization would be required.

Finally, this would be for site-local uses.  At many sites
localization is not required.

>> 3. What about intranets with no connection to the outside "world" ?
>
> The proposed file:/// URLs would still work.

As well as http/https URIs pointing to servers within the intranet.
This would be fully under the control of the config file author.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Roland Mainz
In reply to this post by Benjamin Kaduk-2


----- Original Message -----

> From: "Benjamin Kaduk" <[hidden email]>
> To: "Roland Mainz" <[hidden email]>
> Cc: "Nico Williams" <[hidden email]>, [hidden email]
> Sent: Monday, October 6, 2014 5:59:22 PM
> Subject: Re: Make error messages more useful: add a URI
>
> Maybe I should let Nico answer for himself, but
>
> On Mon, 6 Oct 2014, Roland Mainz wrote:
>
> >
> >
> > ----- Original Message -----
> > > From: "Nico Williams" <[hidden email]>
> > > To: "Greg Hudson" <[hidden email]>
> > > Cc: [hidden email]
> > > Sent: Thursday, October 2, 2014 11:15:08 PM
> > > Subject: Re: Make error messages more useful: add a URI
> > >
> > >
> > > Roland suggests:
> > >
> > > [libdefaults]
> > >
> > >     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
> > >
> > > where %E is whatever the error string would have been and %N is the
> > > error code number (or symbolic name for it).
> > >
> > > The default would be %E.
> > >
> > > Additional contextual information could be provided with other tokens.
> > >
> > > This would allow sites to use URIs or some other non-URI string if they
> > > prefer.
> >
> > BTW: Three nits:
> > 1. Some error messages carry additional information, like an errno message.
> > How can we integrate this ?
>
> I'm pretty sure this is included in the "%E".
>
> > 2. How can we carry over the value of LC_MESSAGES (or better: The result of
> > LANG/LC_MESSAGES/LC_ALL, e.g. $ printf '%s\n'
> > "${LC_ALL:-${LC_MESSAGES:-${LANG:-"C"}}}" # in a POSIX shell) ?
>
> I suspect this is hard to do in a concise manner, so may not end up
> getting done.

1. Why ? AFAIK this isn't hard (see example below)
2. This is then going to backfire in very BAD ways for some scenarios - there are governments like (PRC, Japan, etc.) which mandate correct localisation support. No localisation support - no sales to government.

One option might be to include the result of $ printf '%s\n' "${LC_ALL:-${LC_MESSAGES:-${LANG:-"C"}}}" # (minus encoding, e.g. "en_US.UTF-8" and
"en_US.ISO8859-1" can be reduced to "en_US") into the URL, e.g. file:///usr/share/krb5/docs/en_US/krb_message_8291.html

> > 3. What about intranets with no connection to the outside "world" ?
>
> The proposed file:/// URLs would still work.

OK...

----

Bye,
Roland

--
  __ .  . __
 (o.\ \/ /.o) [hidden email]
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Benjamin Kaduk-2
On Tue, 7 Oct 2014, Roland Mainz wrote:

>
>
> ----- Original Message -----
> > From: "Benjamin Kaduk" <[hidden email]>
> > To: "Roland Mainz" <[hidden email]>
> > Cc: "Nico Williams" <[hidden email]>, [hidden email]
> > Sent: Monday, October 6, 2014 5:59:22 PM
> > Subject: Re: Make error messages more useful: add a URI
> > >
> > > ----- Original Message -----
> > > > From: "Nico Williams" <[hidden email]>
> > > > To: "Greg Hudson" <[hidden email]>
> > > > Cc: [hidden email]
> > > > Sent: Thursday, October 2, 2014 11:15:08 PM
> > > > Subject: Re: Make error messages more useful: add a URI
> >
> > > 2. How can we carry over the value of LC_MESSAGES (or better: The result of
> > > LANG/LC_MESSAGES/LC_ALL, e.g. $ printf '%s\n'
> > > "${LC_ALL:-${LC_MESSAGES:-${LANG:-"C"}}}" # in a POSIX shell) ?
> >
> > I suspect this is hard to do in a concise manner, so may not end up
> > getting done.
>
> 1. Why ? AFAIK this isn't hard (see example below)
> 2. This is then going to backfire in very BAD ways for some scenarios - there are governments like (PRC, Japan, etc.) which mandate correct localisation support. No localisation support - no sales to government.
>
> One option might be to include the result of $ printf '%s\n' "${LC_ALL:-${LC_MESSAGES:-${LANG:-"C"}}}" # (minus encoding, e.g. "en_US.UTF-8" and
> "en_US.ISO8859-1" can be reduced to "en_US") into the URL, e.g. file:///usr/share/krb5/docs/en_US/krb_message_8291.html

The serious difficulties only apply to an extra piece of text inserted as
a literal value in krb5.conf.  This text is administrator-supplied, and
cannot be a part of or message catalog because it is not known at compile
time.  On the other hand, an administrator can choose to not put any
additional text requiring localization (e.g., retaining the original
error string and adding only a URL with no other text), in which case
there is no problem.

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Greg Hudson
In reply to this post by Greg Hudson
> [libdefaults]

>     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N

We would probably accept a patch for this, as long as it doesn't turn
out to be a lot of code.  There does need to be an internal API to get
the unadorned message for the places where we augment or copy error
messages, or an equivalent means of handling those cases without doubly
applying the err_fmt.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Wang Shouhua
On 9 October 2014 23:07, Greg Hudson <[hidden email]> wrote:
>> [libdefaults]
>
>>     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
>
> We would probably accept a patch for this, as long as it doesn't turn
> out to be a lot of code.  There does need to be an internal API to get
> the unadorned message for the places where we augment or copy error
> messages, or an equivalent means of handling those cases without doubly
> applying the err_fmt.

So basically you say localization doesn't matter for MIT?

Wang
--
Wang Shouhua - [hidden email]
中华人民共和国科学技术部 - HTTP://WWW.MOST.GOV.CN

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Greg Hudson
On 10/21/2014 10:51 AM, Wang Shouhua wrote:

> On 9 October 2014 23:07, Greg Hudson <[hidden email]> wrote:
>>> [libdefaults]
>>
>>>     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
>>
>> We would probably accept a patch for this, as long as it doesn't turn
>> out to be a lot of code.  There does need to be an internal API to get
>> the unadorned message for the places where we augment or copy error
>> messages, or an equivalent means of handling those cases without doubly
>> applying the err_fmt.
>
> So basically you say localization doesn't matter for MIT?

I'm not sure how you reached that conclusion.  If localization didn't
matter for MIT, we would not have implemented
http://k5wiki.kerberos.org/wiki/Projects/Localization back in 1.10.

Our built-in error messages already go through a localization step.
What do you suggest beyond this?  We cannot, of course, automatically
localize user-defined text within a custom err_fmt.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Benjamin Kaduk-2
In reply to this post by Wang Shouhua
On Tue, 21 Oct 2014, Wang Shouhua wrote:

> On 9 October 2014 23:07, Greg Hudson <[hidden email]> wrote:
> >> [libdefaults]
> >
> >>     err_fmt = %E. Please see <a href="https://whatever.example/%N">https://whatever.example/%N
> >
> > We would probably accept a patch for this, as long as it doesn't turn
> > out to be a lot of code.  There does need to be an internal API to get
> > the unadorned message for the places where we augment or copy error
> > messages, or an equivalent means of handling those cases without doubly
> > applying the err_fmt.
>
> So basically you say localization doesn't matter for MIT?

I do not follow the reasoning leading you to this conclusion.  Can you
please give more detail for why you say this?

-Ben
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Make error messages more useful: add a URI

Nico Williams
In reply to this post by Greg Hudson
I'll send a patch this week.  Thanks!

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev