PrintBasic:1 Service Template Version 1.01

(1)

1

PrintBasic:1 Service Template Version 1.01

2 3 4

For UPnP™ Version 1.0 Status: Approved Standard Date: August 8, 2002

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

This Standardized DCP has been adopted as a Standardized DCP by the Steering Committee of the UPnP™ Forum, pursuant to Section 2.1(c)(ii) of the UPnP™ Forum Membership

Agreement. UPnP™ Forum Members have rights and licenses defined by Section 3 of the UPnP™ Forum Membership Agreement to use and reproduce the Standardized DCP in UPnP™

Compliant Devices. All such use is subject to all of the provisions of the UPnP™ Forum Membership Agreement.

THE UPNP™ FORUM TAKES NO POSITION AS TO WHETHER ANY INTELLECTUAL PROPERTY RIGHTS EXIST IN THE STANDARDIZED DCPS. THE STANDARDIZED DCPS ARE PROVIDED "AS IS" AND "WITH ALL FAULTS". THE UPNP™ FORUM MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE STANDARDIZED DCPS, INCLUDING BUT NOT LIMITED TO ALL IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OF REASONABLE CARE OR

WORKMANLIKE EFFORT, OR RESULTS OR OF LACK OF NEGLIGENCE.

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

Authors Company

Shivaun Albright Hewlett-Packard

Tom Hastings Xerox

Harry Lewis IBM

Paul Moore Netreon

Peter Zehler Xerox

Gerrie Shults Hewlett-Packard

23

(2)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

2.9. THEORY OF OPERATION...32

2.9.1. Jobs...33

2.9.2. Actions ...33

2.9.3. Events...34

2.9.4. Security ...34

2.9.5. Localization ...34

2.9.6. IPP Data Type mapping to UPnP Data Types ...34

3. XML SERVICE DESCRIPTION ...36

List of Tables

Table 1: Precedence of Production and Layout Job Attributes ...8

Table 2: State Variables...11

Table 2.1: allowedValueList for PrinterState ...14

Table 2.2: allowedValueList for PrinterStateReasons ...15

Table 2.3: allowedValueList for XHTMLImageSupported ...16

Table 2.4: allowedValueList for ColorSupported ...16

Table 2.5: allowedValueList for DocumentFormat ...18

Table 2.6: allowedValueList for Sides ...19

Table 2.7: allowedValueList for NumberUp ...19

Table 2.8: allowedValueList for OrientationRequested...20

Table 2.9: allowedValueList for MediaSize ...21

Table 2.10: allowedValueList for MediaType...22

Table 2.11: allowedValueList for PrintQuality...22

Table 3: Event Moderation ...23

Table 4: Synchronization of Evented Variables ...25

Table 5.: Transition Actions Used in Table 4...26

Table 6: Actions ...27

Table 7: Arguments for CreateJob ...28

Table 8: Arguments for CancelJob ...29

Table 9: Arguments for GetPrinterAttributes...30

Table 10: Arguments for GetJobAttributes ...30

Table 11: Common Error Codes...32

Table 12: Basic IPP data type mappings ...34

(4)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

108 109 110 111 112

Table 13: Derived data type mappings ...35 Table 14: Structured Data Type mapping...35

List of Figures

Figure 1 - Printer Device and Services...33

(5)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

113 114 115 116 117 118

119

120 121 122

123 124 125

126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144

1. Overview and Scope

This service definition is compliant with the UPnP Device Architecture version 1.0.

This service-type enables the following functions:

• Printing

This service template does not address:

• Faxing

2. Service Modeling Definitions

2.1. ServiceType

A service that is compliant with this template is identified with the following service type: urn:schemas-upnp- org:service:PrintBasic:1.

2.2. Terminology

This section defines terms that are used throughout this specification. These terms are always capitalized in order to indicate that they have the meaning defined in this section.

2.2.1. Conformance Terminology

The following terms have special meaning relating to conformance and so are always indicated in all capital letters:

a) MUST - This word, or the term "REQUIRED", mean that the definition is an absolute requirement of the specification.

b) MUST NOT - This phrase means that the definition is an absolute prohibition of the specification.

c) SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

d) SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

e) MAY - This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. An implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option

(6)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169

170 171 172 173

174 175 176 177 178 179 180 181 182

2.2.2. Other terminology

This document uses the terminology defined in the UPnP Architecture document, such as: action, SST variable, and action parameter. This sub-section defines the following additional terms which are capitalized in order to indicate their specific meaning as defined in this section.

a) Print Service (or Printer) - the UPnP entity that accepts actions from UCP (clients), returns responses, and sends events.

b) PDL Data Stream - the stream of data to be printed as represented in a specified document format.

c) Production Job Attributes - job attributes that are not inherent to the PDL Data Stream and so the UCP MAY override the PDL Data Stream instructions, if any, by supplying corresponding IN parameters when submitting the job (see section 2.4).

d) Layout Job Attributes - job attributes that are inherent to the PDL Data Stream and cannot be overridden by supplying corresponding IN parameters when submitting the job (see section 2.4).

e) Comma Separated Value (CSV) - a variable that contains multiple string values separated by the US-ASCII COMMA (‘,’) character (see section 2.5.1.1).

f) Distinguished Value – a special value defined by this specification for some action IN parameters. Use of Distinguished Value IN parameter allows a PDL Data Stream corresponding value to take effect when it would normally be overridden by the IN parameter. In the case where the Distinguished Value is absent in the PDL data stream and the IN parameter value is specified as ‘device-setting’, the Service uses its

<defaultValue> value for the IN parameter. See section 2.6.2.

g) Tracked Job - a UPnP or non-UPnP job that is visible to a UPnP control point, i.e., has a JobId and appears in the JobIdList, and on which the control point can perform any of the Job operations defined in this document.

h) Untracked Job - a non-UPnP job that is not visible to a UPnP control point, i.e., does not have a JobId and does not appear in the JobIdList, and on which the control point cannot perform any of the Job operations defined in this document.

2.2.3. Notation: use of quotation marks

Throughout this document, single quotes (‘) are used around literal string and integer values in running text, but not in Tables. The single quotes are not part of the values. Double quotes (“) are used around words in running text to indicate special English meanings. Variable names, parameters names, and action names are not quoted.

2.3. References

This section lists the references that this document refers to and the tag inside square brackets that is used for each such reference:

[DEVICE] - UPnP Device Architecture, version 1.0.

[HTTP] - RFC 2616 “Hypertext Transfer Protocol -- HTTP/1.1”, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L.

Masinter, P. Leach, T. Berners-Lee. June 1999. (Format: TXT=422317, PS=5529857, PDF=550558 bytes) (Obsoletes RFC2068) (Updated by RFC2817) (Status: DRAFT STANDARD)

[MODEL] - RFC 2566 “Internet Printing Protocol/1.0 Model and Semantics”, March 1999 and RFC 2911 “Internet Printing Protocol/1.1 Model and Semantics”, September 2000, standards. Available at: http://www.ietf.org

(7)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

183 184 185 186 187 188 189 190 191 192

193 194 195 196 197 198

199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220

[PWG5101.1] IEEE-ISTO 5101.1-2001 Media Standardized Names <work in progress>, ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf, .doc, .rtf for standardized names

[UPnP-ENHANCED] - Albright, S., Hastings, T., Zehler, P., and G Shults, "PrintEnhancedLayout:0.10 Service Template For UPnP Version 1.0", work in progress, TBD, 2001.

[XHTML-PRINT] - “XHTML (tm) - Print”, version 0.60, May 11, 2001, <work in progress>, Available at:

ftp://ftp.lexmark.com/pub/standards/xhtml-print.pdf

[MULTIPLEXED] - R. Herriot, "The MIME Application/Multiplexed Content-type", June 26, 2001, available at:

http://search.ietf.org/internet-drafts/draft-herriot-application-multiplexed-04.txt (Subsequent versions, if any, will be available from the same location with the “04” incremented, and eventually as an information RFC.)

2.4. Intent of a Print Job

The intent of a Print job is indicated by the job attributes as represented by either:

- the IN parameters of the CreateJob action and/or - the print instructions in the PDL Data stream.

Many job attributes MAY be specified by either or both methods. This section defines the precedence between these two representations of the intent of a print job.

2.4.1. Production vs. Layout Job Attributes

This specification distinguishes two classes of such job attributes—Production and Layout. A Layout Job Attribute is one that is inherent to the print output and cannot be overridden by IN parameters when the job is created. A Production Job Attribute is one that can reasonably change at the different times when the job is printed without affecting important job characteristics. Obvious examples of Production Attributes are number of copies, number of sides and number of logical pages per physical sheet of paper, provided that when such Production Attributes are represented in the PDL Data Stream they are represented as print instructions. However, if number of copies or number of logical pages per physical sheet of paper is represented by repetitions of the PDL Data Stream, instead of a print instruction in the PDL Data Stream, such a representation is not considered a Production Job Attribute and so an IN parameter does not override such a representation.

Job attributes are partitioned between Production and Layout as follows:

Production Job Attributes (Job Attributes takes precedence):

JobName

JobOriginatingUserName Copies

Sides NumberUp PrintQuality

Layout Job Attributes (data stream takes precedence):

OrientationRequested MediaSize

MediaType

(8)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

221 222 223 224 225 226 227 228 229

2.4.2. Precedence of Production vs. Layout Job Attributes

The UCP MUST supply an allowed value for each of the IN parameters defined for the CreateJob action (see section 2.8.1) or CreateEnhancedJob (see [UPnP-ENHANCED]). The PDL Data Stream MAY also have a value for any Production or Layout attribute represented as a print instruction. The UCP MAY supply the Distinguished Value defined by this document for each IN parameter to request the Printer to use its <defaultValue> value (see section 2.2.2, term f) and section 2.6.2) in case the corresponding print instruction in the PDL Data Stream is absent.

The Printer SHOULD take the following action depending on the values supplied by the UCP in the CreateJob IN parameter and supplied in the PDL Data Stream for each given job attribute:

Table 1: Precedence of Production and Layout Job Attributes Type of job attribute IN parameter PDL Data Stream Printer SHOULD

Production attribute: <Distinguished Value> absent use <defaultValue> in SCPD

X absent use X

<Distinguished Value> Y use Y

X X use X

X Y use X (IN higher than PDL) **

Layout attribute: <Distinguished Value> absent use <defaultValue> in SCPD

X absent use X

<Distinguished Value> Y use Y

X X use X

X Y use Y (PDL higher than IN) **

230 231 232 233 234

235

236 237

238 239 240 241 242 243 244 245 246 247

** Only when both are supplied, does the precedence depend on whether the attribute is a Production Attribute or a Layout Attribute. Production IN parameters take precedence, while Layout PDL print instructions take precedence.

NOTE: Even for Layout Attributes, the IN parameter value supplied in the CreateJob action will be used as long as no overriding value is found in the PDL Data Stream itself.

2.5. State Variables

2.5.1. Derived data types

This section defines some derived data types that are represented as UPnP string data types with special syntax.

2.5.1.1. Comma Separated Value (CSV) Lists

The UPnP printer service uses variables that represent lists, or one-dimensional arrays, of values. Examples include the supported sets of document formats and media stock. The UPnP Device Architecture, Version 1.0 [DEVICE], does not provide for either an array type or a list type, so a list type is defined here. Lists may either be

homogeneous (all values are the same type) or heterogeneous (values of different types are allowed). The data type of a homogeneous list is string (CSV x), where x is the type of the individual values. The data type of a

heterogeneous list is of the form string (CSV x,y,z), where x, y and z are the types of individual element values. If the number of elements in the heterogeneous list is too large to show each type individually, that variable type is represented as string (CSV heterogeneous), and the variable description includes additional information as to the expected sequence of values appearing in the list and their corresponding types.

(9)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

248 249 250 251 252 253 254 255 256 257 258 259 260 261

o A list is represented as a UPnP String type.

o Values within a list are separated by commas.

o Only three value types are used as CSV elements in this specification—string, integer and boolean.

o Integer values are represented in CSVs with the same syntax as the int data type specified in [DEVICE]

(i.e., optional leading sign, optional leading zeroes)

o Boolean values are represented in CSVs as either ‘0’ for false or ‘1’ for true (which is a subset of the defined boolean data type values specified in [DEVICE]: ‘0’, ‘false’, ‘no’, ‘1’, ‘true’, ‘yes’.

o String values are represented in CSVs with the same syntax as the string data types specified in [DEVICE]

(i.e., any Unicode string), with two exceptions that are represented using a backslash escape character:

o The comma (‘,’) is represented as ‘\,’.

o The backslash (‘\’) is represented as ‘\\’.

o Any white space before, after, or interior to a string value is part of that string value. White space before, after, or interior to any other data type is not allowed.

Examples:

Type refinement of string

Value Comments

CSV string text/xml,application/vnd.hp- PCL,application/postscript

List of three document types

CSV int 1,-5,006,0,+7 List of 5 integers.

CSV boolean 0,1,1,0 List of 4 booleans

CSV string Smith\, Fred,Jones\, Davey List of 2 user names,

“Smith, Fred” and

“Jones, Davey”

CSV i4,string,u2 -29837, string with leading blanks,0 Note that the second value is

“ string with leading blanks”

CSV i4 3, 4 Illegal CSV. White space is not

allowed as part of an integer value.

CSV string ,, List of 3 empty string values

CSV heterogeneous Alice,Marketing,5,Susan,R&D,21,David,Finance,7 List of unspecified number of people and associated attributes.

Each person is described by 3 elements, a name string, a department string and years-of- service u2.

262

263 264 265 266 267 268 269 270 271 272

2.5.1.2. State variables, actions and action parameters

All state variables, actions and action parameters are mixed case with the first letter of each word being capitalized.

Most of these variables, actions and parameters are derived directly from IPP by removing the hyphens and up- casing the first letter of each word. Unless specified otherwise, all variable values and action parameter values are all lower case with hyphens, same as in IPP. See Internet Printing Protocol/1.0 Model and Semantics (RFC 2566) and Internet Printing Protocol/1.1 Model and Semantics (RFC 2911), hereafter referred to as [MODEL]. The action and attribute descriptions in these tables are only a brief summary. Implementations MUST conform to the

complete semantics specified in these referenced documents for each attribute indicated with [MODEL] in order to achieve the kind of interoperability between client and Printer implementations of different vendors IPP has demonstrated. A full description of their meaning can be found in the indicated sections in [MODEL].

(10)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

273 274 275 276

277 278 279 280 281 282 283 284 285 286 287 288 289 290 291

292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317

2.6. Service State Table

A conforming UPnP Print Service implementation MUST support all of the Printer Service State Variables in the Service State Table (SST). The first part of the Service State Table contains variables that represent Printer attributes and the second part contains variables that represent Job attributes.

2.6.1. The Printer’s supported and default values

The table below defines “Allowed Values” for each SST variable. The values in a Service Description’s

<allowedValueList> element are the actual values supported by the Print Service instance (Printer).

Each SST variable definition in this document specifies whether or not vendors in their Service Description MAY subset and/or extend the <allowedValueList> element in their Service Description from those “Allowed Values”

values given in this document. The Printer’s “current” <allowedValueList> and <defaultValue> values may or may not be the same as the factory supported and default values, respectively, for that parameter, i.e., someone may have changed the settings from the factory-supplied values. Any <allowedValueList> and <defaultValue> element value MAY be changed at any time after Service Discovery. Furthermore, the current <allowedValueList> and

<defaultValue> values for a job parameter could also possibly change between invocations of the action that uses it, for example, if someone reconfigures the Printer’s “current” device setting for that parameter. However, the UPnP Device Architecture, version 1.0 [DEVICE], states that any change to the <allowedValueList> or <defaultValue>

element requires the printer to issue an “ssdp:byebye” and then re-advertise itself. Each of the values in the

<defaultValue> elements is implementation specific, but MUST be one of the values from the Service Description’s associated <allowedValueList> element, if present.

2.6.2. The Distinguished Value used to avoid action override of PDL

Some Print Service actions have IN parameters that will always override any corresponding value that might be provided in the PDL data stream (see section 2.4.2). For those situations where the UCP prefers to let the PDL data stream value override the IN parameter, the PrintBasic Service has added the Distinguished Value ‘device-setting’

to the <allowedValueList> of the associated state variable. In the case where the Distinguished Value is absent in the PDL data stream and the IN parameter value is specified as ‘device-setting’, the Service uses its <defaultValue>

value for the IN parameter. For example, see CreateJob action, section 2.8.1. When the UCP supplies the Distinguished Value for such an IN parameter, the Print Service MUST process the action following the

corresponding print instruction in the PDL Data Stream, if present. If absent, the Print Service MUST process the action as if the Service’s then current <defaultValue> for that IN parameter value had been supplied by the UCP. In other words, the Service’s then current <defaultValue> value has lower precedence than the PDL Data Stream. All implementations MUST support all Distinguished Value parameters defined herein. The two preceding

requirements also mean that the Distinguished Value for a variable MUST be included in the variable’s allowed value set, even if the vendor is subsetting the allowed value set. However, the Distinguished Value itself MUST NOT be used for the actual value of the <defaultValue> element in the SCPD. Note: the Distinguished Values defined herein for a variable/parameter are not otherwise valid values for the variable/parameter.

The value used as the Distinguished Value for a parameter, is specified in the definition of the parameter’s

associated state variable. This guarantees uniqueness of the Distinguished Value across all actions that might use it.

Any vendor extensions to the set of Print Service actions that use IN parameters with an associated variable that has a defined Distinguished Value SHOULD also support the use of Distinguished Values in their action invocations.

Any vendor extension that does support such Distinguished Values in their actions MUST use the same

Distinguished Value that is defined in this document. While vendors may use the Distinguished Value concept in their Print Service extensions, this specification provides no mechanism for indicating either that Distinguished Values are supported or the actual Distinguished Value used for a specific variable/parameter.

The Distinguished Value for all string variables defined herein is the string ‘device-setting’. For any vendor extensions, the Distinguished Value for all string variables MUST be ‘device-setting’. The Distinguished Value for

(11)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

318 319

320 321 322 323 324 325 326 327

all integer variables defined herein is the value ‘0’. For any vendor extensions, the Distinguished Value for integer variables SHOULD be ‘0’ (or ‘-1’ if ‘0’ is otherwise a useful value).

2.6.3. Purposes of the SST State Variables

The first part of the SST defines the Printer attributes. The second part of the SST defines the Job attributes. Many of the Job attributes in the SST are present solely for the purpose of meeting the UPnP Device Architecture

[DEVICE] requirement that all action parameters MUST have a related SST variable. The full specification for such action parameters is given with the variable in the SST. Some of the Printer attributes can be queried with the GetPrinterAttributes action (see section 2.5.3) and some of the Job attributes can be queried for a specified job with the GetJobAttributes action (see section 2.5.4)

Table 2: State Variables

Variable Name Req.

or Opt.¹

Data Type

Allowed Value Default Value Eng.

Units

Printer Attributes

VariableName R string TBD DEFAULT TBD

PrinterName R string <implementation specific> N/A

PrinterLocation R string <implementation specific> N/A

DeviceId R string <implementation specific> N/A

PrinterState R string See section 2.6.7 idle N/A

PrinterStateReasons R string See section 2.6.8 none N/A

XHTMLImageSupported R string See section 2.6.9 image/jpeg N/A

ColorSupported R boolean See section 2.6.10 <implementation specific> N/A

JobIdList R string

(CSV i4)

See section 2.6.11 <empty String> N/A

JobId R i4 Range: 0 to 2³¹-1 0 N/A

JobEndState R string

(CSV i4,string, string,i4, string)

See section 2.6.13 <empty String> N/A

(12)

Variable Name Req.

or Opt.¹

Data Type

Allowed Value Default Value Eng.

Units

Job Attributes

JobName R string <empty string> N/A

JobOriginatingUserName R string <empty string> N/A

DocumentFormat R string See section 2.6.16 <implementation specific>

RECOMMENDED value:

application/vnd.pwg-xhtml- print+xml

See Note below.

N/A

Copies R i4 Range: 0 to 2³¹-1 <implementation specific>

RECOMMENDED value: 1

N/A

Sides R string See section 2.6.18 <implementation specific>

one-sided

N/A

NumberUp R string See section 2.6.19 <implementation specific>

RECOMMENDED value: 1

N/A

OrientationRequested R string See section 2.6.20 <implementation specific>

portrait

N/A

MediaSize R string See section 2.6.21 <implementation specific> N/A MediaType R string See section 2.6.22 <implementation specific>

Stationery (if supported)

N/A

PrintQuality R string See section 2.6.23 <implementation specific>

normal

N/A

DataSink R uri <empty string> N/A

JobMediaSheetsCompleted R i4 Range: -1 to 2³¹-1 0 N/A

Non-standard state variables implemented by a UPnP vendor go here.

X TBD TBD TBD TBD

1 R = REQUIRED, O = Optional, X = Non-standard.

328 329 330 331

332 333 334 335 336 337

NOTE: The value “application/vnd.pwg-xhtml-print+xml” MUST be shortened to 31 characters for

interoperability reasons. This value MUST be: “application/vnd.pwg-xhtml-print”. Any additional values that are used by a vendor MUST also be 31 characters or less for interoperability.

2.6.4. PrinterName

The administratively assigned user-friendly name of the Printer. How the Printer's Service Description

<defaultValue> element is configured with this value is implementation-specific, e.g., local console, Presentation Service (web access). If the Device Service has only one device, then the Device’s <friendlyName> and

PrinterName are recommended to have the same value. However, if the Device contains several devices, the PrinterName identifies the Printer.

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

(13)

(See [MODEL] section 4.4.4) 338

339 340 341 342

2.6.5. PrinterLocation

Indicates the location of the device. For example, “Bobby’s room”. How the Printer's Service Description

<defaultValue> element is configured with this value is implementation-specific, e.g., local console, Presentation Service (web access).

343

344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377

(See [MODEL] section 4.4.4)

2.6.6. DeviceId

The value of this variable MUST exactly match the IEEE 1284-2000 Device ID string, except the length field MUST not be specified.. The value is assigned by the Printer vendor and MUST NOT be localized by the Print Service.

The IEEE 1284-2000 Device ID is a length field followed by a case-sensitive string of ASCII characters defining peripheral characteristics and/or capabilities. For the purposes of this specification, the length bytes MUST NOT be included. The Device ID sequence is composed of a series of keys and values of the form:

key: value {,value} repeated for each key

As indicated, each key will have one value, and MAY have more than one value. The minimum necessary keys (case- sensitive) are MANUFACTURER, COMMAND SET, and MODEL. (These keys MAY be abbreviated as MFG, CMD, and MDL respectively.) Each implementation MUST supply these three keys and possibly additional ones as well. Each key (and each value) is a string of characters. Any characters except colon (:), comma (,), and semi- colon (;) MAY be included as part of the key (or value) string. Any leading or trailing white space (SPACE[x'20'], TAB[x'09'], VTAB[x'0B'], CR[x'0D'], NL[x'0A'], or FF[x'0C']) in the string is ignored by the parsing program (but is still counted as part of the overall length of the sequence).

An example ID String, showing optional comment and active command set keys and their associated values (the text is actually all on one line):

MANUFACTURER:ACME Manufacturing;

COMMAND SET:PCL,PJL,PS,XHTML-Print+xml;

MODEL:LaserBeam 9;

COMMENT:Anything you like;

ACTIVE COMMAND SET:PCL;

(See IEEE 1284-2000 clause 7.6)

Note: One of the purposes of the DeviceId variable is to select a printer driver for those UCPs that need a printer driver. The values of the COMMAND SET key are interpreted by the printer driver provided by the vendor and so are vendor-defined, rather than being standardized.

2.6.7. PrinterState

Identifies the current state of the service. Values:

idle - new jobs can start processing immediately without waiting.

processing - jobs (Tracked or Untracked) are processing; new jobs will wait before processing, i.e., are said to be pending.

stopped - no jobs can be processed and intervention is needed.

(See [MODEL] section 4.4.11)

Vendors MUST NOT subset or extend allowed values.

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

(14)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

378 Table 2.1: allowedValueList for PrinterState

Value Req. or Opt.

idle R processing R stopped R 379

380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414

2.6.8. PrinterStateReasons

Indicates additional information about why the Printer is in its current state. Multiple conditions MAY exist. The vendor chooses the single value for PrinterStateReasons variable to indicate the most important condition.

Note: some of these reasons describe state of the printer that cannot be entered on the basis of the currently defined UPnP actions set. For example the printer can be ‘paused’; there is no PausePrinter action. The reason these states are presented is because some other protocol (or console action) can have caused the printer to enter that state.

Reason values:

none- Indicates that there are no current state reasons

attention-required - The device has stopped for a reason other than the PrinterStateReasons listed here and requires human intervention before it can continue.

media-jam - The device has a media jam.

paused - Someone has paused the printer and the PrinterState is 'stopped'. In this state, a Printer will not produce printed output.

door-open - One or more covers on the device are open.

media-low - At least one input tray is low on media.

media-empty - At least one input tray is empty.

output-area-almost-full - One or more output area is almost full (e.g. tray, stacker, collator).

output-area-full - One or more output area is full, e.g.,. tray, stacker, collator.

marker-supply-low- The device is low on at least one marker supply, e.g., toner, ink, ribbon.

marker-supply-empty - The device is out of at least one marker supply, e.g., toner, ink, ribbon.

marker-failure - The device has at least one marking device which has failed and requires service or replacement.

media-change-request - A job has been submitted that is requesting media that is currently not loaded. The job has specified a particular MediaSize and MediaType parameter value combination that is not loaded, although the Printer supports that combination.

(See [MODEL] section 4.4.12. The IPP severity suffix MUST NOT be included and, unlike IPP, only one value MUST occur at a time.)

Vendors MUST support the values that represent conditions that are detectable in their implementation. Therefore, vendors MAY subset allowed values if specific PrinterStateReasons are undetectable in their implementation.

Vendors MAY extend allowed values. However, Printer vendors need to understand the implications of extending this list on a UCP. The UCP usually localizes the PrinterStateReasons value (as with other string variable values) to the human language of the user. However, such a Printer vendor extension value will not be recognized by the UCP. As a Fallback presentation, the UCP MAY display the value received as is, which should be in English and therefore, might not be understandable by the user. Alternatively, the vendor might use the general

PrinterStateReasons value: ‘attention-required’ and then explain the problem on the Printer console which the user would see when they are by the Printer.

(15)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

415 Table 2.2: allowedValueList for PrinterStateReasons

Value Req. or Opt. ³

none R

attention-required O

media-jam O

paused O

door-open O

media-low O

media-empty O

output-area-almost-full O

output-area-full O

marker-supply-low O

marker-supply-empty O

media-change-request O

Vendor-defined O

3 Vendors MUST support the values that represent conditions that are detectable in their implementation 416

417 418 419 420 421 422 423 424 425 426 427

2.6.9. XHTMLImageSupported

Identifies the Image formats supported by the Printer. The image MUST be sent as part of an XHTML-Print document[XHTML-PRINT], either interleaved within XHTML-Print using the MIME Application/Multiplexed Content Type [MULTIPLEXED] or as a referenced object. The Printer MUST support both the inline and referenced object forms as defined in XHTML-Print [XHTML-PRINT]. A printer device vendor MAY choose to support other XHTMLImageSupported formats, however, there is no requirement to support the MIME Application/Multiplexed Content Type [MULTIPLEXED] for these other image formats.

All UPnP printers MUST support at least the ‘image/jpeg’ image format.

Vendors MAY extend the allowed values for this attribute.

Note: ‘image/jpeg’ is registered as a MIME Media Type with IANA.

(16)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

428 Table 2.3: allowedValueList for XHTMLImageSupported

image/jpeg R

Vendor-defined O

429 430 431 432 433 434 435 436 437 438 439

2.6.10.ColorSupported

Identifies whether or not the device is capable of multi-hued color printing. A printer that is capable of full color output has a value of ‘1’ (TRUE). A grayscale capable or business graphics capable printer has the value of ‘0’

(FALSE), as would a highlight printer.

(Note: though this variable is named the same as the corresponding IPP “color-supported” (boolean) Printer attribute, the semantics differ: A UPnP Printer must be capable of full color output in order to have a ‘1’ (TRUE) value. See [MODEL] section 4.4.26)

All UPnP printers MUST support either the ‘0’ or the ‘1’ value.

Vendors MUST NOT extend the allowed values for this attribute.

Table 2.4: allowedValueList for ColorSupported

0 O

1 O

440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461

2.6.11.JobIdList

The list of JobId values for all tracked jobs known by the Print Service, i.e. all active and queued jobs, but NOT jobs that have completed, been aborted by the print service, or canceled. It is RECOMMENDED that jobs submitted to the Printer by protocols other than UPnP be represented in JobIdList.

The list is a sequence of Comma Separated i4 Values (CSV i4 - see section 2.5.1.1). Each value is a JobId of a job on the printer. The values range from 1 to 2³¹-1. The list is in the order that the jobs are expected to be completed.

The first job in the list is either currently printing, attempting to print (but the Printer is stopped), or is the next job to print (if no jobs are currently printing or all jobs are in the ‘pending-held’ state). The last job in the list will be printed last. The first JobId in the list is removed when the job completes or is aborted. The corresponding JobId in the list is removed when a job is canceled (see section 2.8.2).

When all jobs are completed, cancelled or aborted, the JobIdList variable is an empty string.

The Print Service, on receipt of a new job, generates a JobId which identifies the new Job on that Print Service.

The JobId is placed in the appropriate place in the JobIdList. The Print Service returns the value of the JobId parameter as part of the response to a CreateJob action.

2.6.12.JobId

The JobId of the current job, i.e., the job that has caused the PrinterState variable to be ‘processing’ or ‘stopped’.

The JobId MUST be the first JobId in the JobIdList or 0. If there is no current job, i.e., the PrinterState is ‘idle’

(there are no jobs, or all jobs are pending or held), then JobId contains a 0 which is an invalid JobId for a job). If JobId is 0, the printer is either idle OR a non-UPnP job is printing (and the Printer implementation has chosen NOT to display non-UPnP jobs, i.e., the job is an Untracked Job).

(See [MODEL] section 4.3.2)

(17)

© 2002 Contributing Members of the UPnP™ Forum. All Rights Reserved.

462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482

483 484 485

486 487 488 489

490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505

2.6.13.JobEndState

This variable holds the “terminating” state of the job most recently removed from the JobIdList. It is evented; it is triggered when any JobId is removed from the JobIdList. However, the JobEndState is not an OUT parameter of any action, so it is not available to a client via polling.

JobEndState is a heterogeneous CSV list of five items: JobId, JobName, JobOriginatingUserName,

JobMediaSheetsCompleted, job-completion-state (same order as the GetJobAttributes OUT parameters, plus the job-completion-state).

JobId: the JobId of the job being removed (see section 2.6.12) JobName: The name of the job. See section 2.6.14.

JobOriginatingUserName: The name of the user that submitted the job. See section 2.6.15.

JobMediaSheetsCompleted: If JobId was the “active” job, i.e., the first job in JobIdList, this is the final value of JobMediaSheetsCompleted for the job. Otherwise, this value is ‘0’. See section 2.6.25.

job-completion-state: One of ‘aborted’, ‘canceled’ or ‘successful’ as defined below:

aborted: The job did not complete successfully, for one of two reasons—either (1) the printer encountered a non-recoverable error while processing the job or attempting to receive the data, or (2) the job was created by the CreateEnhancedJob action (see [UPnP-ENHANCED]) and the printer detected during processing that the job requirements could not be met.

successful: The job printed successfully all of the pages of the job and the sheets have been stacked in the output bin.

canceled: The job was canceled either by a CancelJob action or the equivalent in another protocol.

2.6.14. JobName

The user-friendly name of the job. It is RECOMMENDED that the client (UCP) supply a value to help a user easily distinguish between the jobs that he/she has submitted.

2.6.15. JobOriginatingUserName

The name of the user that submitted the job. Either supplied by the client (UCP) or by the security infrastructure, if any. It is RECOMMENDED that the client (UCP) supply a value to help a user easily distinguish between the jobs that he/she has submitted and jobs that others have submitted.

2.6.16. DocumentFormat

Identifies the DocumentFormat of the job as a mime media type. One special value is 'application/octet-stream'. If the Printer service supports this value, the Printer service MUST be capable of auto-sensing the format of the document data.

Another special value is ‘unknown’. This value is intended for the UCP to supply that does not know the document format of the document data. The behavior of the Printer when receiving the ‘unknown’ value is

IMPLEMENTATION DEFINED. However, if the Printer can perform auto sensing of the data, (the

‘application/octet-stream’ behavior), it is RECOMMENDED that it do so.

If the UCP (client) does not know the document format, it SHOULD supply the ‘application/octet-stream’ value and let the Printer determine the format, unless the Printer doesn’t support the ‘application/octet-stream’ value, in which case the UCP’s only recourse is to supply the special ‘unknown’ value. All UPnP printers MUST support at least the ‘application/vnd.pwg-xhtml-print’ document format[XHTML-PRINT] and the ‘unknown’ value.

The vendors MAY extend the allowed values for this attribute, but MUST NOT support the ‘device-setting’

Distinguished Value. The vendor MAY subset the allowed values as long as ‘application/vnd.pwg-xhtml-print’ and

‘unknown’ remain as supported values.

(18)

506 Table 2.5: allowedValueList for DocumentFormat

unknown R application/vnd.pwg-xhtml-print+xml

See NOTE below.

R

text/plain O text/plain;charset=utf-8 O

application/octet-stream O application/postscript O

application/vnd.hp-PCL O

Vendor-defined O

507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529

NOTE: The value “application/vnd.pwg-xhtml-print+xml” MUST be shortened to 31 characters for

interoperability reasons. This value MUST be: “application/vnd.pwg-xhtml-print”. Any additional values that are used by a vendor MUST also be 31 characters or less for interoperability.

2.6.17. Copies

Contains the number of copies of the document to be printed for the job. See [MODEL] section 4.2.5.

The ‘0’ Distinguished Value indicates that the control point wants the Printer to use its <defaultValue> value for Copies, which MUST be greater than 0, but to allow that value to be overridden if a corresponding value is encountered in the PDL Data Stream.

Vendors MAY subset the allowed values, but MUST support the ‘0’ Distinguished Value.

Vendors MUST NOT extend the allowed values.

2.6.18. Sides

Specifies how pages are to be imposed upon the sides of a selected medium for the job. Values:

one-sided

two-sided-long-edge two-sided-short-edge device-setting

The ‘device-setting’ Distinguished Value indicates that the control point wants the Printer to use its <defaultValue>

value for Side, but to allow that value to be overridden if a corresponding value is encountered in the PDL Data Stream.

Vendors MAY subset allowed values, but MUST support the ‘device-setting’ Distinguished Value.

Vendors MUST NOT extend allowed values.

(19)

530 Table 2.6: allowedValueList for Sides

device-setting R

one-sided R two-sided-long-edge O

two-sided-short-edge O 531

532 533 534

2.6.19. NumberUp

Description: Indicates the number of PDL Data Stream pages to impose upon a single side of an instance of a selected medium for the job. Examples:

1 - One page per side.

535

2 - Two pages per side.

536

4 - Four pages per side.

537 538 539 540 541 542 543 544 545 546

device-setting

The value is represented as ASCII decimal digits without leading zeros, so that the Allowed Values can be represented as individual integer (string) values in the range 1 to 2**31-1.

value for NumberUp, but to allow that value to be overridden if a corresponding value is encountered in the PDL Data Stream.

Vendors MAY subset or extend allowed values, but MUST support the ‘device-setting’ Distinguished Value.

Table 2.7: allowedValueList for NumberUp

device-setting R

1 R

2 O

4 O

Vendor-defined O

547

548 549 550 551

2.6.20. OrientationRequested

Indicates the desired orientation for printed pages for any MIME type format of the job. Which MIME type formats a Printer is able to change the orientation depends on implementation and MAY depend on the actual document content. Values:

portrait 552

landscape 553

reverse-landscape 554

reverse-portrait 555

device-setting 556

(20)

557 558 559 560 561 562 563

(See [MODEL] section 4.2.10 which intends the “orientation-requested” attribute to apply to ‘text’ MIME types.) The ‘device-setting’ Distinguished Value indicates that the control point wants the Printer to use its <defaultValue>

value for OrientationRequested, but to allow that value to be overridden if a corresponding value is encountered in the PDL Data Stream.

Table 2.8: allowedValueList for OrientationRequested

device-setting R

portrait R

landscape O

reverse-landscape O reverse-portrait O 564

565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592

2.6.21. MediaSize

Identifies the medium size name and dimensions that the Printer Service uses for all sheets of the job. Each value MUST include the name of the size followed by the dimensions in inches or millimeters followed by the “in” or

“mm” suffix to indicate the units. Both the Inch and Millimeter dimension MAY include a non-zero decimal fraction set off by a period (.). The name of the size consists of a class part and a name part separated by an underscore (_). The class part MUST be “na”, “asme”, or “oe” for inch units and “iso”, “jis”, “jpn”, “prc”,

“roc”, or “om” for metric units (see [PWG5101.1] for additional class names). The name part is set off by a second underscore (_) and the dimensions are separated by the lower case letter x. The shorter dimension MUST come first. See the Allowed Values for examples.

For sizes that do not have standard names, a UCP or a Print Service can create a customized name using the 'custom_xxx' class and name, where xxx indicates the custom name of the medium, followed by the dimensions in inches or millimeters as for standard names. For example, a custom 3.5 by 5.0 inch medium that, say, represents an index card, could be indicated by the string value:

custom_index-card_3.5x5in

The customized values configured for the Printer MUST be added to the Printer’s <allowedValueList>.

If a Printer supports the control point supplying custom names that are not one of the values in the Printer’s

<allowedValueList> element, the Printer’s <allowedValueList> element MUST include both the

‘custom_max_IIIxJJJmm’ and ‘custom_min_IIIxJJJmm’ (and/or ‘custom_max_IIIxJJJin’ and

‘custom_min_IIIxJJJin’) Allowed Values to indicate the minimum and maximum custom sizes that the Printer will allow the control point to supply.

(See [PWG5101.1] for suggested media size names and their dimensions. These names SHOULD NOT use the

“custom” class name.)

value for MediaSize, but to allow that value to be overridden if a corresponding value is encountered in the PDL Data Stream.

Vendors MAY subset and extend allowed values, but MUST support the ‘device-setting’ Distinguished Value.

How the Printer's Service Description <defaultValue> and <allowedValueList> elements are configured with these values is implementation-specific, e.g., local console, Presentation Service (web access).

(21)

593 Table 2.9: allowedValueList for MediaSize

Value³ Req. or Opt.

device-setting R na_letter_8.5x11in O

na_legal_8.5x14in O iso_a4_210x297mm O iso_c5_162x229mm O iso_dl_110x220mm O jis_b4_257x364mm O

custom_xxx_IIIxJJJmm O custom_xxx_IIIxJJJin O custom_min_IIIxJJJmm O custom_max_IIIxJJJin O Vendor-defined (see [PWG5101.1] O

3 These values represent examples and are not intended to be exhaustive (see [PWG5101.1].

594

595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612

2.6.22. MediaType

Identifies the medium type that the Printer Service uses for all impressions of the job. Example values:

stationery Separately cut sheets of an opaque material transparency Separately cut sheets of a transparent material

envelope Envelopes that can be used for conventional mailing purposes labels Label stock [For example, a sheet of peel-off labels].

photographic Separately cut sheets of an opaque material to produce photographic quality images cardstock Separately cut sheets of an opaque material that is heavier and stiffer than stationery.

device-setting Indicates that the control point wants the Printer to use its <defaultValue> value for MediaType.

The values are a subset of and the descriptions are a taken verbatim from the Media Type Names in [PWG5101.1].

value for MediaType, but to allow that value to be overridden if a corresponding value is encountered in the PDL Data Stream.

Vendors MAY subset or extend allowed values, but MUST support the ‘device-setting’ Distinguished Value. See [PWG5101.1] for additional example values.

How the Printer's Service Description <defaultValue> and <allowedValueList> elements are configured with these values is implementation-specific, e.g., local console, Presentation Service (web access).

(22)

613 Table 2.10: allowedValueList for MediaType

Value³ Req. or Opt.

device-setting R

stationery O

stationery-inkjet O

transparency O envelope O labels O photographic O cardstock O Vendor-defined (see [PWG5101.1] O

3 These values represent examples and are not intended to be exhaustive (see [PWG5101.1].

614

615 616

2.6.23. PrintQuality

Specifies the print quality requested for the job. Values:

draft 617

normal 618

high 619

device-setting 620

621 622 623 624 625 626 627

value for PrintQuality, but to allow that value to be overridden if a corresponding value is encountered in the PDL Data Stream.

Table 2.11: allowedValueList for PrintQuality

device-setting R

draft O normal R high O

628

(23)

629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645

646 647

2.6.24. DataSink

Contains the URL to which the UCP is to send the HTTP Post operation (see section 2.8.5 ) for the job. This value is returned by the Printer in the CreateJob action response, rather than being supplied by the UCP in the CreateJob action request.

2.6.25. JobMediaSheetsCompleted

The number of media sheets completed for the job so far. The JobMediaSheetsCompleted value includes

completion of stacking the output. If a Printer implementation does not know the number of media sheets completed, then it MUST return a -1 value to indicate “unknown”. If JobId is 0, then JobMediaSheetsCompleted MUST be 0 (or -1, if the media sheets are unknown).

It is possible in some implementations that the final value of JobMediaSheetsCompleted is known, but that

intermediate values are not known. In this case the Printer SHOULD return 0 for a job that is not active, -1 for an active job and the proper final value for completed jobs. The Printer MUST still return -1 for

JobMediaSheetsCompleted when it does not know the value, even in situations that it normally would know the value. A UCP MUST NOT conclude that receipt of a value of -1 for JobMediaSheetsCompleted means that the Printer will always return -1. Even implementations that can never successfully count media sheets completed might still know that a canceled or aborted job never marked any paper, so it could properly return a value of ‘0’

for JobMediaSheetsCompleted in the JobEndState variable.

2.7. Eventing and Moderation

Table 3: Event Moderation

Variable Name Evented Moderated Event

Max Event Rate¹ (sec)

Logical Combination

Min Delta per Event²

PrinterState Yes No N/A N/A

PrinterStateReasons Yes No N/A N/A

JobIdList Yes No N/A N/A

JobEndState Yes No N/A N/A

JobMediaSheetsCompleted Yes Yes 5 N/A

1 Events containing this variable value SHOULD occur no more often than once every MaxEventRate seconds.

2 See 4.4, Eventing: Augmenting the UPnP Template Language in [DEVICE].

648 649

650 651 652 653 654 655 656 657 658

2.7.1. Event Model

The eventing model for the print service has three main purposes. First is to inform the UCP when there is a change in condition of the print device. Examples: the printer becomes idle, a paper jam occurs or the printer is low on paper. The PrinterState and PrinterStateReasons variables provide this information. Second is for job tracking.

Events inform a UCP when a job is submitted, completed or removed from the job queue. The JobIdList and JobEndState provide this information. JobEndState indicates the final status of each job. It lets control points know whether it completed successfully or was canceled or aborted. Third is to inform a UCP of the progress of the current job. JobMediaSheetsCompleted is a moderated evented variable that updates an interested UCP on the number of impressions printed for the current job.

(24)

659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694

2.7.2. Synchronization of Evented Variables

Table 4 below describes how internal printer state changes affect the values of the five evented state variables, plus the non-evented variable, JobId. These state changes can be forced by any of: a UCP invoking one of the print service actions documented herein, a non-UPnP external action or printer internal events and conditions. The effect of some non-UPnP external actions is indirect, i.e., they affect internal printer state immediately, but, if they result in any UPnP-visible effect, the affect appears later. All of these indirect effects have to do with management of untracked jobs. They are included in this table because their ultimate effect can be visible at some later time. A UCP should be aware of this to fully understand observed behavior. For print service implementers, the complete table is a guideline to the information that must be kept and how it is synchronized to guarantee that the externally visible state variables are always correct.

In Table 4, column 1 contains the current value of the variable PrinterState. Column 2 lists the events that can trigger an internal printer state change. Column 3 gives the new printer state and the complete set of actions taken by the printer on the transition that is triggered by the column 2 event. In several cases, the actions taken depend on other printer conditions in addition to the triggering event. Those situations are identified in the table by dividing the lower right portion of the corresponding event “cell” into multiple subcells, one for each condition or set of conditions that requires a different set of transition actions. The upper portion of the event cell is extended into column 3, signifying that no transition action(s) can be specified for this event except when the conditions in the event’s subcells are also considered. The word invisible in column 3 means there is no state change that could be observed by a UPnP UCP. All of the actions listed in column 3 MUST be completed atomically relative to all external UPnP observations.

For purposes of this document, atomically means:

1. From the viewpoint of any UCP observer external to the Print Service, all of the values change at the same time. To achieve this, it is RECOMMENDED that all evented variables changed by this collected set of actions appear in a single event message.

2. It is not possible through any query action for a UCP to detect that any single state variable has changed unless it detects that all have changed and been properly updated to their new values.

To help understand the actions, let’s follow one transition through the tables. Find the entry in column 2 “Terminate active job that was tracked. Its termination condition, T, is one of ‘successful’, ‘canceled’ or ‘aborted’.” Since it has subcell entries, there is no direct entry in column 3. Assume the normal situation of a busy printer with more jobs queued and that all of them are tracked. The relevant added condition is “Next job is tracked.” That takes us to column 3 with actions of “J3, M0, E1(T)”. Looking in Table 5 we see that J3 tells us to remove the first element of the JobIdList and set the new value of JobId to the new first element of JobIdList. M0 tells us to reset JobMediaSheetsCompleted to ‘0’ if we track it, or leave it at ‘-1’ if we don’t. E1(T) tells us to set JobEndState with all the corresponding values for the job just completed, including the indicator whether it was ‘successful’, ‘canceled’ or ‘aborted’. Also note that the M2 value inside JobEndState is set according to the actual final value of the sheets printed, if known.

PrintBasic:1 Service Template Version 1.01