1.1 Synopsis

PAIA consists of two independent parts:

• PAIA core defines six basic API methods to look up loaned and reserved items, to request and cancel loans and reservations, and to look up fees and general patron information.

• PAIA auth defines three authentication API methods (login, logout, and password change) to get or invalidate an access token, and to modify credentials.

Authentication in PAIA is based on OAuth 2.0 (RFC 6749) with bearer tokens (RFC 6750) over HTTPS (RFC 2818).

1.2 Status of this document

This specification has been created collaboratively based on use cases and taking into account existing related standards and products of integrated library systems (ILS), such as NISO Circulation Interchange Protocol (NCIP), SIP2, [X]SLNP,¹ DLF-ILS recommendations, and VuFind ILS.

All sources and updates can be found in a public git repository at http://github.com/gbv/paia. See the list of releases at https://github.com/gbv/paia/releases for functional changes. The master file paia.md is written in Pandoc’s Markdown. HTML version of the specification is generated from the master file with makespec. The specification can be distributed freely under the terms of CC-BY-SA.

Additional information and references about PAIA can be found in the public PAIA Wiki at https://github.com/gbv/paia/wiki.

1.3 Conformance requirements

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

A PAIA server MUST implement PAIA core and it MAY implement PAIA auth. If PAIA auth is not implemented, another way SHOULD BE documented to distribute patron identifiers and access tokens. A PAIA server MAY support only a subset of methods but it MUST return a valid response or error response on every method request, as defined in this document.

2.1 API methods

Each API method is accessed at a unique URL with a HTTP verb GET or POST:

All API method URLs MUST also be accessible with HTTP verb OPTIONS. All API methods with HTTP verb GET MAY also be accessible with HTTP verb HEAD.

API method URLs share a common base URL for PAIA core methods and common base URL for PAIA auth methods. A server SHOULD NOT provide additional methods at these base URLs and it MUST NOT propagate additional methods at these base URLs as belonging to PAIA.

Base URLs of PAIA auth and PAIA core are not required to share a common host, nor to include the URL path core/ or auth/. In the following, the base URL https://example.org/core/ is used for PAIA core and https://example.org/auth/ for PAIA auth.

For security reasons, PAIA methods MUST be requested via HTTPS only. A PAIA client MUST NOT ignore SSL certificate errors; otherwise access token (PAIA core) or even password (PAIA auth) are compromised by the client.

2.2 Access tokens and scopes

All PAIA API methods, except PAI auth login and HTTP OPTIONS requests require an access token as a special request parameter. The access token is a so called bearer token as described in RFC 6750. The access token can be sent either as a URL query parameter or in an HTTP header. For instance the following requests both get information about patron 123 with access token vF9dft4qmT:

curl -H "Authorization: Bearer vF9dft4qmT" https://example.org/core/123
curl -H https://example.org/core/123?access_token=vF9dft4qmT

An access token is valid for a limited set of actions, referred to as scope. The following scopes are possible for PAIA core:

read_patron

Get patron information by the patron method.

read_fees

Get fees of a patron by the fees method.

read_items

Get a patron’s item information by the items method.

write_items

Request, renew, and cancel items by the request, renew, and cancel methods.

For instance a particular token with scopes read_patron and read_items may be used for read-only access to information about a patron, including its loans and requested items but not its fees.

For PAIA auth there is an additional scope:

change_password

Change the password of a patron with the PAIA auth change method.

A PAIA auth server MAY support additional scopes to share an access token with other services.

2.3 Request and response format

Each API method call expects a set of request parameters, given as URL query fields, HTTP headers, or HTTP message body and return a JSON object. Most parts of PAIA core request parameters and JSON response can be mapped to RDF as defined by the PAIA Ontology.

Request parameters and fields of response objects are defined in this document with:

• the name of the parameter/field
• the ocurrence (occ) of the parameter/field being one of
  • 0..1 (optional, non repeatable)
  • 1..1 (mandatory, non repeatable)
  • 1..n (mandatory, repeatable)
  • 0..n (optional, repeatable)
• the data type of the parameter/field
• a short description

Simple parameter names and response fields consist of lowercase letters a-z only.

Repeatable response fields are encoded as JSON arrays with irrelevant order, for instance:

{ "fee" : [ { ... }, { ... } ] }

Hierarchical JSON structures in this document are referenced with a dot (.) as separator. For instance the subfield/parameter item of the doc element is referenced as doc.item and refers to the following JSON structure:

{ "doc" : [ { "item" : "..." } ] }

2.4 URL query fields

The following special request parameters can be added to any request as URL query fields:

access_token

An access token can be sent either as URL query parameter or as HTTP request header.

callback

A JavaScript callback method name to return JSONP instead of JSON. The callback MUST only contain alphanumeric characters and underscores.

suppress_response_codes

If this parameter is present, all responses MUST be returned with a 200 OK status code, even request errors.

2.5 HTTP headers

2.6 HTTP message body

All POST requests MUST include a HTTP message body.

• For PAIA core the message body MUST be sent in JSON format with content type application/json. A PAIA core server MAY also support message body as URL encoded query string.

• For PAIA auth the message body MUST be sent as URL encoded query string with content type application/x-www-form-urlencoded. A PAIA auth server MAY also support message body in JSON.

A PAIA Server MUST also accept the explicit charset UTF8 (content type application/json; charset=utf-8 or application/x-www-form-urlencoded; charset=utf-8). A PAIA Server MAY support additional request charsets such as ISO-8859-1.

2.7 Request errors

Malformed requests, failed authentication, unsupported methods, and unexpected server errors such as backend downtime etc. MUST result in an error response. An error response is returned with an HTTP status code 4xx (client error) or 5xx (server error) as defined in RFC 2616, unless the request parameter suppress_response_codes is given.

Document errors MUST NOT result in a request error but they are part of a normal response.

The response body of a request error is a JSON object with the following fields (compatible with OAuth error response):

The code field is REQUIRED with request parameter suppress_response_codes in PAIA core. It SHOULD be omitted with PAIA auth requests to not confuse OAuth clients.

The response header of a request error MUST include a WWW-Authenticate header field to indicate the need of providing a proper access token. The field MAY include a short name of the PAIA service with a “realm” parameter:

WWW-Authenticate: Bearer
WWW-Authenticate: Bearer realm="PAIA Core"

The following error responses are expected:²

For instance the following response could result from a request with malformed URIs:

{
  "error": "invalid_request",
  "code": "422",
  "error_description": "malformed item identifier provided: must be an URI",
  "error_uri": "http://example.org/help/api"
}

2.8 Simple data types

The following data types are used to define request and response format:

string

A Unicode string. Strings MAY be empty.

nonnegative integer

An integer number larger than or equal to zero.

boolean

Either true or false. Note that omitted boolean values are not false by default but unknown!

date

A date value in YYYY-MM-DD format. A datetime value with time and timezone SHOULD be used instead, if possible.

datetime

A date value in YYY-MM-DD format, optionally followed by a time value. A time value consists of the letter T followed by hh:mm:ss format, and a timezone indicator (Z for UTC or +hh:mm or -hh:mm) where:

• YYYY indicates a year (0001 through 9999)
• MM indicates a month (01 through 12)
• DD indicates a day (01 through 31)
• hh indicates an hour (00 through 23)
• mm indicates a minute (00 through 59)
• ss indicates a second (00 through 59)

Examples of valid datetime values include 2015-03-20 (a date), 2016-03-09T11:58:19+10:00, and 2017-08-21T12:24:28-06:00.

money

A monetary value with currency (format [0-9]+\.[0-9][0-9] [A-Z][A-Z][A-Z]), for instance 0.80 USD.

email

A syntactically correct email address.

URI

A syntactically correct URI.

account state

A nonnegative integer representing the current state of a patron account. Possible values are:

0. active
1. inactive
2. inactive because account expired
3. inactive because of outstanding fees
4. inactive because account expired and outstanding fees

A PAIA server MAY define additional states which can be mapped to 1 by PAIA clients. In JSON account states MUST be encoded as numbers instead of strings.

service status

A nonnegative integer representing the current status in fulfillment of a service. In most cases the service is related to a document, so the service status is a relation between a particular document and a particular patron. Possible values are:

0. no relation (this applies to most combinations of document and patron, and it can be expected if no other state is given)
1. reserved (the document is not accessible for the patron yet, but it will be)
2. ordered (the document is being made accessible for the patron)
3. held (the document is on loan by the patron)
4. provided (the document is ready to be used by the patron)
5. rejected

A PAIA server MUST NOT define any other service status. In JSON service status MUST be encoded as numbers instead of strings.

2.9 Documents

A document is a key-value structure with the following fields:

For each document at least an item URI or an edition URI MUST be given. Together, item and edition URI MUST uniquely identify a document within the set of documents related to a patron.

The fields starttime and endtime MUST be interpreted as following:

Note that timezone information is mandatory in these fields. The field duedate is deprecated. Clients SHOULD only use it as endtime if no endtime was given.

If both storage and storageid are given, a PAIA server MUST return identical values of storage for identical id and identical content language. PAIA clients MAY override the value of storage based on storageid and a preferred language.

Unknown document URIs and failed attempts to request, renew, or cancel a document MUST NOT result in a request error. Instead they are indicated by a document error with field error. Form and type of document errors are not specified, so clients SHOULD use these messages for display only.

If condition is given, a PAIA server MUST also include a document error for the same document, for instance the error message “confirmation required”. This allows PAIA clients without support of conditions and conformations to treat conditions as simple, unrecoverable document errors.

{
   "status":    5,
   "item":      "http://example.org/items/barcode1234567",
   "edition":   "http://example.org/documents/9876543",
   "requested": "http://example.org/documents/9876543",
   "starttime": "2014-07-12T14:07Z",
   "error":     "sorry, we found out that our copy is lost!"
}

{
  "item": "http://example.org/some/uri",
  "error": "item URI not found"
}

2.10 Conditions and confirmations

Conditions and confirmations can OPTIONALLY be used to require or to select from additional options in PAIA core methods request, renew, and cancel. For instance a PAIA server MAY allow to choose among multiple delivery methods or it MAY require to explicitly agree to some terms of services when a special document is requested. A PAIA client without support of conditions and confirmations will always be assigned to the default option or it will experience a condition as document error if no default option is available.

{
  "http://purl.org/ontology/paia#FeeCondition": {
    "option": [ 
      {
        "id": "http://purl.org/ontology/dso#Loan",
        "about": "loan",
        "amount": "0.50 EUR"
      } 
    ]
  }
}

{
  "http://purl.org/ontology/paia#StorageCondition": {
    "option": [
      {
        "id": "http://example.org/locations/pickup-desk",
        "about": "pickup desk"
      },
      {
        "id": "http://example.org/locations/branch",
        "about": "branch office"
      },
      {
        "id": "http://example.org/services/home-delivery",
        "amount": "2.50 EUR",
        "about": "home delivery"
      }
    ],
    "default": [ "http://example.org/locations/pickup-desk" ]
  },
  "http://example.org/purpose": {
    "multiple": true,
    "option": [
      { 
        "id": "http://example.org/purpose/research",
        "about": "document usage for research"
      },
      { 
        "id": "http://example.org/purpose/leisure",
        "about": "document usage for leisure"
      }
    ],
    "default": [ ]
  }
}

{
  "http://purl.org/ontology/paia#FeeCondition": [
    "http://purl.org/ontology/dso#DocumentService"
  ],
  "http://example.org/purpose": [
    "http://example.org/purpose/research",
    "http://example.org/purpose/leisure"
  ]
}

{ }
{ "http://purl.org/ontology/paia#FeeCondition": [ ] }

{
  "http://example.org/purpose": {
    "multiple": true,
    "option": [
      { "id": "http://example.org/research", "about": "for research" },
      { "id": "http://example.org/leisure", "about": "for leisure" }
    ],
    "default": [ ]
  }

{ "http://example.org/purpose": [ ] }
{ "http://example.org/purpose": [ "http://example.org/research" ] }
{ "http://example.org/purpose": [ "http://example.org/leisure" ] }
{ "http://example.org/purpose": [ "http://example.org/research", "http://example.org/leisure" ] }

3.1 patron

purpose

Get general information about a patron

HTTP verb and URL

GET https://example.org/core/{uri_escaped_patron_identifier}

scope

read_patron

response fields

name	occ	data type	description
name	1..1	string	full name of the patron
email	0..1	email	email address of the patron
address	0..1	string	freeform address of the patron
expires	0..1	datetime	patron account expiry
status	0..1	account state	current state (0, 1, 2, or 3)
type	0..n	URI	list of custom URIs to identify patron types

PAIA server documentation SHOULD refer to a specialized API, such as LDAP, to get more detailed patron information.

GET /core/123 HTTP/1.1
Host: example.org
User-Agent: MyPAIAClient/1.0
Accept: application/json
Authorization: Bearer a0dedc54bbfae4b

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Accepted-OAuth-Scopes: read_patron
X-OAuth-Scopes: read_fees read_items read_patron write_items

{
  "name": "Jane Q. Public", 
  "email": "jane@example.org",
  "address": "Park Street 2, Springfield",
  "expires": "2015-05-18",
  "status": 0,
  "type": ["http://example.org/usertypes/default"]
}

3.2 items

purpose

Get a list of loans, reservations and other items related to a patron

HTTP verb and URL

GET https://example.org/core/{uri_escaped_patron_identifier}/items

scope

read_item

response fields

name	occ	data type	description
doc	0..n	document	list of documents (order is irrelevant)

In most cases, each document will refer to a particular copy (doc.item), but users may also have requested (doc.requested) and/or reserved (doc.edition) an edition.

GET /core/123/items HTTP/1.1
Host: example.org
User-Agent: MyPAIAClient/1.0
Accept: application/json
Authorization: Bearer a0dedc54bbfae4b

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Accepted-OAuth-Scopes: read_patron
X-OAuth-Scopes: read_items read_patron

{
  "doc": [{
    "status": 3,
    "item": "http://bib.example.org/105359165",
    "edition": "http://bib.example.org/9782356",
    "about": "Maurice Sendak (1963): Where the wild things are",
    "label": "Y B SEN 101",
    "queue": 0,
    "renewals": 0,
    "reminder": 0,
    "starttime": "2014-05-08T12:37Z",
    "endtime": "2014-06-09",
    "cancancel": false,
  },{
    "status": 1,
    "item": "http://bib.example.org/8861930",
    "about": "Janet B. Pascal (2013): Who was Maurice Sendak?",
    "label": "BIO SED 03",
    "queue": 1,
    "starttime": "2014-05-12T18:07Z",
    "endtime": "2014-05-24",
    "cancancel": true,
    "storage": "pickup service desk",
    "storageid": "http://bib.example.org/library/desk/7",
  }]
}

3.3 request

purpose

Request one or more items for reservation or delivery.

HTTP verb and URL

POST https://example.org/core/{uri_escaped_patron_identifier}/request

scope

write_item

request parameters

name	occ	data type	description
doc	1..n	array	list of documents requested
doc.item	0..1	URI	URI of a particular item
doc.edition	0..1	URI	URI of a particular edition
doc.confirm	0..1	confirmation	Confirmation
doc.storageid	0..1	URI	Requested document location (deprecated)

response fields

name	occ	data type	description
doc	1..n	document	list of documents (order is irrelevant)

The response SHOULD include the same documents as requested. A client MAY also use the items method to get the service status after request.

The field doc.storageid is deprecated and MUST be ignored if field doc.confirm is given. Otherwise a PAIA core server SHOULD map the value of field doc.storageid (e.g http://example.org/a/location) to a corresponding confirmation in field doc.confirm:

{
  "http://purl.org/ontology/paia#StorageCondition": [
    "http://example.org/a/location"
  ]
}

3.4 renew

purpose

Renew one or more documents usually held by the patron. PAIA servers MAY also allow renewal of reserved, ordered, and provided documents.

HTTP verb and URL

POST https://example.org/core/{uri_escaped_patron_identifier}/renew

scope

write_item

request parameters

doc	1..n	array	list of documents to renew
doc.item	0..1	URI	URI of a particular item
doc.edition	0..1	URI	URI of a particular edition
doc.confirm	0..1	confirmation	Confirmation

response fields

name	occ	data type	description
doc	1..n	document	list of documents (order is irrelevant)

The response SHOULD include the same documents as requested. A client MAY also use the items method to get the service status after renewal.

3.5 cancel

purpose

Cancel requests for items.

HTTP verb and URL

POST https://example.org/core/{uri_escaped_patron_identifier}/cancel

scope

write_item

request parameters

name	occ	data type
doc	1..n	array	list of documents to cancel
doc.item	0..1	URI	URI of a particular item
doc.edition	0..1	URI	URI of a particular edition
doc.confirm	0..1	confirmation	Confirmation

response fields

name	occ	data type	description
doc	1..n	document	list of documents (order is irrelevant)

3.6 fees

purpose

Look up current fees of a patron.

HTTP verb and URL

GET https://example.org/core/{uri_escaped_patron_identifier}/fees

scope

read_fees

response fields

name	occ	data type	description
amount	0..1	money	sum of all fees. May also be negative.
fee	0..n	array	list of fees
fee.amount	1..1	money	amount of a single fee
fee.date	0..1	date	date when the fee was claimed
fee.about	0..1	string	textual information about the fee
fee.item	0..1	URI	item that caused the fee
fee.edition	0..1	URI	edition that caused the fee
fee.feetype	0..1	string	textual description of the type of service that caused the fee
fee.feeid	0..1	URI	URI of the type of service that caused the fee

A PAIA server MUST return identical values of fee.feetype for identical fee.feeid and identical content language. PAIA clients MAY override the value of fee.feetype based on fee.feeid and a preferred language.

If a fee was caused by a document (fee.item or fee.edition is set) then fee.feeid SHOULD be taken as http://purl.org/ontology/dso#DocumentService if not given and SHOULD be a class URI from the Document Service Ontology otherwise. If the fee was confirmed with a confirmation, the value of fee.feeid SHOULD be the value of the confirmed condition option.

4.1 login

The PAIA auth login method is the only PAIA method that does not require an access token as part of the query.

purpose

Get a patron identifier and access token to access patron information

URL

POST https://example.org/auth/login (in addition a PAIA auth server MAY support HTTP GET requests)

request parameters

name	occ	data type
username	1..1	string	User name of a patron
password	1..1	string	Password of a patron
grant_type	1..1	string	Fixed value set to “password”
scope	0..1	string	Space separated list of scopes

If no scope parameter is given, it is set to the default value read_patron read_fees read_items write_items for full access to all PAIA core methods (see access tokens and scopes).

The response format is a JSON structure as defined in section 5.1 (successful response) and section 5.2 (error response) of OAuth 2.0. The PAIA auth server MAY grant different scopes than requested for, for instance if the account of a patron has expired, so the patron should not be allowed to request and renew new documents.

response fields

name	occ	data type	description
patron	1..1	string	Patron identifier
access_token	1..1	string	The access token issued by the PAIA auth server
token_type	1..1	string	Fixed value set to “Bearer” or “bearer”
scope	1..1	string	Space separated list of granted scopes
expires_in	0..1	nonnegative integer	The lifetime in seconds of the access token

POST /auth/login
Host: example.org
User-Agent: MyPAIAClient/1.0
Accept: application/json
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=alice02&password=jo-!97kdl%2B0tt

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-OAuth-Scopes: read_patron read_fees read_items write_items
Cache-Control: no-store
Pragma: no-cache

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "patron": "8362432",
  "scope": "read_patron read_fees read_items write_items"
}

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Pragma: no-cache
WWW-Authenticate: Bearer realm="PAIA auth example"

{
  "error": "access_denied",
  "error_description": "invalid patron or password"
}

4.2 logout

purpose

Invalidate an access token

URL

POST https://example.org/auth/logout (in addition a PAIA auth server MAY support HTTP GET requests)

request parameters

name	occ	data type	description
patron	1..1	string	patron identifier

response fields

name	occ	data type	description
patron	1..1	string	patron identifier

The logout method invalidates an access token, independent from the previous lifetime of the token. On success, the server MUST invalidate at least the access token that was used to access this method. The server MAY further invalidate additional access tokens that were created for the same patron.

4.3 change

purpose

Change password of a patron

URL

POST https://example.org/auth/change

scope

change_password

request parameters

name	occ	data type	description
patron	1..1	string	Patron identifier
username	1..1	string	User name of the patron
old_password	1..1	string	Password of the patron
new_password	1..1	string	New password of the patron

response fields

name	occ	data type	description
patron	1..1	string	patron identifier

The server MUST check

• the access token
• whether username and password match
• whether the user identified by username has scope change_password

A PAIA server MAY reject this method and return an error response with error code access_denied (403) or error code not_implemented (501). On success, the patron identifier is returned.

7.1 Transitions of service states

Six service status data type values are possible. One document can have different status for different patrons and for different times. The following table illustrates reasonable transitions of service status with time for a fixed patron. For instance some document held by another patron is first requested (0 → 1) with PAIA method request, made available after return (1 → 4), picked up (4 → 3), renewed after some time with PAIA method renew (3 → 3) and later returned (3 → 0).

Transitions marked with “/” may also be possible in special circumstances: for instance a book ordered from the stacks (status 2) may turn out to be damaged, so it is first repaired and reserved for the patron meanwhile (status 1). Transitions for digital publications may also be different. Note that a PAIA server does not need to implement all service status. A reasonable subset is to only support 0, 1, 3, and 5.

7.2 Digital documents

The handling of digital documents is subject to frequently asked questions. The following rules of thumb may help:

• For most digital documents the concept of an item does not make sense and there is no URI of a particular copy. In this case the document.edition field should be used instead of document.item.
• For some digital documents there may be no distinction between status provided and status held. The status provided should be preferred when the same document can be used by multiple patrons at the same time, and held should be used when the document can exclusively be used by the patron.

7.3 PAIA core extensions to non-document services

A future version of PAIA may be extended to support services not related to documents. For instance a patron may reserve a cabin or some other facility. The following methods may be added to PAIA core for this purpose:

services

List non-document services related to a patron - similar to method items.

servicetypes

Get a list of services that a patron may request, each with URI, name, and short description.

8.1 Normative References

• Bradner, S. 1997. “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels”. http://tools.ietf.org/html/rfc2119.

• Crockford, D. 2006. “RFC 6427: The application/json Media Type for JavaScript Object Notation (JSON)”. http://tools.ietf.org/html/rfc4627.

• Fielding, R. 1999. “RFC 2616: Hypertext Transfer Protocol”. http://tools.ietf.org/html/rfc2616.

• D. Hardt. 2012. “RFC 6749: The OAuth 2.0 Authorization Framework”. http://tools.ietf.org/html/rfc6749.

• Jones, M. and Hardt, D. 2012. “RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage”. http://tools.ietf.org/html/rfc6750.

• van Kesteren, Anne. 2014. “Cross-Origin Resource Sharing” http://www.w3.org/TR/cors/

• Rescorla, E. 2000. “RFC 2818: HTTP over TLS.” http://tools.ietf.org/html/rfc2818.

8.2 Informative References

• 3M. 2006. “3M Standard Interchange Protocol Version 2.00“. http://mws9.3m.com/mws/mediawebserver.dyn?6666660Zjcf6lVs6EVs66S0LeCOrrrrQ-.

• ILS-DI. 2008. “DLF ILS Discovery Interface Task Group (ILS-DI) Technical Recommendation - revision 1.1“ http://old.diglib.org/architectures/ilsdi/.

• Katz, D. 2013. “ILS Driver (VuFind 2.x)“. http://vufind.org/wiki/vufind2:building_an_ils_driver.

• NISO. 2010. “NISO Circulation Interchange Protocol (NCIP) - Z39.83-1-2008 Version 2.01“. http://www.ncip.info/.

• Voß, J. 2015. “PAIA Ontology“. http://gbv.github.io/paia-rdf/.

• Voß, J. 2014. “Document Service Ontology“ http://purl.org/ontology/dso.

• “PAIA Wiki“. https://github.com/gbv/paia/wiki

8.3 Revision history

This is version 1.3.0+1 of PAIA specification, last modified at 2015-11-16 with revision ceb14b3.

Version numbers follow Semantic Versioning: each number consists of three numbers, optionally followed by + and a suffix:

• The major version (first number) is increased if changes require a modification of PAIA clients
• The minor version (second number) is increased if changes require a modification of PAIA servers
• The patch version (third number) is increased for backwards compatible fixes or extensions, such as the introduction of new optional fields
• The optional suffix indicates informal changes in documentation