There seem to be two alternatives:
1. The server generates the start sheet and end sheets contents using
one of the PDLs in the device.
2. The device generates the start sheet and end sheets as requested by
the server (which has the option of asking for start, start and end,
and none). The server has to furnish the data to the device to put
on the start and end sheet.
3. Both the server and the device have the capability, and the
customer adminstrator setup up each to use either:
(1) the server's start/end sheet capability in which case the device's
start/end sheet capability isn't used (because the server says it doesn't
want start/end sheets to the device.
(2) the device's start/end sheet capability in which case the server
passes the data on to the device in the protocol.
perhaps depending on the device (some devices having acceptable start/end
sheet capabilities and other devices not being acceptable to the
administrator).
Approach 1 seems the simplest and generates uniform start/end sheets
across all printers from all vendors.
However, approach 1 requires that the device implement multiple-documents
in one job in IPP parlance (multiple jobs in one session in TIP/SI
parlance. Each document in an IPP job (jobs in a TIPSI session) must be
able to be in a specific PDL, since the server has to generate the start/end
sheet in one of the PDLs supported by the printer, which need not be the PDL
that the end-user document is in.
Also approach 1 requires that the finishing must be able to be specified
for combinations of documents in a job (jobs in a session) independently,
so that the start and end sheets can be included or not included in the
stapling, for example.
Thus I think that a requirement for a device implementing a Server
to Device Protocol (TIPSI or IPP) is that it must support multiple
documents in an IPP job (multiple jobs in a single session in TIPSI
parlance).
This is a differennce from the Model conformance requirements, but
Create-Job and Send-Document are well-defined operations in the Model
document.
Tom