https://en.wikipedia.org/wiki/Networked_Help_Desk is an open standard allowing
multiple issue tracking systems (rt, jira, zendesk, ..._) to share and synchronize
information.

The main web site is: http://networkedhelpdesk.org and the spec is at
http://networkedhelpdesk.org/rfc/

The protocol is rest over http and json. With the merging of the rest interface and
the ability to extend it this should be doable. They have a few requirements such as
a UUID that uniquely identifies a ticket/request across systems. They define this as
a sha1sum over update_url/type/id  so issues.roundup-tracker.org/rest/sharing/issue/2
for sharing issue 2. Similarly users can be shared as the authors of comments.

Sharing relationship is on a per ticket basis so this might add a requirement to
extend a schema with an agreement multilink allowing 1 ticket -> many agreement relations.
Also sharing relationships can be full or partial. The sender determines what can be done.
It looks like the perms are:

   sender -> receiver full delegation:

       receiver can add comments: public (customer viewable) and private (not cust. viewable)
          (in roundup all are public, but a tracker can be built to support private comments)
       status on receiver side is synched to sender

   sender -> receiver partial delegation:

       receiver can send only private comments
       status is not synched

This should be doable with the current roundup permission code. Need to add a validator
that authenticates the user, verifies that there is a full/partial delegation and
creates/sets as appropriate.

It has its own authentication mechanism, so using JWT won't work. However for establishing
agreements, jwt could be used to permit the sender to create an agreement invite/agreement
modification request. Consider core changes/refactoring to allow for authentication plugins
if modification via interfaces.py is not practical.

The protocol uses POST for new issue creation and PUT for update. They allow incomplete PUT's 
where a missing value implies no change to that value as opposed to unsetting the value. This 
is what Roundup's interface permits as well.

Using PUT for creation and PATCH for updates is suggested. In our case POST would always
be used for creation since PUT must be used against an existing URL. PATCH should work as 
expected.

It looks like users may be created as the result of a share. So the author for a comment
update from a jira system will have a uuid for the user in jira and a name. This user
will need to be created in roundup similar to how we autocreate users on email reception
from unknown users.

There is a mechanism for attaching files. It provides a url and a name. A Get on the
URL retrieves the contents of the file on the update origin. Authentication credentials
have to be included in the URL if authentication is needed.

Custom fields ae supported. They suggest name spacing the field names. How mapping is done is 
not specified.

Open questions:

  formatting of comments, what formatting language is used? Is everything turned into
     plain text or is markup (e.g. markdown/rst/jira) included?

  If the status has 5 values in jira but 7 in roundup, how are these mapped? The RFC
    defines only 3 states: "open", "pending", and "solved".