mfd system service semantic model and service interface€¦ · 43 title: network mfd system...

Copyright © 2007-2010, Printer Working Group. All rights reserved.

January 5, 2010 1

wd-mfdsystemservicemodel10-2010 Working Draft 2

3

The Printer Working Group 4

5

6

MFD System Service 7

Semantic Model and Service Interface 8

9

Status: initial 10

11

12 13 14

Abstract: Network print devices have evolved to support additional multifunction services. Examples include system and 15 facsimile services. Each of these services can be controlled individually such as disabling submissions to the service or 16 pausing the output from the service. It is desirable at times to be able to control all the services at once. Another 17 administrative need is the ability to start up, restart or shut down hosted services. The MFD System Service provides this 18 functionality. There are system wide data elements that are not visible to any individual service. For example the system 19 wide usage counters and condition tables. This service provides access to the system wide data elements. In addition to 20 the service-oriented view of the System there is a device-oriented view (i.e., based on subunits). Traditionally SNMP 21 and/or vendor specific methods are used to monitor and manage the subunit data. The System Service permits the 22 monitoring and management of this data over Web Services. 23

24 25 26 27 28

29

30

31

32

33

34

35

36

MFD: System Service January 5, 2010

Copyright © 2010, Printer Working Group. All rights reserved. of 18

Copyright (C) 2007-2009, The Printer Working Group. All rights reserved. 37 This document may be copied and furnished to others, and derivative works that comment on, or otherwise explain it or 38 assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of 39 any kind, provided that the above copyright notice, this paragraph and the title of the Document as referenced below are 40 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as 41 by removing the copyright notice or references to the Printer Working Group, a program of the IEEE-ISTO. 42

Title: Network MFD System Service Semantic Model and Service Interface 43

The IEEE-ISTO and the Printer Working Group DISCLAIM ANY AND ALL WARRANTIES, WHETHER EXPRESS OR 44 IMPLIED INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 45 FOR A PARTICULAR PURPOSE. 46

The Printer Working Group, a program of the IEEE-ISTO, reserves the right to make changes to the document without 47 further notice. The document may be updated, replaced or made obsolete by other documents at any time. 48

The IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO take no position regarding the validity or 49 scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the 50 technology described in this document or the extent to which any license under such rights might or might not be 51 available; neither does it represent that it has made any effort to identify any such rights. 52

The IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO invite any interested party to bring to its 53 attention any copyrights, patents, or patent applications, or other proprietary rights, which may cover technology that may 54 be required to implement the contents of this document. The IEEE-ISTO and its programs shall not be responsible for 55 identifying patents for which a license may be required by a document and/or IEEE-ISTO Industry Group Standard or for 56 conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Inquiries may be 57 submitted to the IEEE-ISTO by e-mail at: 58

[email protected] 59

The Printer Working Group acknowledges that the IEEE-ISTO (acting itself or through its designees) is, and shall at all 60 times, be the sole entity that may authorize the use of certification marks, trademarks, or other special designations to 61 indicate compliance with these materials. 62

Use of this document is wholly voluntary. The existence of this document does not imply that there are no other ways to 63 produce, test, measure, purchase, market, or provide other goods and services related to its scope. 64 65

66



About the IEEE-ISTO 67

The IEEE-ISTO is a not-for-profit corporation offering industry groups an innovative and flexible operational forum and 68 support services. The IEEE Industry Standards and Technology Organization member organizations include printer 69 manufacturers, print server developers, operating system providers, network operating systems providers, network 70 connectivity vendors, and print management application developers. The IEEE-ISTO provides a forum not only to develop 71 standards, but also to facilitate activities that support the implementation and acceptance of standards in the marketplace. 72 The organization is affiliated with the IEEE (http://www.ieee.org/) and the IEEE Standards Association 73 (http://standards.ieee.org/). 74

For additional information regarding the IEEE-ISTO and its industry programs visit: 75 http://www.ieee-isto.org. 76 77 About the Printer Working Group 78

The Printer Working Group (or PWG) is a Program of the IEEE-ISTO. All references to the PWG in this document 79 implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” The PWG is chartered to make printers and 80 the applications and operating systems supporting them work together better. In order to meet this objective, the PWG will 81 document the results of their work as open standards that define print related protocols, interfaces, data models, 82 procedures and conventions. Printer manufacturers and vendors of printer related software would benefit from the 83 interoperability provided by voluntary conformance to these standards. 84

In general, a PWG standard is a specification that is stable, well understood, and is technically competent, has multiple, 85 independent and interoperable implementations with substantial operational experience, and enjoys significant public 86 support. 87

Contact information: 88

The Printer Working Group 89 c/o The IEEE Industry Standards and Technology Organization 90 445 Hoes Lane 91 Piscataway, NJ 08854 92 USA 93 94 MFD Web Page: http://www.pwg.org/mfd MFD Mailing List: [email protected] 95 96 Instructions for subscribing to the MFD mailing list can be found at the following link: 97 http://www.pwg.org/mailhelp.html 98 Members of the PWG and interested parties are encouraged to join the PWG and MFD WG mailing lists in order to 99 participate in discussions, clarifications and review of the WG product. 100

101

http://www.ieee.org/

http://standards.ieee.org/)

http://www.ieee-isto.org/

mailto:[email protected]

http://www.pwg.org/mailhelp.html



Contents 102

1 Introduction ..................................................................................................................................................... 6 103

2 Summary ......................................................................................................................................................... 6 104

3 Terminology .................................................................................................................................................... 7 105 3.1 Conformance Terminology .................................................................................................................................... 7 106 3.2 Content Specific Terminology ................................................................................................................................ 7 107

4 Rationale ......................................................................................................................................................... 8 108 4.1 Rationale for this SystemService Specification ..................................................................................................... 8 109 4.2 Out of Scope for SystemService............................................................................................................................ 8 110 4.3 Model mapping conventions .................................................................................................................................. 8 111

5 MFD Model Overview ..................................................................................................................................... 9 112

6 Systeme Model Overview ............................................................................................................................... 9 113 6.1 SystemCapabilities .............................................................................................................................................. 10 114 6.2 SystemConfiguration ........................................................................................................................................... 10 115 6.3 SystemDescription ............................................................................................................................................... 11 116 6.4 SystemStatus ....................................................................................................................................................... 12 117

7 SystemService Theory of Operation ............................................................................................................. 13 118

8 SystemService Interfaces ............................................................................................................................. 14 119

9 Conformance Requirements ......................................................................................................................... 14 120 9.1 Client Conformance Requirements...................................................................................................................... 14 121 9.2 System Service Conformance Requirements ...................................................................................................... 15 122

9.2.1 Objects ............................................................................................................................... 15 123

9.2.2 Operations ......................................................................................................................... 15 124

9.3 System Service Elements .................................................................................................................................... 15 125 9.4 Extensions ........................................................................................................................................................... 15 126

10 PWG and IANA Registration Considerations................................................................................................ 16 127

11 Internalization Considerations ...................................................................................................................... 16 128

12 Security Considerations ................................................................................................................................ 16 129 12.1 Protection of Digital Document ............................................................................................................................ 16 130 12.2 Restricted use of System Service Features ........................................................................................................ 16 131

13 References .................................................................................................................................................... 16 132 13.1 Normative References ......................................................................................................................................... 16 133 13.2 Informative References ........................................................................................................................................ 17 134

14 Author’s Address ........................................................................................................................................... 17 135 136

137

Figures 138

Figure 1 High Level System Schema ...................................................................................................................................... 9 139

Figure 2 SystemCapabilities ................................................................................................................................................. 10 140

Figure 3 SystemConfiguration............................................................................................................................................... 11 141

Figure 4 SystemDescription .................................................................................................................................................. 12 142

Figure 5 SystemStatus .......................................................................................................................................................... 13 143

144



145

Tables 146

Table 4 User Operations ....................................................................................................................................................... 14 147

Table 5 Administrative Operations ........................................................................................................................................ 14 148

149

150



1 Introduction 151

This document specifies the PWG abstract model for the System Service of a Multifunction Device (MFD). 152 Included in this document is the content specific terminology, data model, the theory of operation, the 153 SystemService interfaces and the conformance requirements. The MFD System Service abstract model includes 154 the functional models and interfaces of the associated System Services for a local network or enterprise-connected 155 multifunction device. 156 157

2 Summary 158

The MFD service addressed in this specification is the SystemService. The SystemService responds to queries 159 about its capabilities, configuration, status and descriptive information. The SystemService acts upon requests to 160 modify system data. 161 162 A client application interacting with the SystemService contains a System Client. A System Client interacts with the 163 End User to obtain the End User’s directives and uses the System Client to communicate with the SystemService 164 that will execute the directive. 165 166 The System scenarios addressed in this specification range from walk-up users that use MFD’s front panel to 167 initiate requests to remote users that use their computers to initiate requests. The assumption is that it is possible 168 to implement a Network Connected System Client that is accessible via the device’s front panel. The model also 169 supports external security services that protects against unauthorized use of the SystemService and access of 170 System’s data. 171 172



3 Terminology 173

3.1 Conformance Terminology 174

See [MFD] for conformance terminology used. There are no SystemService specific conformance terms. 175

3.2 Content Specific Terminology 176

See [MFD] for common MFD terminology used. For this service the “<service>” in the MFD Terminology section is 177

replaced with “System”. The terms used in this document are:. 178

179 There is no SystemService specific terminology. 180 181

Comment [PZ1]: Update with correct reference

Comment [PZ2]: Update with terms used in this spec



4 Rationale 182

4.1 Rationale for this SystemService Specification 183

184

In order to support common functionality for managing and monitoring multifunction devices, there is a need to 185

develop a semantic model and a set of abstract operations and elements for System related services. In order to 186

implement an abstract model of the operations and elements for the System service, there is need to map them 187

onto implementable applications and communication protocols that support interactions between System Clients 188

and SystemService. There is a need to define a binding of the abstract model into Web Service Schema and Web 189

Service protocol stack. 190

4.2 Out of Scope for SystemService 191

The basic SystemService model defined in this document is targeted to support enterprise SystemService 192 applications. However this document does not specify any application specific semantics. The MFD Working 193 Group charter [CHAR] defines the following as out of scope: 194 195

1. Semantics of any compound service such as Copy-And-Email. 196 2. Semantics of any workflow protocol, i.e., sequencing and coordination of Jobs across multiple services. 197 3. Semantics of any SystemService management operations for MFDs that are not network connected. 198

199

4.3 Model mapping conventions 200

The SystemService model is described in this document as an XML schema. This is for the sake of convenience 201 and does not require a protocol mapping involving XML. The top level objects such as SystemConfiguration, 202 Services, and their associated Jobs and Documents can be represented in any number of ways. Abstractly they 203 are objects which contain attributes or properties that express characteristics of the object. For the remainder of 204 this document references to attribute or element refer to XML attributes and XML elements respectively. Either of 205 these can be abstractly considered to be attributes or properties of abstract objects. 206



207

5 MFD Model Overview 208

See [MFD] for the overall MFD model. SystemService fits within the MFD model as one of a number of services 209 that can be hosted on a multifunction device (i.e., System). The critical MFD container object with regard to 210 describing SystemService is Services. 211

The System has a SystemConfiguration object that contains all the subunits that comprise the MFD. Each 212 SystemService instance contains a service specific view of the subunits used by that service instance. The 213 SystemService element SystemServiceConfiguration contains the service specific view of the associated Subunits. 214

215

6 Systeme Model Overview 216

Below is the top level view of the System schema. 217 218

219

Figure 1 High Level System Schema 220

221 The PWG semantic model supports exactly one SystemServices. A SystemService is hosted locally on an MFD. The 222 SystemService model has a set of elements which includes System status, configuration, description, and capabilities. 223 All the hosted service instances are represented in the Services element. The exception to this is the SystemService 224 itself which is logically bound to the System object itself. 225 226 The SystemCapabilities group element represents the ZZZ. The details of each processing element are specified in 227 §ZZZ. 228 229

Comment [PZ3]: The SystemService does not quite fit along with the other services. There is only a single instance. There is no “queue view” realized by setting different capabilities for different instances. The service would always be available. There are no jobs coming in or output produced.

Comment [PZ4]: Need description for SystemCapabilities.



SystemServiceConfiguration provides a System wide view of the Subunits. The details of each subunit are detailed in 230 §ZZZ. 231 232 The SystemServiceDescription group element includes descriptive information such as system name and information, 233 and has extension point for vendor specific information. These description elements are settable by Administrators. The 234 details of the SystemDescription elements are specified in §ZZZ. 235 236 The SystemServiceStatus group element includes elements such as ID, state, counters, state messages and state 237 reasons. State messages are localized state reasons. The details of the elements in the SystemStatus group are 238 specified in §6.4ZZZ. 239 240 241

6.1 SystemCapabilities 242

The SystemServiceCapabilities provides information about ZZZ. 243

244

245

246

247

Figure 2 SystemCapabilities 248

249 . 250

6.2 SystemConfiguration 251

The MFD Model and Overall Semantics specification [MFD] defines the system wide Subunits 252 253

Comment [PZ5]: What should be said abour Services with regards to a SystemService?

Comment [PZ6]: Need description for SystemCapabilities



254

Figure 3 SystemConfiguration 255

256 257 258

6.3 SystemDescription 259

260 Below is a view of the System’s SystemDescription . SystemDescription provide Descriptive information for the 261 entire MFD. The element values are administratively set. The element values can be directly or modified indirectly 262 through an operation. 263



264

Figure 4 SystemDescription 265

266 The elements in ServiceDescriptions are described in the MFD Model and Overall Semantics specification [MFD]. 267 268

6.4 SystemStatus 269

270 Below is a view of the System’s SystemStatus. SystemServiceStatus provide roll up state information for the 271 hosted services. The elements values are maintained by automata and cannot be directly set. The element 272 values can be modified indirectly through an operation. For example PauseSystemService operation on the 273 SystemService may result in the change of the State and StateReasons elements. 274 275

Comment [PZ7]: The ServicesSupported and XriSupported should be combined so that multiple URL’s per service can be enumerated and URLs can be bound to service types.



276

277

Figure 5 SystemStatus 278

279 280

7 SystemService Theory of Operation 281

The SystemService follows the behaviors and state transitions defined in the MFD Model and Overall Semantics 282 specification [MFD]. 283 Comment [PZ8]: Since this is a roll up status

the semantics needs additional explanation



8 SystemService Interfaces 284

The SystemService provides a set of service interfaces that is the same for a co-located local System Client or a 285 Remote System Client via a local interface, a local area network, or the Internet. A user makes a SystemService 286 request by interacting directly with the SystemService or indirectly through a local System Client via the MFD UI or 287 a Remote System Client via its software application UI. 288 289 The requests below that are expected to have parameters are defined as containing an extension point indicating 290 that vendors may extend the request with additional information. Responses to operations that fail are expected to 291 return a fault. Responses that are expected to have no parameters are defined as containing an extension point 292 indicating that vendors may extend the request with additional information. 293 294 The semantics for these operations are the same as the operations specified in the MFD Model and Overall 295 Semantics specification [MFD]. The exception is that since the SystemService does not expose a 296 SystemDocument no operations(e.g., SetSystemDocumentElements) or elements (e.g., 297 SystemDocumentProcessing) associated with the document object are applicable to this service. In the table 298 below required operations and parameters ar in bold and option operations and parameters are in normal font. 299 300

Table 1 User Operations 301

User Operation Name

Input Parameters Output Parameters

GetMfdElements ElementsNaturalLanguageRequested, RequestedElements

SystemServiceElements, NaturalLanguage

Table 2 Administrative Operations 302

Administrative Operation Name

Input Parameters Output Parameters

DisableMfdServices

EnableMfdServices

PauseMfdServices

RestartMfdService Id, ServiceType

ResumeMfdServices

SetMfdElements SystemElements, NaturalLanguage

ShutdownMfdService Id, ServiceType

StartupMfdService Id, ServiceType

303 304

9 Conformance Requirements 305

This section describes conformance issues and requirements. This document introduces model entities such as 306 objects, operations, elements, element syntaxes, and element values. These conformance sections describe the 307 conformance requirements which apply to these model entities. 308

9.1 Client Conformance Requirements 309

A conforming client MUST support all REQUIRED operations as defined in this document. For each parameter 310 included in an operation request, a conforming client MUST supply a value whose type and value syntax conforms 311 to the requirements of the Model document as specified in Section ZZZ. A conforming client MAY supply any 312 extensions in an operation request, as long as they meet the requirements in Section ZZZ. 313

Comment [PZ9]: If this service can retrieve information for one of multiple instance of an object (e.g., PrintService 1, Media loaded in InputTray 3) then we would need something like a simple XPath expression to specify the Requested element. Alternatively we could limit the Get method to top level elements or tables.



When sending a request, a conforming client NEED NOT supply any parameters that are indicated as 314 OPTIONALLY supplied by the client. 315

A client MUST be able to accept any of the elements defined in the model, including their full range that may be 316 returned to it in a response from a System Service 317

An operation response may contain elements and/or values that the client does not expect. Therefore, a client 318 implementation MUST gracefully handle such responses and not refuse to inter-operate with a conforming System 319 Service that is returning extended elements and/or values that conform to Section ZZZ . Clients may choose to 320 ignore any parameters, elements, or values that they do not understand. 321

9.2 System Service Conformance Requirements 322

This section specifies the conformance requirements for conforming implementations with respect to objects, 323 operations, and attributes. 324

325

9.2.1 Objects 326

327

Conforming implementations MUST implement all of the model objects as defined in this specification in the 328 indicated sections: 329

Section ZZZ - System 330 Section ZZZ- System Services 331 Section ZZZ- System Capabilities 332 Section ZZZ- System Configuration 333 Section ZZZ- System Description 334 Section ZZZ- System Status 335

9.2.2 Operations 336

Conforming System Service implementations MUST implement all of the REQUIRED model operations, including 337 REQUIRED responses, as defined in this specification in section ZZZ: 338

GetMfdElements DisableMfdServices EnableMfdServices PauseMfdServices RestartMfdService ResumeMfdServices SetMfdElements ShutdownMfdServices StartupMfdServices

339 340

Conforming System Service MUST support all REQUIRED operation elements and all values of such elements if 341 so indicated in the description. Conforming System Service MUST ignore all unsupported or unknown operation 342 elements received in a request. 343

9.3 System Elements 344

Conforming System Service MUST support all of the REQUIRED object elements, as defined in this specification. 345

If an object supports an element, it MUST support only those values specified in this document or through the 346 extension mechanism described in section ZZZ It MAY support any non-empty subset of these values. That is, it 347 MUST support at least one of the specified values and at most all of them. 348

9.4 Extensions 349

Conforming System Service MAY support extensions. To extend the model the extensions MUST be fully qualified. 350 The qualified name MUST NOT be in the PWG target namespace. When extending the model with new elements 351 the new elements MUST be added at the extension points at the end of the associated sequence of elements. 352 Extended values for elements MUST conform to the extension patterns defined in the element schema. 353 Implementers are free to add vendor specific operations to the service. 354



10 PWG and IANA Registration Considerations 355

Once the specification and associated schema is published it will require a new version of the specification to 356 register extensions to the SystemService model. Vendors may use extensions in their own namespace until such 357 time as an update to the specification is under review. At that time the extension can be registered with the PWG 358 and included in the new PWG specification. 359

11 Internalization Considerations 360

All element values defined by enumeration (e.g. State) represent keywords. Keywords are never localized by the 361 device. The client may convert the values into a form acceptable to the client. This includes not only localization but 362 also transformations into graphical representation. The elements with an extensible list of keyword are represented 363 by the union of an enumeration of keywords and a pattern for new values. 364

Some of the elements have values that are Scan Service generated strings (e.g. StateMessages). In each 365 operation request, the client identifies a natural language that affects the System Service generated strings 366 returned by the System Service in operation responses. The System Service MUST provide the localized value as 367 requested by the user for any supported natural languages. A request for a language not supported results in a 368 response with the string in the default localization. 369

The final category of string values are those supplied by administrator or End User (e.g. MessageFromOperator). 370 No localization is performed on these strings and they are returned in operation responses as set by the 371 administrator or End User. 372

12 Security Considerations 373

12.1 Protection of Digital Document 374

The Services hosted on a System usually has some internal representation for the digital form of the document that 375 is being processed. The internal Digital Document is not visible to the user. The internal Digital Document should 376 be protected from disclosure by encrypting the content of the Documents. 377

378

12.2 Restricted use of System Service Features 379

The management of the site policy for the use of Scan Service features is outside the scope of this specification. 380

13 References 381

13.1 Normative References 382

[MFD] 383

PWG 5108.1-2010 MFD Model and Overall Semantics version 1, February 20, 2010, W. Wagner, 384 ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-mfd10-20100210-5108.01.pdf 385

[PWG5105.1] 386

PWG 5105.1-2004 Printer Working Group (PWG) Semantic Model version 1, January 20, 2004, P. Zehler, 387 T.Hastings, S. Albright, ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm10-20040120-5105.1.pdf 388

[PWG5108.2] 389

PWG 5108.2-2009 Network Scan Service Semantic Model and Service Interface version 1, April 10, 2009, 390 N. Chen, P. Zehler, ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-scan10-20090410-5108.02.pdf 391

Comment [ZP10]: Update with approved specification

ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-mfd10-20100210-5108.01.pdf

ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm10-20040120-5105.1.pdf

ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-scan10-20090410-5108.02.pdf



[PWG5101.1] 392

PWG 5101.1-2002 Media Standardized Names, February 26, 2002 393 ftp://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn10-20020226-5101.1.pdf 394

[PWG5100.3] 395 PWG 5100.3-2001, "Internet Printing Protocol (IPP): Production Printing Attributes - Set1", February 12, 396

2001, K. Ocke, T. Hastings, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf 397

398

[PWG5106.1-2007] 399

PWG 5106.1-2007, "The Printer Working Group (PWG) Standardized Imaging System Counters 1.1", April 400 27, 2007, H. Lewis, I. McDonald, J. Thrasher, W. Wagner, and P. Zehler, 401 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimscount11-20070427-5106.1.pdf 402

[RFC2119] 403 S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, March 1997. 404

[RFC2911] 405

RFC 2911 “Internet Printing Protocol/1.1 Model and Semantics”, September 2000, T. Hastings, R. Herriot, 406 R. deBry, S. Isaacson, P. Powell, ftp://ftp.rfc-editor.org/in-notes/rfc2911.txt 407

[RFC 3805] 408 R. Bergman, H. Lewis, I. McDonald, “Printer MIB v2”, RFC 3805, June 2004. 409

[rfc3066] 410

RFC 3066 “Tags for the Identification of Languages”, January 2001, H. Alvestrand, 411 http://www.ietf.org/rfc/rfc3066.txt 412

[RFC4395] 413

RFC 4395 “Guidelines and Registration Procedures for New URI Schemes”, February 2006, T. Hansen, T. 414 Hardie, L. Masinter, http://www.rfc-editor.org/rfc/rfc4395.txt 415

[WS-SCAN] 416

“SystemService DefinitionVersion 1.0 For Web Services on Devices”, November 2006, Microsoft, M 417 Fenelon, http://www.microsoft.com/whdc/connect/rally/wsdspecs.mspx 418

419

13.2 Informative References 420

[CHAR] 421

P. Zehler, and I. McDonald, “Charter of the PWG Multifunction Device (MFD) Working Group (WG)”, May 4, 422 2007, ftp://ftp.pwg.org/pub/pwg/mfd/charter/ch-mfd-20070504.pdf 423

[prod-print2] 424

T. Hastings, and D. Fullman, “Internet Printing Protocol (IPP): Production Printing Attributes - Set 2”, August 425 21, 2002, ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set2-draft-v0_1-020821.pdf 426

14 Author’s Address 427

Peter Zehler 428 Xerox Research Center Webster 429

Email: [email protected] 430 Voice: (585) 265-8755 431 SYSTEM: (585) 265-7441 432

ftp://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn10-20020226-5101.1.pdf

ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf

ftp://ftp.rfc-editor.org/in-notes/rfc2911.txt

http://www.rfc-editor.org/rfc/rfc4395.txt

http://www.microsoft.com/whdc/connect/rally/wsdspecs.mspx

ftp://ftp.pwg.org/pub/pwg/mfd/charter/ch-mfd-20070504.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set2-draft-v0_1-020821.pdf



US Mail: Peter Zehler 433 Xerox Corp. 434 800 Phillips Rd. 435 M/S 128-25E 436 Webster NY, 14580-9701 437

438 439 Additional contributors: (Still to be updated) 440 Nancy Chen – OkiData 441 Lee Farrell – Cannon 442 Ira McDonald – High North 443 Bill Wagner – TIC 444 445