Editing Xerox Network Systems (section)

===Application protocols===

====Courier RPC====
In the original Xerox concept, application protocols such as remote printing, filing, and mailing, etc., employed a [[remote procedure call]] protocol named '''Courier'''.  Courier contained primitives to implement most of the features of Xerox's [[Mesa (programming language)|Mesa programming language]] function calls. Applications had to manually serialize and de-serialize function calls in Courier; there was no automatic facility to translate a function activation frame into an RPC (i.e. no "RPC compiler" was available). Because Courier was used by all applications, the XNS application protocol documents specified only courier function-call interfaces, and module+function binding tuples. There was a special facility in Courier to allow a function call to send or receive bulk data.{{sfn|cisco}}

Initially, XNS service location was performed via broadcasting remote procedure-calls using a series of expanding ring broadcasts (in consultation with the local router, to get networks at increasing distances.) Later, the Clearinghouse Protocol 3-level directory service was created to perform service location, and the expanding-ring broadcasts were used only to locate an initial Clearinghouse.{{sfn|cisco}}

Due to its tight integration with Mesa as an underlying technology, many of the traditional higher-level protocols were not part of the XNS system itself. This meant that vendors using the XNS protocols all created their own solutions for [[file sharing]] and [[Printer (computing)|printer]] support. While many of these 3rd party products theoretically could talk to each other at a packet level, there was little or no capability to call each other's application services. This led to complete fragmentation of the XNS market, and has been cited as one of the reasons that IP easily displaced it.{{sfn|Stephens|1989|p=15}}

====Authentication====
The XNS protocols also included an Authentication Protocol and an Authentication Service to support it. Its "Strong credentials" were based on the same [[Needham–Schroeder protocol]] that was later used by [[Kerberos (protocol)|Kerberos]]. After contacting the authentication service for credentials, this protocol provided a lightweight way to digitally sign Courier procedure calls, so that receivers could verify the signature and authenticate senders over the XNS internet, without having to contact the Authentication service again for the length of the protocol communication session.<ref name=XSIS098404 />

====Printing====
Xerox's printing language, [[Interpress]], was a binary-formatted standard for controlling laser printers.  The designers of this language, John Warnock and Chuck Geschke, later left Xerox PARC to start [[Adobe Systems]].  Before leaving, they realized the difficulty of specifying a binary print language, where functions to serialize the print job were cumbersome and which made it difficult to debug errant printing jobs.  To realize the value of specifying both a programmable and easily debug-able print job in ASCII, Warnock and Geschke created the Postscript language as one of their first products at Adobe.

====Remote Debug Protocols====
Because all 8000+ machines in the Xerox corporate Intranet ran the Wildflower architecture (designed by Butler Lampson), there was a remote-debug protocol for microcode.  Basically, a peek and poke function could halt and manipulate the microcode state of a C-series or D-series machine, anywhere on earth, and then restart the machine.

Also, there was a remote debug protocol for the world-swap debugger.<ref>
{{cite web
| title = World-stop debuggers
| url = https://people.ece.ubc.ca/gillies/pages/note1.html
| date = 1999-01-25
| access-date = 2013-07-05}}</ref>  This protocol could, via the debugger "nub", freeze a workstation and then peek and poke various parts of memory, change variables, and continue execution.  If debugging symbols were available, a crashed machine could be remote debugged from anywhere on earth.