Here are some initial comments.
Tom
At 08:47 10/23/1997 PDT, Ron Bergman wrote:
>I have loaded the following files for the Job MIB Mapping specification:
>
> ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP00.TXT (.DOC)
>
>I would like to review this document at the JMP meeting next week. The
>main subject will be the mapping to jmJobSubmissionId. We need to verify
>that all the necessary formats for jmJobSubmissionId are available in the
>MIB.
>
>Attached is the text version.
>
> Ron Bergman
>
>
>
>
>
>
>
> INTERNET-DRAFT Ron Bergman
> Dataproducts Corp.
> October 15, 1997
>
>
> Job Submission Protocol Mapping Recommendations
> for the Job Monitoring MIB
>
> <draft-ietf-printmib-job-protomap-00.txt>
>
> Expires Apr 15, 1997
>
>
>
> Status of this Memo
>
> This document is an Internet-Draft. Internet-Drafts are working
> documents of the Internet Engineering Task Force (IETF), its areas,
> and its working groups. Note that other groups may also distribute
> working documents as Internet-Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other
> documents at any time. It is inappropriate to use Internet-Drafts
> as reference material or to cite them other than as "work in
> progress".
>
> To learn the current status of any Internet-Draft, please check the
> "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
> Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
> munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
> ftp.isi.edu (US West Coast).
>
> Abstract
>
> This Internet-Draft defines the recommended mapping for many
> currently popular Job submission protocols to objects and
> attributes the Job Monitoring MIB.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Bergman [page 1]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
> TABLE OF CONTENTS
>
> 1.0 INTRODUCTION .....................................................2
> 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL ...........................3
> 2.1 jmJobSubmissionId Mapped to LPR/LPD ..............................4
> 2.2 jmJobIndex Mapped to LPR/LPD .....................................4
> 2.3 Other MIB Objects Mapped to LPR/LPD ..............................4
> 2.4 The Attribute Group Mapped to LPD ................................4
> 3.0 APPLETALK PROTOCOL ...............................................5
> 3.1 jmJobSubmissionId Mapped to AppleTalk ............................5
> 3.2 Other AppleTalk Mappings .........................................5
> 4.0 INTERNET PRINTING PROTOCOL (IPP) .................................5
> 4.1 jmJobSubmissionId Mapped to IPP ..................................6
> 4.2 jmJobIndex Mapped to IPP .........................................6
> 4.3 Other MIB Objects Mapped to IPP ..................................7
> 4.4 The Attribute Group Mapped to IPP ................................7
> 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) ...........................7
> 6.0 DOCUMENT PRINTING APPLICATION (DPA) ..............................8
> 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) ..........................8
> 7.1 jmJobSubmissionId Mapped to NDPS .................................8
> 7.2 jmJobIndex Mapped to NDPS ........................................8
> 7.3 Other MIB Objects Mapped to NDPS .................................8
> 7.4 The Attribute Group Mapped to NDPS ...............................8
> 8.0 PRINTER JOB LANGUAGE (PJL) .......................................9
> 8.1 jmJobSubmissionId Mapped to PJL ..................................9
> 8.2 jmJobIndex Mapped to PJL .........................................9
> 8.3 The Attribute Group Mapped to PJL ................................9
> 9.0 POSTSCRIPT ......................................................10
> 10.0 NETWARE PSERVER ................................................10
> 10.1 jmJobSubmissionId Mapped to PServer ............................10
> 10.2 jmJobIndex Mapped to PServer ...................................10
> 10.3 The Attribute Group Mapped to PServer ..........................10
> 11.0 NETWARE NPRINTER or RPRINTER ...................................11
> 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL ............................11
> 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) ........11
> 14.0 REFERENCES .....................................................11
>
>
> 1.0 INTRODUCTION
>
> The Job Monitoring MIB [JobMIB] is functional with any job submission
Can we find a better word or phrase than "functional with" here?
How about something like:
The Job Monitoring MIB [JobMIB] is intended to be implemented in a device
or server that supports any job submission protocol(s).
> protocol. However, the information available and the method of
> presentation varies significantly by job submission protocol. A common
> method of mapping job submission information to the Job Monitoring MIB
> is essential for interoperability of Job MIB agents and monitoring
> applications. This document defines recommended mappings for most
> popular job submission protocols to insure this compatibility.
>
> All mappings are unidirectional from the job submission protocol to the
> MIB. It is assumed that support of the job submission protocol in the
> printer implies that the reverse information flow is presently defined
> and does not require interaction from the MIB. This mapping is not
> defined in this document as it should be obvious.
>
>
> Bergman [page 2]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
>
> This document refers to system configurations that are defined in the
> Job Monitoring MIB [JobMIB]. For those readers that are familiar with
> the configuration descriptions, a short summary appears here. Please
> see the Job MIB document for further details.
>
> Configuration 1: This is a simple peer-to-peer system which contains
> only a client and a printer. The Job MIB agent is resident in
> the printer.
>
> Configuration 2: This system contains a client, server, and a
> printer. The Jib MIB agent is resident in the server.
>
> Configuration 3: This system, as in configuration 2, contains a
> client, server, and a printer. In this case the Job MIB agent is
> implemented within the printer.
>
> The most important object to be mapped is jmJobSubmissionId, since this
> is the key for the user to locate a submitted job. Therefore,
Add: or client
> jmJobSubmissionId is specified for all job submission protocols defined
> in this document. The remaining objects mapped include only those items
> that have the equivalent information presented to the printer by the job
> submission protocol.
>
>
> 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL
>
> The LPR/LPD printing protocol [LPD] is used with BSD Unix systems in the
> client-server-printer configuration. Usage of the Job Monitoring MIB
> with LPR/LPD will most likely conform to Configuration 3, where the
> monitor application or the server uses SNMP to obtain job information
> from the printer. The client communicates with the Unix server using
> the existing LPD protocol to obtain job information.
>
> The LPR/LPD protocol is also used in the Windows environment to
> implement peer-to-peer printing, as shown in configuration 1. In this
> case, SNMP is used by the client and/or the monitor application to
> obtain the job information.
>
> One of the major problems of LPR/LPD is the large number of vendor
> unique extensions currently used with the protocol and the resulting
> compatibility issues between available implementations. To avoid these
> issues, this mapping of LPR/LPD is restricted to the protocol as defined
> by RFC 1179.
>
> The LPR/LPD protocol transfers print job data and control information in
> separate files, known as the Data File and Control File respectively.
Need a "," ,
> Most of the information concerning the print job is contained in the
> Control File. In many LPD implementations, the Control File is
> transferred following the Data File. Thus much of the information
> concerning the job may not be available until the completion of the data
> transmission.
>
>
>
> Bergman [page 3]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
>
> 2.1 jmJobSubmissionId Mapped to LPR/LPD
>
> The LPR/LPD Receive Data File command contains a parameter which defines
> the name of the data file. This name field is structured as follows:
>
> dfaXXX<host-name> or daXXXX<host-name>
>
> Where XXX or XXXX is the numeric job number assigned by the LPR/LPD
> client submitting the print job. The recommended mapping of this name
> field to jmJobSubmissionId is:
>
> octet 1: '9'
>
> octets 2-40: Contains the <host-name> portion of the name field. If
> the <host-name> portion is less than 40 octets, the
> left-most character in the string shall appear in octet
> position 2. Otherwise, only the last 39 bytes shall be
> included.
Need to indicate that traliing SPACES are used for items shorter than 40.
(The MIB describes the trailing spaces once up front.)
Also this description is much different than (but equivalent to) what
is in the Job Mon MIB. Do you think this is better, so we should change
the MIB? The MIB description is:
'9' octets 2-40: last 39 bytes of the host name with
trailing SPACES that submitted the job to this
server/device using a protocol, such as LPD
[RFC-1179] which includes the host name in the job
submission protocol.
octets 41-48: 8-decimal-digit leading zero
representation of the job id generated by the
by the submitting server (configuration 3)
or the client (configuration 1 and 2), such as in
the LPD protocol.
This format is reserved for clients.
>
> octets 41-48: `00000XXX' or `0000XXXX'.
>
>
> 2.2 jmJobIndex Mapped to LPR/LPD
>
> The job index (jmJobIndex) is assigned by the SNMP job monitoring agent
> and is independent of the XXX (or XXXX) index assigned by the LPR/LPD
> client. This will allow the SNMP agent to track jobs received from
> multiple sources.
>
>
> 2.3 Other MIB Objects Mapped to LPR/LPD
>
> MIB Object | LPR/LPD Parameter
> -----------------------+------------------------------------------------
> jmJobKOctetsRequested | Number of bytes as defined in the Data File
> jmJobOwner | User Identification string in the Control File
Need to identify which ASCII letter code field you mean in above. There
are several.
>
>
> 2.4 The Attribute Group Mapped to LPD
>
> Other attributes that are applicable, but not defined in this section
> such as attributes that map to a vendor unique extension, may also be
> included.
>
> MIB attribute | LPR/LPD information | Data type
> ----------------------+---------------------------------+--------------
> serverAssignedJobName | Name of the data file (note 1) | Octet String
I made the comment last meeting that this MIB attribute should be
jobName(23), not serverAssignedJobName(22), but maybe you have changed
your mind. Or the Job MIB needs some clarification for format 9? The
serverAssignedJobName(22) is only for configuration 3, but LPD can
be used with configurations 1 and 2 as well.
> jobSourceChannelIndex | prtChannelIndex (note 2) | Integer
> queueNameRequested | Queue name from the Data File | Octet String
> fileName | Name of the source file (note 3)| Octet String
> documentName | The document title name (note 3)| Octet String
Need to identify which ASCII letter code field you mean in above. There
are several.
>
>
>
> Bergman [page 4]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
> Notes:
> ------
> 1. See section 2.1 (jmJobSubmissionId).
> 2. Included if the Printer MIB is also supported by the agent.
> 3. The information is optional in the Control File. The attribute
> should be included if present in the Control File.
>
>
> 3.0 APPLETALK PROTOCOL
>
> AppleTalk was originally developed as a peer-to-peer network protocol,
> as described in configuration 1, for use with Apple Macintosh computers.
> Today, print spoolers are also available for use with Macintosh computer
> networks that conform to configurations 2/3. In addition, printing with
> the AppleTalk protocol is supported from both Windows NT servers and
> Novell servers also per configurations 2/3.
>
> The AppleTalk protocol provides very little information that can be used
> with the Job Monitoring MIB. The Macintosh print drivers are able to
> provide information concerning the user and document name but imbed this
> information in the PDL, which is typically PostScript. The preferred
> jmJobSubmissionId is constructed from the information in the PostScript
> file, as defined in section 9.0.
>
>
> 3.1 jmJobSubmissionId Mapped to AppleTalk
>
> An alternative jmJobSubmissionId may be constructed from the Connection
> Identifier contained in the AppleTalk Printer Access Protocol (PAP)
> header. Since the Connection Id is not readily available in any of the
> defined AppleTalk implementations, this approach may be of little
> utility.
>
> octet 1: '?' ***** NEW TYPE CODE ???? *****
Everyone agree to add this format?
>
> octets 2-40: Contains the AppleTalk printer name, with the first
> character of the name in octet 2. (AppleTalk printer
> names are a maximum of 31 characters.)
>
> octets 41-48: `00000XXX', where `XXX' is the decimal representation
> of the Connection Id.
>
>
> 3.2 Other AppleTalk Mappings
>
> No other Job MIB objects or parameters can be derived from information
> available in the AppleTalk headers
>
>
> 4.0 INTERNET PRINTING PROTOCOL (IPP)
>
> The Internet Printing Protocol [IPP] supports printing using any one of
> the three possible configurations. For configuration 2, the mapping
>
>
> Bergman [page 5]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
> defined herein is performed on a server. Otherwise, the mapping is
> performed on an agent within the printer.
>
> 4.1 jmJobSubmissionId Mapped to IPP
>
> IPP contains a rich set of parameters which allow several methods of
> creating the jmJobSubmissionId object. The preferred method is to use
> the IPP job-uri attribute as follows:
>
> octet 1: '4'
>
> octets 2-40: Contains the IPP job-uri job template attribute. If
> the job-uri is less than 40 octets, the left-most
> character in the string shall appear in octet position
> 2. Otherwise, only the last 39 bytes shall be included.
>
> octets 41-48: Contains the job-id job template attribute.
For all three formats, need to add a warning that the range of the
IPP "job-id" attribute could exceed 8 characters, so implementors might
want to limit the range of IPP "job-id" to not exceed 99999999.
>
> If the job-uri is not available to the agent, the job-name job template
> attribute shall be used.
>
> octet 1: '?' ***** New format required ? (1 for clients) *****
Yes, '1' is for clients, but it is IPP clients who assign the "job-name",
so change '?' to '1'. Or do we have some confusion about what is meant
by reserved to clients vs. agents?
>
> octets 2-40: Contains the IPP job-name job template attribute. If
> the job-name is less than 40 octets, the left-most
> character in the string shall appear in octet position
> 2. Otherwise, only the last 39 bytes shall be included.
>
> octets 41-48: Contains the job-id job template attribute.
>
> If both the job-uri and the job-name are not available, the job-
> originating-user job template attribute shall be used.
>
> octet 1: '4'
I think this should be changed from '4' to '8' (which is also reserved
to clients).
>
> octets 2-40: Contains the IPP job-originating-user job template
> attribute. If the job-originating-user name is less
> than 40 octets, the left-most character in the string
> shall appear in octet position 2. Otherwise, only the
> last 39 bytes shall be included.
>
> octets 41-48: Contains the job-id job template attribute.
>
>
> 4.2 jmJobIndex Mapped to IPP
>
> The job index (jmJobIndex) assigned by the SNMP job monitoring agent may
> be identical to the IPP job-id job template attribute if the agent is
> receiving jobs only from a single server or client. If jobs are to be
> received from multiple sources, jmJobIndex and job-id must be
> independent.
ISSUE: Need some discussion here. It would seem to me that an implementation
that supports multiple protocols could assign job ids as the jobs come
in in any protocol. The jobs that are visible via IPP, could either
show all jobs or show only IPP jobs. There is no requirement in IPP that
job-ids step by one. So there could be holes in the IPP job-id values, for
the implementations that couldn't show jobs from other protocols as IPP jobs.
Therefore, I disagree with the last sentence:
> If jobs are to be
> received from multiple sources, jmJobIndex and job-id must be
> independent.
If the jmJobIndex is not the same as the IPP job-id attribute, then
we may need another jobsubmissionID format, so that a client that knows
the IPP "job-id" can find the job. I had hoped that the jmJobIndex
could always be the same as the IPP "job-id" so that we wouldn't
have to add an extra submission id format in which the "job-id" (an integer)
is the input. Though maybe any of the other three ids formats is good
enough?
>
>
>
>
> Bergman [page 6]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
> 4.3 Other MIB Objects Mapped to IPP
>
> MIB Object | IPP Job template attribute
> --------------------------+---------------------------------------------
> jmJobOwner | job-originating-user
> jmJobKOctetsRequested | job-k-octets
> jmJobKOctetsProcessed | job-k-octets-processed
> jmJobImpressionsRequested | job-impressions
> jmJobImpressionsProcessed | job-impressions-completed
> jmJobStateReasons1 | job-state-reasons (note 1)
> jmNumberOfInterveningJobs | number-of-intervening-jobs
>
> Notes:
> ------
> 1. JobStateReasons is a bit map described in one object and three
> attributes. The IPP condition may change one or more of the bits
> in one or more of these Job MIB items.
>
>
> 4.4 The Attribute Group Mapped to IPP
>
> The following mappings are required if the listed IPP job template
> attribute is provided.
>
> MIB attribute | IPP job template attribute | Data type
> ---------------------------+------------------------------+-------------
> jobName | job-name | Octet String
> documentFormat | document-format | Octet String
> jobPriority | job-priority | Integer
> jobHoldUntil | job-hold-until | Octet String
> sides | sides | Integer
Add a note that the mapping is 3 enum values to two integer values
> finishing | finishings | Integer
> printQualityRequested | print-quality | Integer
> printerResolutionRequested | printer-resolution | Integer
> jobCopiesRequested | copies | Integer
> mediumRequested | media | Octet String
> jobSubmissionTime | time-at-pending | Integer
Changes to: time-at-submission
> jobStartedProcessingTime | time-at-processing | Integer
> jobCompletionTime | time-at-completed | Integer
> sheetsRequested | job-media-sheets | Integer
> jobURI | job-uri | Octet String
> jobStateReasonsN | job-state-reasons (note 1) | Integer
> physicalDevice | output-device-assigned | Octet String
> sheetsCompleted | job-media-sheets-completed | Integer
See latest ipp-jmp.doc .pdf that I'll post later today.
>
> Notes:
> ------
> 1. JobStateReasons is a bit map described in one object and three
> attributes. The IPP condition may change one or more of the bits
> in one or more of these Job MIB items.
>
>
> 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS)
>
>
> Bergman [page 7]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
>
>
> 6.0 DOCUMENT PRINTING APPLICATION (DPA)
I'll send this later this weekend in your format.
>
>
> 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS)
>
> Novell Distributed Print Services is a DPA based job submission protocol
> that conforms to configuration 3.
>
>
> 7.1 jmJobSubmissionId Mapped to NDPS
>
> NDPS supports the generation of a properly formatted jmJobSubmissionId
> for use in the Job MIB.
>
>
> 7.2 jmJobIndex Mapped to NDPS
>
> NDPS does not provide a value that can be mapped to jmJobIndex.
>
>
> 7.3 Other MIB Objects Mapped to NDPS
>
> MIB Object | NDPS Parameter
> -----------------------+------------------------------------------------
> jmJobOwner |
>
>
> 7.4 The Attribute Group Mapped to NDPS
>
> The following mappings are required if the listed PJL attribute or
> command option is provided.
>
> MIB attribute | NDPS parameter | Data type
> ---------------------------+------------------------------+-------------
> jobAccountName |
> serverAssignedJobName |
> jobName |
> jobServiceTypes |
> numberOfDocuments |
> fileName |
> documentName |
> jobComment |
> documentFormatIndex |
> documentFormat |
> jobPriority |
> jobProcessAfterDateAndTime |
> jobHoldUntil |
> outputBin |
> sides |
> finishing |
> printQualityRequested |
>
>
> Bergman [page 8]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
> printerResolutionRequested |
> jobCopiesRequested |
> mediumRequested |
> jobSubmissionToServerTime |
> jobSubmissionTime |
>
>
> 8.0 PRINTER JOB LANGUAGE (PJL)
>
> PJL [PJL] has been developed by Hewlett-Packard to provide job control
> information to the printer and status information to applications,
> independent of the PDL. PJL is normally transferred using a traditional
> job submission language such as LPR/LPD or NetWare PServer.
>
>
> 8.1 jmJobSubmissionId Mapped to PJL
>
> PJL has defined the SUBMISSIONID option for the JOB command which
> indicates a properly formatted jmJobSubmissionId for use in the Job MIB.
> The PJL JOB command is presented at the start of a print job with
> options that apply only the attached job. The syntax for this command
> option is:
>
> @PJL JOB SUBMISSIONID = `
`id
string'
'
>
> Driver software that implements this PJL command option must provide the
> `
`id string'
' in one of the client version formats
specified in the Job
> MIB for jmJobSubmissionId.
>
> For drivers that are not able to create the SUBMISSIONID option, it is
> recommended that jmJobSubmissionId format 0 be created by the agent
> using the PJL attribute DocOwner or DocOwnerId.
>
> octet 1: '0'
>
> octets 2-40: Contains the string associated with DocOwner or
> DocOwnerId. If the string is less than 40 octets, the
> left-most character in the string shall appear in octet
> position 2. Otherwise, only the last 39 bytes shall be
> included. If DocOwner or DocOwnerId cannot be obtained,
> this field shall be blank.
>
> octets 41-48: Contains the value of jmJobIndex associated with the
> job.
>
>
> 8.2 jmJobIndex Mapped to PJL
>
> PJL does not provide a value that can be mapped to jmJobIndex.
>
>
> 8.3 The Attribute Group Mapped to PJL
>
>
>
> Bergman [page 9]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
> The following mappings are required if the listed PJL attribute or
> command option is provided.
>
> MIB attribute | PJL attribute or command option | Data type
> ----------------------+----------------------------------+--------------
> jobOwner | DocOwner or DocOwnerId attribute | Octet String
> serverAssignedJobName | DocName attribute or the command | Octet String
> | @PJL JOB Name = `
`string'
' | Octet String
> submittingServerName | SrcServerName attribute | Octet String
> jobOriginatingHost | SrcPort attribute | Octet String
> queueNameRequested | SrcQ attribute | Octet String
> fileName | JobFName attribute | Octet String
> jobComment | JobDesc attribute | Octet String
> jobSubmissionTime | TimeSubmit attribute | Octet String
>
>
> 9.0 POSTSCRIPT
>
>
> 10.0 NETWARE PSERVER
>
> The NetWare PServer job submission protocol is implemented in a client-
> server-printer system on the server to printer link as defined in
> configuration 3.
>
>
> 10.1 jmJobSubmissionId Mapped to PServer
>
> octet 1: '?' ***** New format req'd ??? *****
>
> octets 2-40: Contains the Directory Path Name as recorded by the
> Novell File Server in the queue directory. If the
> string is less than 40 octets, the left-most character
> in the string shall appear in octet position 2.
> Otherwise, only the last 39 bytes shall be included.
>
> octets 41-48: `000XXXXX' The ASCII representation of the Job Number
> as per the queue directory.
>
>
> 10.2 jmJobIndex Mapped to PServer
>
> The job index (jmJobIndex) is assigned by the SNMP job monitoring agent
> and is independent of the Job Number assigned by the NetWare File
> Server. This will allow the SNMP agent to track jobs received from
> multiple sources.
>
>
> 10.3 The Attribute Group Mapped to PServer
>
> The following mappings are required if the listed PServer parameter is
> provided in the Novell File Server queue directory.
>
>
>
> Bergman [page 10]
>
>
> Job Submission Protocol Mapping Recommendations Oct 10, 1997
>
>
>
> MIB attribute | PServer parameter | Data type
> ---------------------------+-----------------------------+--------------
> jobOwner | Client Id Number | Integer
> serverAssignedJobName | Job File Name | Octet String
> queueNameRequested | Queue Id | Integer
> physicalDevice | Server Id Number | Integer
> jobComment | Job Description | Octet String
> jobPriority |
> jobProcessAfterDateAndTime | Target Execution Time | Octet String
> jobHoldUntil |
> jobCopiesRequested | Number of Copies | Integer
> mediumRequested | Form Name | Octet String
> jobSubmittedToServerTime | Job Entry Time | Octet String
>
>
> 11.0 NETWARE NPRINTER or RPRINTER
>
> The NetWare NPrinter/RPrinter protocol was designed to transfer print
> data from a Novell File Server to a printer attached directly to a local
> port (e.g. parallel or serial) on a PC. NPrinter/RPrinter is an
> extremely lightweight printing protocol. Consequently, no information
> required by the Job Monitoring MIB is provided and a meaningful
> jmJobSubmissionId cannot be generated.
>
> It is recommended that an additional job submission layer, such as PJL
> or another vendor private protocol, be included on top of
> NPrinter/RPrinter to provide the required information. The mapping
> should then be performed according to the recommendations of the higher
> layer submission protocol.
>
>
> 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL
>
>
> 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI)
>
>
> 14.0 REFERENCES
>
> [IPP] The Internet Printing Protocol RFC XXXX, Model RFC XXXX
>
> [JobMIB] The Job Monitoring MIB, RFC XXXX, IETF informational document.
>
> [LPD] Line Printer Daemon Protocol, RFC 1179, IETF informational
> document.
>
> [PJL] Printer Job Language Technical Reference Manual, Hewlett-Packard
> part number 5021-0328.
>
> [PrtMIB] The Printer MIB, RFC 1759, IETF standards track document.
>
>
>
>
>
> Bergman [page 11]
>
>