Addinfo Mandatory

Addinfo is mandatory in a bib-1 diagnostic. What should a server do when it has no useful or meaningful information to provide?

It has been suggested that addInfo should not have been defined as mandatory and that this is a defect in the standard; however there isn't consensus on this view. But there is consensus (even among those who take this view) that the standard should not now be amended to correct this perceived defect. There are many deployed clients who expect addinfo (whether the addinfo information is meaningful or not), and who would interpret the omission of addinfo to be a protocol error. Since this issue has not been raised before and since addinfo has been mandatory for many years it would be unfair to these clients and would do more harm than good to change addinfo to be optional.

Thus, a server should always include addInfo in a bib-1 diagnostic (a client may, if it wishes, accept a bib-1 diagnostic where addInfo is omitted).

But the question remains: what value of addInfo should be supplied when the server has no meaningful additional information to supply? In addressing this question it is useful to distinguish between the two classes of bib-1 diagnostics:

1. Those whose definition does not specify any particular additional information; these define addInfo either as "unspecified" or simply leave blank the addInfo cell in the definition.
2. Those who specify a particular type of additional information, for example, diagnostic 109: "database unavailable", which specifies addInfo as "database name".

In the first category,
it is recomended that the sever either:

• Supply a text string, for example, "no further information available". It is further recommended in this case that the client show the message to the user.
• Supply a well-known value, in lieu of, and to mean "no additional information available". The well-known value would be either "null" or a zero-length string.

  Discussion
  The first option is recomended in cases where the server knows what language the client prefers, as in the case where a language has been negotiated. When the server does not know what language the client prefers, the second option is recommended, however there are different opinions of what the well-known value should be. A zero-length string poses a problem for some implementations.

In the second category,
the use of a well-known value is inappropriate, because it cannot be distinguished from a real value (for example, "null" could be a database name). However, it seems that for this category the server should always be capable of providing the specified information. For example, if a server declares "database unavailable" it should be able to say which database.