We've identified a number of SIP2 quirks which are features of an ILS product rather than features of a particular installation.

An example of a feature of a particular installation would be "All connections must be secured via SSL with such-and-such a certificate" or "All connections from a circulation manager must send location code X." These are the results of decisions made by library staff during installation of a SIP2 server. We deal with these quirks by adding individual configuration settings for them.

An example of a product quirk would be "the PA field, not defined in the SIP2 spec, is used here to convey the expiration date of the patron's library card", or "the 'End Patron Session' message (35) is not recognized and clients should just drop the connection when they're done." These are the results of decisions by a software development team during the development of an ILS product.

We could deal with product quirks by adding individual configuration settings for them, but this isn't optimal, for two reasons:

1. Library staff will be configuring the SIP2 setup. They didn't make the product decisions and they probably don't know which answer is the "correct" answer to any of these questions. But they do know which ILS product they're using.
2. Product quirks are a package deal, in a way that feature quirks are not. Your SSL certificate decision has nothing to do with your location code decision, but by choosing one ILS or another you've locked yourself into a whole package of product quirks.

Instead, let's create a single configuration setting that lets the library admin configure the "dialect" of SIP2 in use by selecting one ILS product or another. The default dialect will be "Generic SIP2", and will have the current behavior.

Each dialect should have a class somewhere in the admin/sip package, probably in admin/sip/client.py, which can be passed into the SIP2Client constructor to configure its behavior. This would work similarly to the csv.Dialect class in the Python standard library. When we instantiate a SIP2AuthenticationProvider, we'll look up the appropriate dialect class, and when SIP2AuthenticationProvider instantiates a SIP2 client, we'll pass that class in as one of the constructor arguments.

As we identify quirks that would require backwards-incompatible changes (such as sending vs. not sending the "End Patron Session" message), we can use the dialect classes to customize the behavior of the SIP2Client class. There's a lot of sophisticated stuff we could do w/r/t the design of the dialect classes, but I think it's best to just define some constants in there and keep all the actual code in SIP2Client.