ftp.pwg.orgftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20121116.docx · web view11/16/2012 · the...
TRANSCRIPT
November 16, 2012
Working Draft
The Printer Working Group
IPP Everywhere
Status: Stable
Abstract: This standard defines an extension of IPP to support network printing without vendor-specific driver software, including the transport, various discovery protocols, and standard document formats.
This document is a PWG Working Draft. For a definition of a "PWG Working Draft", see: ftp://ftp.pwg.org/pub/pwg/general/pwg-process30.pdf
Copyright © 2011-2012 The Printer Working Group. All rights reserved.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
151617
1819
November 16, 2012
Working Draft
The Printer Working Group
This document is available electronically at:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20121116.docxftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20121116.pdf
Copyright © 2011-2012 The Printer Working Group. All rights reserved.
20
2122
Working Draft – IPP Everywhere November 16, 2012
Copyright © 2011-2012 The Printer Working Group. All rights reserved.
This document may be copied and furnished to others, and derivative works that comment on, or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice, this paragraph and the title of the Document as referenced below are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO.
Title: IPP Everywhere
The IEEE-ISTO and the Printer Working Group DISCLAIM ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The Printer Working Group, a program of the IEEE-ISTO, reserves the right to make changes to the document without further notice. The document may be updated, replaced or made obsolete by other documents at any time.
The IEEE-ISTO takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
The IEEE-ISTO invites any interested party to bring to its attention any copyrights, patents, or patent applications, or other proprietary rights which may cover technology that may be required to implement the contents of this document. The IEEE-ISTO and its programs shall not be responsible for identifying patents for which a license may be required by a document and/or IEEE-ISTO Industry Group Standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Inquiries may be submitted to the IEEE-ISTO by e-mail at: [email protected].
The Printer Working Group acknowledges that the IEEE-ISTO (acting itself or through its designees) is, and shall at all times, be the sole entity that may authorize the use of
Page 3 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
1
2
23
24252627282930
31
32333435
363738
3940414243
44454647484950
5152
Working Draft – IPP Everywhere November 16, 2012
certification marks, trademarks, or other special designations to indicate compliance with these materials.
Use of this document is wholly voluntary. The existence of this document does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to its scope.
Page 4 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
3
4
5354
555657
58
Working Draft – IPP Everywhere November 16, 2012
About the IEEE-ISTO
The IEEE-ISTO is a not-for-profit corporation offering industry groups an innovative and flexible operational forum and support services. The IEEE-ISTO provides a forum not only to develop standards, but also to facilitate activities that support the implementation and acceptance of standards in the marketplace. The organization is affiliated with the IEEE (http://www.ieee.org/) and the IEEE Standards Association (http://standards.ieee.org/).
For additional information regarding the IEEE-ISTO and its industry programs visit:
http://www.ieee-isto.org
About the IEEE-ISTO PWG
The Printer Working Group (or PWG) is a Program of the IEEE Industry Standards and Technology Organization (ISTO) with member organizations including printer manufacturers, print server developers, operating system providers, network operating systems providers, network connectivity vendors, and print management application developers. The group is chartered to make printers and the applications and operating systems supporting them work together better. All references to the PWG in this document implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” In order to meet this objective, the PWG will document the results of their work as open standards that define print related protocols, interfaces, procedures and conventions. Printer manufacturers and vendors of printer related software will benefit from the interoperability provided by voluntary conformance to these standards.
In general, a PWG standard is a specification that is stable, well understood, and is technically competent, has multiple, independent and interoperable implementations with substantial operational experience, and enjoys significant public support.
For additional information regarding the Printer Working Group visit:
http://www.pwg.org
Contact information:
Page 5 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
5
6
59
606162636465
66
67
68
6970717273747576777879
808182
83
84
85
Working Draft – IPP Everywhere November 16, 2012
The Printer Working Groupc/o The IEEE Industry Standards and Technology Organization445 Hoes LanePiscataway, NJ 08854USA
Page 6 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
7
8
8687888990
91
Working Draft – IPP Everywhere November 16, 2012
About the Internet Printing Protocol Work Group
The Internet Printing Protocol (IPP) working group has developed a modern, full-featured network printing protocol, which is now the industry standard. IPP allows a print client to query a printer for its supported capabilities, features, and parameters to allow the selection of an appropriate printer for each print job. IPP also provides job information prior to, during, and at the end of job processing.
For additional information regarding IPP visit:
http://www.pwg.org/ipp/
Implementers of this specification are encouraged to join the IPP mailing list in order to participate in any discussions of the specification. Suggested additions, changes, or clarification to this specification, should be sent to the IPP mailing list for consideration.
Page 7 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
9
10
92
9394959697
98
99
100101102
Working Draft – IPP Everywhere November 16, 2012
Table of Contents
1. Introduction......................................................................................................................9
2. Terminology.....................................................................................................................9
2.1 Conformance Terminology.........................................................................................9
2.2 Imaging Terminology.................................................................................................9
2.3 Other Terminology...................................................................................................10
2.4 Acronyms and Organizations...................................................................................11
3. Requirements................................................................................................................12
3.1 Rationale for IPP Everywhere..................................................................................12
3.2 Use Cases...............................................................................................................13
3.2.1 Select Printer.....................................................................................................13
3.2.2 Print...................................................................................................................15
3.2.3 Exceptions.........................................................................................................18
3.3 Out of Scope............................................................................................................20
3.4 Design Requirements..............................................................................................20
4. Discovery Protocols.......................................................................................................21
4.1 Printer Description Attributes Used in Discovery.....................................................21
4.2 DNS Service Discovery (DNS-SD)...........................................................................21
4.2.1 Service (SRV) Instance Name...........................................................................21
4.2.2 Geo-Location (LOC)..........................................................................................21
4.2.3 Text (TXT).........................................................................................................23
4.3 LDAP and SLP Discovery........................................................................................28
Page 8 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
11
12
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
Working Draft – IPP Everywhere November 16, 2012
4.4 SSDP Discovery......................................................................................................29
4.4.1 Device Definitions..............................................................................................30
4.4.2 Theory of Operation...........................................................................................31
4.4.3 XML Device Description....................................................................................31
4.5 WS-Discovery..........................................................................................................32
5. Protocol Binding............................................................................................................34
5.1 HTTP Features........................................................................................................34
5.1.1 Host...................................................................................................................34
5.1.2 If-Modified-Since, Last-Modified, and 304 Not Modified....................................34
5.1.3 Cache-Control...................................................................................................34
5.2 IPP Operations.........................................................................................................35
5.3 IPP Printer Description Attributes.............................................................................35
5.3.1 media-col-database (1setOf collection).............................................................38
5.3.2 media-col-ready (1setOf collection)...................................................................39
5.3.3 media-ready (1setOf (type3 keyword | name(MAX)).........................................40
5.3.4 media-size-supported (1setOf collection)..........................................................40
5.3.5 media-supported (1setOf (type3 keyword | name(MAX))..................................41
5.3.6 printer-device-id (text(1023)).............................................................................42
5.4 IPP Operation Attributes..........................................................................................43
5.5 IPP Job Template Attributes....................................................................................44
5.6 IPP Job Description Attributes.................................................................................45
5.6.1 job-id (integer)...................................................................................................45
Page 9 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
13
14
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
Working Draft – IPP Everywhere November 16, 2012
5.6.2 job-uri (uri).........................................................................................................46
6. Document Formats........................................................................................................46
6.1 Supporting Long-Edge Feed Media with PWG Raster Format Documents.............46
7. Additional Values for Existing Attributes........................................................................49
7.1 ipp-features-supported (1setOf type2 keyword).......................................................49
8. Additional Semantics for Existing Value Tags...............................................................50
8.1 nameWithLanguage and nameWithoutLanguage....................................................50
8.2 naturalLanguage......................................................................................................50
8.3 textWithLanguage and textWithoutLanguage..........................................................50
8.4 uri.............................................................................................................................50
9. Conformance Requirements..........................................................................................51
9.1 Conformance Requirements for Clients...................................................................51
9.2 Conformance Requirements for Printers..................................................................51
9.3 Conditional Conformance Requirements for Printers...............................................52
10. Internationalization Considerations..............................................................................53
11. Security Considerations...............................................................................................53
12. IANA Considerations...................................................................................................54
12.1 Attribute Value Registrations..................................................................................54
13. Safe String Truncation.................................................................................................54
13.1 Plain Text Strings...................................................................................................54
13.2 URIs.......................................................................................................................54
13.3 MIME Media Types................................................................................................55
Page 10 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
15
16
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
Working Draft – IPP Everywhere November 16, 2012
13.4 IEEE 1284 Device ID Strings.................................................................................55
13.5 Delimited Lists........................................................................................................55
14. References..................................................................................................................56
14.1 Normative References...........................................................................................56
14.2 Informative References..........................................................................................60
15. Authors' Addresses......................................................................................................61
16. Change History............................................................................................................62
16.1 November 16, 2012...............................................................................................62
16.2 November 4, 2012.................................................................................................62
16.3 September 26, 2012..............................................................................................63
16.4 September 6, 2012................................................................................................63
16.5 July 24, 2012..........................................................................................................65
16.6 June 27, 2012........................................................................................................66
16.7 May 30, 2012.........................................................................................................66
16.8 April 20, 2012.........................................................................................................66
16.9 April 8, 2012...........................................................................................................67
16.10 February 1, 2012..................................................................................................67
16.11 September 27, 2011............................................................................................68
16.12 August 3, 2011.....................................................................................................68
16.13 March 16, 2011....................................................................................................68
Page 11 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
17
18
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
Working Draft – IPP Everywhere November 16, 2012
List of Figures
Figure 1 - UPnP Printer:2 Functional Diagram..................................................................29
Figure 2 - PWG Raster Bitmaps with Portrait Feed Orientation.........................................47
Figure 3 - PWG Raster Bitmaps with Landscape Feed Orientation...................................47
Figure 4 - PWG Raster Bitmaps with Reverse Landscape Feed Orientation....................48
Figure 5 - PWG Raster Bitmaps with Reverse Portrait Feed Orientation..........................48
Page 12 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
19
20
191
192
193
194
195
196
197
198
199
Working Draft – IPP Everywhere November 16, 2012
List of Tables
Table 1 - Attributes in Discovery Protocols........................................................................22
Table 2 - Priority of DNS TXT Key/Value Pairs.................................................................24
Table 3 - DNS TXT Record Keys.......................................................................................25
Table 4 - Device Requirements for urn:schemas-upnp-org:printer:2.................................30
Table 5 - IPP Everywhere Required Operations................................................................35
Table 6 - IPP Everywhere Required Printer Description Attributes....................................35
Table 7 - IPP Everywhere Required Operation Attributes.................................................43
Table 8 - IPP Everywhere Required Job Template Attributes...........................................44
Table 9 - IPP Everywhere Required Job Description Attributes........................................45
Page 13 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
21
22
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
Working Draft – IPP Everywhere November 16, 2012
1. Introduction
New mobile devices (e.g., cellphones, PDAs, netbooks, etc.) do not follow the traditional use models for printing services. For mobile devices, discovery of available printers and their capabilities is both more difficult than for traditional desktop systems and more important because of dynamically changing network attachment points.
Printer vendors and software vendors have defined and deployed many different document formats (page description languages) and also dialects of those document formats, increasing the traditional desktop system need for model-specific printer drivers. While there are millions of model-specific printer drivers now available for traditional desktop systems, this printer driver model is clearly not practical for mobile devices.
The goal of IPP Everywhere is to allow Clients, particularly mobile Internet devices, to easily support printing using IPP but without the use of vendor-specific drivers through the adoption of standard document formats, discovery protocols, and schemas.
2. Terminology
2.1 Conformance Terminology
Capitalized terms, such as MUST, MUST NOT, RECOMMENDED, REQUIRED, SHOULD, SHOULD NOT, MAY, and OPTIONAL, have special meaning relating to conformance as defined in Key words for use in RFCs to Indicate Requirement Levels [RFC2119].
The term CONDITIONALLY REQUIRED is additionally defined for a conformance requirement that applies to a particular capability or feature.
2.2 Imaging Terminology
Normative definitions and semantics of printing terms are imported from IETF Printer MIB v2 [RFC3805], IETF Finisher MIB [RFC3806], and IETF Internet Printing Protocol/1.1: Model and Semantics [RFC2911].
Page 14 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
23
24
215
216217218219
220221222223224
225226227
228
229
230231232233
234235
236
237238239
Working Draft – IPP Everywhere November 16, 2012
This document also defines the following protocol roles in order to specify unambiguous conformance requirements:
Client: Initiator of outgoing IPP session requests and sender of outgoing IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616] User Agent).
Device: A Logical or Physical Device associated with one or more Printers; also see section 2.3 of [RFC2911].
Document: An object created and managed by a Printer that contains the description, processing, and status information. A Document object may have attached data and is bound to a single Job.
Logical Device: a print server, software service, or gateway that processes jobs and either forwards or stores the processed job or uses one or more Physical Devices to render output.
Physical Device: a device that renders output (typically on paper.)
Printer: Listener for incoming IPP session requests and receiver of incoming IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616] Server) that represents one or more Physical Devices or a Logical Device.
Imaging Device: A printer or other device that acts as a Printer.
Job: An object created and managed by a Printer that contains description, processing, and status information. The Job also contains zero or more Document objects.
2.3 Other Terminology
Direct Imaging: Printing, facsimile, and scanning performed by direct communication from the Client to an Imaging Device or local print server.
Directory Service: A Service providing query and enumeration of information using names or other identifiers.
Discovery: Finding Printers by querying or browsing local network segments or Enumeration of Directory or Name Services.
Page 15 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
25
26
240241
242243
244245
246247248
249250251
252
253254255
256
257258
259
260261
262263
264265
Working Draft – IPP Everywhere November 16, 2012
Enumeration: Listing Printers that are registered with a Directory or other Service.
Indirect Imaging: Printing, facsimile, and scanning performed by communication from the Client and/or Imaging Device to an intermediary service in a different administrative domain, for example when the Client communicates with a third-party print service or when an Imaging Device communicates with a Cloud service.
Network Accessible Device: A Device that can be directly accessed by a Client.
Network Accessible/Accessibility: Refers to the ability of one device to communicate directly with another, for example a Client is able to connect to a Device, query for supported attributes, submit Job creation requests, and so forth.
Operator: A person or automata that typically oversees the Printer. The Operator is allowed to query and manage the Printer, Jobs and Documents based on site policy.
Paid Imaging Services: Printing, facsimile, and scanning performed for a fee. The means of collecting payment is outside the scope of this specification.
Secure Print: A print job using the "document-password", "job-password", and/or "job-password-encryption" operation attributes to provide document and/or physical security. See [PWG5100.11] and [PWG5100.13].
Service: Software providing access to physical, logical, or virtual resources and (typically) processing of queued Jobs.
User: A person or automata using a Client to communicate with a Printer.
2.4 Acronyms and Organizations
IANA: Internet Assigned Numbers Authority, http://www.iana.org/
IEEE: Institute of Electrical and Electronics Engineers, http://www.ieee.org/
IETF: Internet Engineering Task Force, http://www.ietf.org/
ISO: International Organization for Standardization, http://www.iso.org/
Page 16 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
27
28
266
267268269270
271
272273274
275276
277278
279280281
282283
284
285
286
287
288
289
Working Draft – IPP Everywhere November 16, 2012
NFC: Near Field Communications, http://www.nfc-forum.org/
OASIS: Organization for the Advancement of Structured Information Standards, http://www.oasis-open.org/
PWG: Printer Working Group, http://www.pwg.org/
UPNP: Universal Plug-and-Play, http://www.upnp.org/
Page 17 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
29
30
290
291292
293
294
295
296
Working Draft – IPP Everywhere November 16, 2012
3. Requirements
3.1 Rationale for IPP Everywhere
Given the following existing specifications and the need for a standard method of Direct Imaging without traditional vendor-specific driver software, the IPP Everywhere Specification should:
1. Use existing protocols and schema to support discovery, identification, and auto-configuration of Imaging Devices,
2. Use the existing IPP specifications to support job submission to and monitoring of Imaging Devices,
3. Encourage support for printing through standard document formats, and4. Discourage the further proliferation of vendor-specific page description
languages, formats, discovery protocols, interfaces, and transports
The Internet Printing Protocol Version 2.0 Second Edition [PWG5100.12] defines:
1. A collection of existing IPP specifications that form the basis for IPP/2.02. Standard job template attributes3. Specific interoperability requirements, such as HTTP/1.1 support with chunking
and IPP collection attribute support4. New version number and operation requirements for different classes of
Imaging Devices
The IPP: Job and Printer Extensions - Set 3 [PWG5100.13] define new attributes and operations required for mobile printing and printing with generic drivers.
The PWG Raster Format [PWG5102.4] defines a minimal file format for transmission of multi-page color and grayscale bitmap images
The Document management -- Portable document format -- Part 1: PDF 1.7 [ISO32000] defines:
1. A rich file format for transmission of multi-page color and grayscale vector and bitmap images
Page 18 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
31
32
297
298
299300301
302303304305306307308
309
310311312313314315
316317
318319
320321
322323
Working Draft – IPP Everywhere November 16, 2012
2. Standard page attributes to support page size, orientation, and duplex functionality
The JPEG File Interchange Format Version 1.02 [JFIF] defines a compact file format for transmission of photographic images
The Open XML Paper Specification [ECMA388] defines a paginated document format based on Open Packaging Conventions (OPC) [ISO29500-2], Extensible Markup Language (XML) [XML11], and standard image and font formats with device-independent color.
The Bonjour Printing Specification version 1.0.2 [BONJOUR] defines:
1. Discovery of Printers using Domain Name System (DNS) service (SRV) lookups [RFC2782]
2. Multicast DNS for use on link-local networks [mDNS]3. Automatic address assignment for both IPv4 [RFC3927] and IPv64. DNS text (TXT) record keys to support auto-configuration, capabilities,
identification, and protocol selection
The Lightweight Directory Access Protocol (LDAP): Schema for Printer Services [RFC3712] defines a schema for Printer registrations and discovery via LDAP [RFC4510] and Service Location Protocol (SLP) [RFC2608] services.
The OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1 [WS-DISCOVERY] defines a discovery protocol to locate services.
3.2 Use Cases
3.2.1 Select Printer
Printer selection is part of most Print use cases - Jane selects a Printer, implicitly or explicitly, and the remainder of the use case applies to the selected Printer. A Printer can be a Logical Printer (Service) or a Physical Printer (section 2.2). Selection use cases can often be combined, for example Selection Using a Directory Service (section 3.2.1.4) with Selection Using Properties (section 3.2.1.9).
Page 19 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
33
34
324325
326327
328329330331
332
333334335336337338
339340341
342343
344
345
346347348349350
Working Draft – IPP Everywhere November 16, 2012
In order to simplify the selection use cases, common exceptions are listed as separate use cases in section 3.2.3.
Precondition: For all of the following use cases, the Printer is Network Accessible to be selected, either directly or through an intermediate Service.
3.2.1.1 Select the Last Used Printer
The Client User Interface provides the last used Printer as a selection. Jane then confirms the selection of the last used Printer.
The last used Printer may be automatically selected by the Client User Interface and may be affected by the current network topology or geo-location, for example the last used Printer may be tracked on a per-network (e.g., default router or other criteria), per-location (e.g., geo-location), or per-Service (e.g., current local server) basis.
3.2.1.2 Select Printer Using Name or Address
The Client User Interface asks Jane for a name or address for the Printer. She then provides a Printer name or address through the Client User Interface. Finally, the Client User Interface queries the Printer for valid Service Uniform Resource Identifiers (URIs).
The Printer name can be a DNS Service Discovery (DNS-SD) Service name, a fully-qualified domain name, or other unique identifying name. The Printer address can be a numeric IP address or other unique identifying number.
3.2.1.3 Select Printer Using URI
The Client User Interface asks Jane for a Service URI for the Printer. She then provides a URI through the Client User Interface or cancels selection.
For example, Jane could supply an IPP URI: "ipp://example.com/port1" as reported by the Printer's network configuration page.
3.2.1.4 Select Printer Using a Directory Service
The Client obtains a list of Printers on behalf of Jane from the Directory Service and validates that each Printer supports one or more Client-supported Service protocols. The
Page 20 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
35
36
351352
353354
355
356357
358359360361
362
363364365
366367368
369
370371
372373
374
375376
Working Draft – IPP Everywhere November 16, 2012
Client User Interface then asks Jane to select one of the supported Printers. Finally, she selects a Printer.
Preconditions: One or more Printers are listed in a Directory Service and that Directory Service is Network Accessible to the Client.
3.2.1.5 Select Printer Using a Cloud Service
The Client obtains a list of Printers on behalf of Jane from the Cloud Service(s). The Client User Interface then asks Jane to select one of the Printers. Finally, she selects a Printer.
Preconditions: The Client and one or more Printers are registered with a Cloud Service, and that Cloud Service is Network Accessible to both the Client and Printers. The Client and Printers may be registered with multiple Cloud Services, and both may maintain multiple identities for a particular Cloud Service.
3.2.1.6 Select Printer Using a Discovery Protocol
The Client initiates Discovery on behalf of Jane and maintains a dynamic list of Network Accessible Printers during selection. The Client User Interface asks Jane to select one of the Network Accessible Printers, updating those Printers as they come and go. Finally, she selects a Printer and the Client terminates Discovery.
Preconditions: The Printer is Network Accessible to the Client and supports a common Discovery Protocol.
3.2.1.7 Select Printer Using Geo-Location
The Client initiates Enumeration of Printers within a geographic area using Services and/or Discovery Protocols, hiding duplicate Printers that are reported by multiple Service and/or Discovery Protocols. The Client User Interface asks Jane to select one of the Printers. Finally, she selects a Printer.
Preconditions: Both the Client and Printer have access to geo-location information to allow for Enumeration within a geographic area, and both support common Discovery Protocol(s).
Page 21 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
37
38
377378
379380
381
382383
384385386387
388
389390391392
393394
395
396397398399
400401402
Working Draft – IPP Everywhere November 16, 2012
3.2.1.8 Select Printer Using Out of Band Method
Jane asks the Client User Interface to identify the Printer using a built-in camera, Near-Field Communications (NFC) chip, or other sensing technology. The Client initiates identification to obtain a Service URI and descriptive information. The Client User Interface then asks Jane to confirm the selection of the identified Printer. Finally, she confirms the selection.
Precondition: The Printer and Client support a common identifying technology such as NFC, Quick Response Codes (QRCodes), or bar codes.
3.2.1.9 Select Printer Using Properties
Jane selects a Printer using properties such as Service, capability, or description properties of the Printer. Service properties include the application (printing) protocol, security, or restrictions such as the maximum number of pages allowed in a job. Capability properties include values such as media, duplex, finishing, color support, and so forth, Description properties include values such as location, speed, color support, and job size. The properties may be provided by a combination of user input, policy, and/or software heuristic.
Jane asks the Client User Interface to select using properties. The Client obtains a list of Printers for Jane that meet the given properties provided by the Client software, policy, and/or user and validates that each Printer supports one or more Client-supported Service protocols. The Client User Interface then asks Jane to select one of the supported Printers. Finally, she selects a Printer.
3.2.2 Print
Each of the use cases in this section begin by initiating a print action, selecting a Printer (section 3.2.1), querying the Printer status, capabilities, and status information, and displaying of any status information important to the User. Each use case generally ends with Jane collecting the printout from the Printer.
Preconditions: For all of the following use cases, the Printer must be Network Accessible to the Client in order to be selected, either directly or through an intermediate Service. Also, the document to be printed must be Network Accessible to the Printer and in a format suitable for the Printer or converted by the Client or Service into a suitable format.
Page 22 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
39
40
403
404405406407408
409410
411
412413414415416417418
419420421422423
424
425426427428
429430431432
Working Draft – IPP Everywhere November 16, 2012
3.2.2.1 Print a Document
Jane has a Client connected to the Wi-Fi network in her business and has a document to print prior to a meeting that is stored on her phone.
After Jane initiates a print action and selects a Printer, she specifies the processing intent for the Job and confirms the print action. The Client sends a print job request to the Printer with the Job Ticket and attached document data. The Printer validates the Job Ticket and document data and then prints the document.
3.2.2.2 Print a Document by Reference
Jane has a Client connected to the Wi-Fi network in her business and is viewing a document on a server that she would like to print.
After Jane initiates a print action and selects a Printer, she specifies the processing intent for the Job and confirms the print action. The Client sends a print job request to the Printer with the Job Ticket and document URI. The Printer validates the Job Ticket and document URI and then prints the document.
3.2.2.3 Print Using Loaded Media
Jane is viewing a photo and would like to print the photo on the largest borderless photographic media loaded on her Printer.
After Jane initiates a print action from the phone and selects a Printer, the Client photo application automatically selects the largest borderless photographic media loaded on the Selected Printer and the highest print quality. Jane selects additional processing intent for the Job and confirms the print action. The Client sends a print job request to the Printer with the Job Ticket and local photo. The Printer validates the Job Ticket and document data and then prints the photo.
Preconditions: Printer can report loaded media information such as size, orientation, type, coating, and weight. This may be detected automatically or manually entered by the User or Operator when loading the media.
Page 23 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
41
42
433
434435
436437438439
440
441442
443444445446
447
448449
450451452453454455
456457458
Working Draft – IPP Everywhere November 16, 2012
3.2.2.4 Print a Secure Form
The treasurer of a small training company that is holding a meeting and seminar at a resort needs to print out 20 checks for training personnel. He uses an accounting program to enter the hours worked, bonuses, reimbursable expenses, and so forth and prints the checks on a printer provided by the resort using check blanks he brought to the meeting.
The treasurer loads check blanks into the Printer and configured the loaded media as necessary at the Printer. After he initiates a print action from the accounting program, selects a Printer for printing, and selects checks to be printed, the Client User Interface displays a preview of the printed checks and he confirms that the checks are correctly paginated and oriented and the amounts, payees and signature are correct. The Client automatically selects the check blank media. The treasurer selects additional processing intent for the Job and confirms the print action. The Client sends a print job request to the Printer with the Job Ticket and document data containing the check information, correctly oriented for the check blank media. He waits for the checks to be printed and removes any excess media from the Printer.
Preconditions: Printer can report loaded media information such as size, orientation, type, coating, and weight. This may be detected automatically or manually entered by the User or Operator when loading the media.
3.2.2.5 Print with Special Formatting
At a seminar located at a country resort, an assistant has been asked to provide 80 sets of ten keywords/phrases, clearly printed on 2-inch by 1-inch paper slips for use in a get acquainted exercise. Costs are to be minimized. The assistant has a laptop with a word processer program. The resort has a Wi-Fi network available to Users and a networked MFD at the business center. The attendant at the business center will charge for any printed sheets removed from the premises.
After the assistant initiates a print action from the word processor and selects a Printer, he selects the processing intent for the Job and confirms the print action. The word processor produces document data using the media information (size and margins) in the Job Ticket so that 2-inch by 1-inch slips are spread evenly over each page and sends a print job
Page 24 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
43
44
459
460461462463464
465466467468469470471472473474
475476477
478
479480481482483484
485486487488
Working Draft – IPP Everywhere November 16, 2012
request to the Printer with the Job Ticket and document. The Printer validates the Job Ticket and document data and then prints the document.
3.2.2.6 Print and Select at Printer
One or more Printers are associated with a Service that allows Users to release and print Jobs at any associated Printer. Each User may release a job at a given Printer by providing a Personal Identification Number (PIN) and/or other unique identification/authorization information such as a username and password or IDentification (ID) card.
After initiating a print action and selecting a Service, Jane specifies the processing intent and PIN for the Job and confirms the print action. The Client sends a print job request to the Service with the Job Ticket and local document. The Service validates the Job Ticket and document data and then holds the document until released by Jane at the Printer.
Precondition: The Client and Printer support a common authorization or identification system. The capability of associated Printers are the same or the User selects a best-effort job processing intent.
3.2.2.7 Print to a Service
John is flying to New York for a presentation and doesn't want to carry the presentations. John arrives in New York and goes online from his mobile phone. After initiating a print action, he selects a local print provider, reviewing the provider web pages as needed. He then specifies the processing intent as 10 color copies, printed duplex and stapled on the left side, with the covers on 80lb. stock and the internal pages on 24lb. stock. After confirming the print action, John goes to the provider and picks up his presentations, paying with his corporate credit card.
3.2.2.8 Print to a Recipient
The recipient may release a job at a given Printer by providing a PIN and/or other unique identification/authorization information such as a username and password or ID card.
After initiating a print action and selecting a Printer, Jane specifies the processing intent, specifies John as the recipient, and confirms the print action. The Client sends a print job request to the Printer with the Job Ticket and local document. The Printer validates the
Page 25 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
45
46
489490
491
492493494495496
497498499500
501502503
504
505506507508509510511
512
513514
515516517
Working Draft – IPP Everywhere November 16, 2012
Job Ticket and document data and then holds the document until released by John. Finally, John collects the printout from the Printer.
3.2.2.9 Print with a Proof Copy
After initiating a print action and selecting a Printer, John specifies the processing intent, requests a proof print, and confirms the print action. The Client sends a print job request to the Printer with the Job Ticket and local document. The Printer validates the Job Ticket and document data and then prints a proof copy of the document. John collects the proof printout from the Printer and verifies correct output. John then initiates a full print of the document from the Client or Printer to produce part or all of the final output.
3.2.3 Exceptions
3.2.3.1 Print Action Canceled
Jane cancels the print action UI. The Client then discontinues any active printer selection, print job submission, or other operations and cancels any incomplete print job submission as needed.
3.2.3.2 Select Printer Canceled
John cancels selection of a Printer. The Client then discontinues any active discovery, Enumeration, or query operations as needed.
3.2.3.3 Printer No Longer Network Accessible after Selection
After selecting a Network Accessible Printer, the Client, selected Printer, or network suffers a failure preventing the Client from communicating with the Printer. Typically this will display an error message on the Client and cancel the print request.
3.2.3.4 Not Authorized
After confirming the print request, the Printer responds that the User is not authorized to print the Job document(s). The reason for the authorization failure may involve general access to the Printer, Job document(s), or disallowed Job Ticket values, for example a User may not be allowed to print in color.
Page 26 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
47
48
518519
520
521522523524525526
527
528
529530531
532
533534
535
536537538
539
540541542543
Working Draft – IPP Everywhere November 16, 2012
Precondition: The Printer has access to a file, database, or Service that provides authorization information.
3.2.3.5 Needs Authentication
After confirming the print request or selecting the Printer, the User is asked to authenticate with the Printer in order to gain access.
Precondition: The Printer has access to a file, database, or Service that provide authentication and authorization information.
3.2.3.6 Not Accepting Jobs
After confirming the print request, the Client discovers that the Printer is no longer accepting jobs, displays an error message, and cancels the print request.
3.2.3.7 Job Ticket or Document Format Not Supported
After confirming the print request, the Printer rejects the request because the job ticket or document format is not supported. The Client displays an error message and cancels the print request.
3.2.3.8 Job or Document Processing Failures
While processing a job, the Printer reports job or document processing issues to the Client, which displays an error message as needed and asks the User or Operator to confirm the disposition of the Job. Processing failures include out-of-memory, missing resources, and other conditions that prevent a particular Job or document from printing.
3.2.3.9 Printer Fault
While processing a Job, the Printer reports faults to the Client, which displays an error message as needed and asks the User or Operator to confirm the disposition of the Job. Printer faults include "out of paper" and other conditions that stop the processing of Jobs.
Page 27 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
49
50
544545
546
547548
549550
551
552553
554
555556557
558
559560561562
563
564565566
Working Draft – IPP Everywhere November 16, 2012
3.2.3.10 Printer Warning
While processing a Job, the Printer reports warnings to the Client, which provides a warning message as needed. Printer warnings include "low toner" and other advisory conditions that do not stop the processing of Jobs and do not require immediate attention.
3.3 Out of Scope
The following elements of the use cases are considered out of scope for this specification:
1. The actual method of geo-location and geographic area detection for the Select Printer Using Geo-Location (section 3.2.1.7) use case
2. The actual method of payment for the Print to a Service (section 3.2.2.7) use case
3. Constraining choice of document formats suitable for the Print use cases4. Definition of new discovery protocols used to find Network Accessible Printers
(however, extension of existing protocols is still in scope)
3.4 Design Requirements
The IPP Everywhere design should:
1. Define conformance profiles that reference the IPP/2.0 versions [PWG5100.12];2. Follow the naming conventions defined in IETF IPP/1.1 [RFC2911], including
keyword value case (lower) and hyphenation requirements;3. Define conformance requirements for both Printers and Clients; and4. Support printing with vendor-neutral Client software from any Client to any
Printer using a variety of discovery protocols, IPP for the transport, and standard document formats.
Page 28 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
51
52
567
568569570
571
572
573574575576577578579
580
581
582583584585586587588
589
Working Draft – IPP Everywhere November 16, 2012
4. Discovery Protocols
Printers MUST support DNS-SD and WS-Discovery based Discovery. Printers MAY support other Discovery protocols such as LDAP, SLP, and SSDP.
Clients MUST support DNS-SD and/or WS-Discovery. Clients MAY support other Discovery protocols such as LDAP, SLP, and SSDP.
4.1 Printer Description Attributes Used in Discovery
Table 1 lists the Printer Description attributes that would normally be used for Discovery or filtering of discovered Printers based on one or more specified Printer attribute values.
4.2 DNS Service Discovery (DNS-SD)
DNS Service Discovery [DNS-SD] uses service (SRV) records and traditional unicast and multicast DNS (mDNS) [mDNS] queries. This discovery protocol is collectively defined in the Bonjour Printing Specification version 1.0.2 [BONJOUR] and extended in this specification.
Printers MUST support mDNS and MAY support dynamic DNS updates via Dynamic Updates in the Domain Name System (DNS UPDATE) [RFC2136] and other mechanisms.
4.2.1 Service (SRV) Instance Name
Printers MUST NOT use a service instance name containing a unique identifier by default. A unique identifier MAY be added to the instance if there is a name collision.
Printers MUST advertise the "_ipp._tcp" (generic IPP) and "_ipp._tcp,_print" (IPP Everywhere) services over mDNS.
Printers supporting the "ipps" URI scheme [IPPS] MUST advertise the "_ipps._tcp" (generic IPPS) and "_ipps._tcp,_print" (IPP Everywhere Secure) services over mDNS.
The domain portion of the service instance name MUST BE "local." for mDNS.
Page 29 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
53
54
590
591592
593594
595
596597
598
599600601602
603604
605
606607
608609
610611
612
Working Draft – IPP Everywhere November 16, 2012
4.2.2 Geo-Location (LOC)
Printers MUST publish LOC records [RFC1876] over mDNS to provide the physical location of the Printer. Printers MUST allow the User to configure the geo-location manually. If the accuracy of the geo-location is unknown, a value of 9x109 meters (0x99) MUST be used.
Page 30 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
55
56
613
614615616617
618
Working Draft – IPP Everywhere November 16, 2012
Table 1 - Attributes in Discovery Protocols
IPP Attribute DNS-SD TXT Key LDAP/SLP Attribute
color-supported Color printer-color-supported
copies-supported Copies printer-copies-supported
device-service-count (note 2) printer-device-service-count (note 1)
device-uuid DUUID printer-device-uuid (note 1)
document-formats-supported
pdl printer-document-format-supported
finishings-supported Bind, Punch, Sort, Staple
printer-finishings-supported
ipp-versions-supported (subtype) printer-ipp-versions-supported
media-supported PaperCustom, PaperMax
printer-media-supported
multiple-document-handling Collate -
pages-per-minute (note 2) printer-pages-per-minute
pages-per-minute-color (note 2) printer-pages-per-minute-color
printer-charge-info (note 2) printer-charge-info
(note 1)
printer-charge-info-uri chargeuri printer-charge-info-uri
(note 1)
printer-device-id usb_CMD, printer-device-id (note 1)
Page 31 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
57
58
619
Working Draft – IPP Everywhere November 16, 2012
IPP Attribute DNS-SD TXT Key LDAP/SLP Attribute
usb_MDL, usb_MFG
printer-geo-location (LOC record) printer-geo-location
(note 1)
printer-info (instance) printer-info
printer-location note printer-location
printer-make-and-model ty printer-make-and-model
printer-more-info adminurl printer-more-info
printer-name (instance) printer-name
printer-organization (note 2) O
printer-organizational-unit (note 2) OU
printer-uri-supported (service + host + port) rp
printer-uri, printer-xri-supported
printer-uuid UUID printer-uuid (note 1)
sides-supported Duplex printer-sides-supported
uri-authentication-supported air printer-xri-supported
uri-security-supported TLS printer-xri-supported
Note 1: Extension attribute to RFC 3712.Note 2: Available via subsequent IPP Get-Printer-Attributes request.
4.2.3 Text (TXT)
Printers MUST publish a text (TXT) record that provides service information over mDNS. Printers that support dynamic DNS updates MUST publish separate TXT records for each
Page 32 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
59
60
620621
622
623624
Working Draft – IPP Everywhere November 16, 2012
domain that is updated. The following subsections define new key/value pairs in addition to those required by the Bonjour Printing Specification [BONJOUR].
Page 33 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
61
62
625626
Working Draft – IPP Everywhere November 16, 2012
lists all of the key/value pairs that are defined with the corresponding default values. Printers SHOULD omit key/value pairs when the value matches the default value for the corresponding key to limit the size of the TXT record.
The combined length of a TXT key/value pair ("key=value") cannot exceed 255 octets. This limit is sometimes smaller than the limit imposed by the corresponding IPP attribute.
For example, the IPP "printer-more-info" attribute has a maximum length of 1023 octets, however the corresponding "adminurl" key cannot represent a value longer than 246 octets (255 - 9 octets for "adminurl="). Printers MUST truncate long strings as described in section 13.
The combined length of all TXT key/value pairs provided by the Printer SHOULD BE 400 octets or less for unicast DNS and MUST NOT exceed 1300 octets for multicast DNS.
Printers MUST provide the "rp" TXT key/value pair within the first 400 octets of the TXT record. Table 2 shows the priority of TXT key/value pairs.
Table 2 - Priority of DNS TXT Key/Value Pairs
Most Important
Access Keys Identification Keys Capability Keys
Least Important
Keys
rp
txtvers
priority
qtotal
note
air
TLS
adminurl
UUID
DUUID
ty
Color
Duplex
Copies
Collate
PaperMax
PaperCustom
Bind
Punch
Product
usb_MFG
usb_MDL
usb_CMD
pdl
Page 34 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
63
64
627628629
630631
632633634635
636637
638639
640
Working Draft – IPP Everywhere November 16, 2012
Sort
Staple
Clients MUST ignore incomplete key/value pairs at the end of a truncated TXT record.
Page 35 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
65
66
641
642
Working Draft – IPP Everywhere November 16, 2012
Table 3 - DNS TXT Record Keys
Key Description Default Value
adminurl The Printer-resident configuration page URL as reported by the "printer-more-info" Printer Description attribute.
'' (empty string)
air The type of authentication information that is required for the Printer. See section 4.2.3.1.
'none'
Bind 'T' if the Printer can bind output, 'F' otherwise.
'U' (note 1)
Collate 'T' if the Printer can collate copies, 'F' otherwise.
'U' (note 1)
Color 'T' if the Printer supports color printing, 'F' otherwise.
'U' (note 1)
Copies 'T' if the Printer can make copies on its own, 'F' otherwise.
'U' (note 1)
Duplex 'T' if the Printer supports duplex printing, 'F' otherwise
'U' (note 1)
DUUID The UUID of the Device without the "urn:uuid:" prefix as reported by the "device-uuid" Printer Description attribute. See section 4.2.3.9.
'' (empty string)
note The location of the Printer as reported by the "printer-location" Printer Description attribute.
'' (empty string)
PaperCustom 'T' if the Printer supports custom media sizes, 'F' otherwise.
'U' (note 1)
Page 36 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
67
68
643
Working Draft – IPP Everywhere November 16, 2012
Key Description Default Value
PaperMax The maximum media size supported by the Printer: '<legal-A4', 'legal-A4', 'isoC-A2', '>isoC-A2'.
'legal-A4'
pdl A comma-delimited list of supported MIME media types. See section 4.2.3.2.
'' (empty string)
priority The priority for the service from 0 to 99, where 0 is the highest priority and 99 is the lowest priority.
'50'
product The PostScript product name, typically the value reported by the "printer-make-and-model" Printer Description attribute with parenthesis, e.g., '(Example Model)'.
'' (empty string)
Punch 'T' if the Printer can punch output, 'F' otherwise.
'U' (note 1)
qtotal The number of queues for this Printer. MUST have the value '1'. See section 4.2.3.3
'1'
rp The remote print queue name, which is the resource path portion of the Printer URI without the leading slash.
'' (empty string)
Sort 'T' if the Printer can sort output, 'F' otherwise.
'U' (note 1)
Staple 'T' if the Printer can staple output, 'F' otherwise.
'U' (note 1)
TLS The maximum TLS version supported or 'none' if no version of TLS is supported. See section 4.2.3.4.
'none'
txtvers The major version of the Bonjour printing '1'
Page 37 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
69
70
Working Draft – IPP Everywhere November 16, 2012
Key Description Default Value
specification. MUST have the value '1'.
ty The make and model of the Printer as reported by the "printer-make-and-model" Printer Description attribute.
'' (empty string)
usb_CMD The IEEE 1284 Device ID command set value. See section 4.2.3.5.
'' (empty string)
usb_MDL The IEEE 1284 Device ID model value. See section 4.2.3.7.
'' (empty string)
usb_MFG The IEEE 1284 Device ID manufacturer value. See section 4.2.3.6.
'' (empty string)
UUID The UUID of the Printer without the 'urn:uuid:' prefix as reported by the "printer-uuid" Printer Description attribute. See section 4.2.3.8.
'' (empty string)
Note 1: The value 'U' means "undefined".
4.2.3.1 air
The "air" key defines the type of authentication information that is required for imaging. The name "air" comes from the CUPS "auth-info-required" Printer Description attribute [CUPSIPP] that extends the "uri-authentication-supported" Printer Description attribute [RFC2911]. The following values are supported:
'certificate'; Authentication using Secure Sockets Layer (SSL) and Transport Layer Security (TLS) certificates. This is equivalent to the value 'certificate' for the "uri-authentication-supported" Printer Description attribute [RFC2911].
'negotiate'; Kerberized authentication is required [RFC4559]. This is equivalent to the 'negotiate' value for the "uri-authentication-supported" Printer Description attribute [PWG5100.13].
Page 38 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
71
72
644
645
646647648649
650651652
653654655
Working Draft – IPP Everywhere November 16, 2012
'none'; No authentication is required. This is equivalent to the value 'none' for the "uri-authentication-supported" Printer Description attribute [RFC2911].
'username,password'; Username + password authentication is required. This is equivalent to the values 'basic' or 'digest' for the "uri-authentication-supported" Printer Description attribute [RFC2911].
The default value for the "air" key is 'none'.
4.2.3.2 pdl
The REQUIRED "pdl" (Page Description Language) key lists the supported MIME media types. Because the total length of a key/value pair is 255 octets, the "pdl" value is typically a subset of the values reported by the "document-format-supported" Printer Description attribute. Printers SHOULD populate the "pdl" key with a comma-delimited list of the REQUIRED and preferred Multipurpose Internet Mail Extensions (MIME) media types and MUST NOT list the 'application/octet-stream' MIME media type.
4.2.3.3 qtotal
The "qtotal" key defines the number of services supported by the Printer with this service instance name. While the Bonjour Printing Specification [BONJOUR] does allow Printers to advertise multiple services with the same name using multiple TXT records, historically this functionality has caused interoperability and stability issues for Printers and Clients that support multiple network interfaces, e.g., Wi-Fi and Ethernet. Therefore, Printers MUST NOT advertise multiple services using the same name and MUST always use the default value (1) for the "qtotal" key and advertise the default (print) service in the TXT record. Printers with multiple print service endpoints MAY advertise multiple uniquely named services, each providing a single TXT record for their corresponding information.
4.2.3.4 TLS
The "TLS" key defines the highest version of TLS that is supported for encrypted communications with the Printer. The following values are currently defined:
'none'; No encryption is supported. This is equivalent to the value 'none' for the "uri-security-supported" Printer Description attribute.
Page 39 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
73
74
656657
658659660
661
662
663664665666667668
669
670671672673674675676677678
679
680681
682683
Working Draft – IPP Everywhere November 16, 2012
'1.0'; TLS 1.0 [RFC2246] encryption is supported. This is equivalent to the value 'tls' for the "uri-security-supported" Printer Description attribute.
'1.1'; TLS 1.1 [RFC4346] encryption is supported. This is equivalent to the value 'tls' for the "uri-security-supported" Printer Description attribute.
'1.2'; TLS 1.2 [RFC5246] encryption is supported. This is equivalent to the value 'tls' for the "uri-security-supported" Printer Description attribute.
The default value of the "TLS" key is 'none'. Version numbers correspond to the currently defined TLS protocol versions as defined by the IETF and are not limited to the version numbers shown above.
4.2.3.5 usb_CMD
The REQUIRED "usb_CMD" key provides the COMMAND SET (CMD) [PWG5107.2] value from the "printer-device-id" Printer attribute.
4.2.3.6 usb_MFG
The REQUIRED "usb_MFG" key provides the MANUFACTURER (MFG) value from the "printer-device-id" Printer attribute.
4.2.3.7 usb_MDL
The REQUIRED "usb_MDL" key provides the MODEL (MDL) value from the "printer-device-id" Printer attribute.
4.2.3.8 UUID
The REQUIRED "UUID" key provides the value of the "printer-uuid" Printer Description attribute [RFC4122] [PWG 5100.13] without the leading "urn:uuid:". For example, if a Printer reports a "printer-uuid" value of:
urn:uuid:12345678-9ABC-DEF0-1234-56789ABCDEF0
The "UUID" key will have a value of:
12345678-9ABC-DEF0-1234-56789ABCDEF0
Page 40 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
75
76
684685
686687
688689
690691692
693
694695
696
697698
699
700701
702
703704705
706
707
708
Working Draft – IPP Everywhere November 16, 2012
Note: The "printer-uuid" value is used instead of "device-uuid" because DNS-SD identifies services and not devices.
4.2.3.9 DUUID
The "DUUID" key provides the value of the "device-uuid" Printer Description attribute [RFC4122] [PWG 5100.13] without the leading "urn:uuid:". For example, if a Printer reports a "device-uuid" value of:
urn:uuid:12345678-9ABC-DEF0-1234-56789ABCDEF0
The "DUUID" key will have a value of:
12345678-9ABC-DEF0-1234-56789ABCDEF0
4.3 LDAP and SLP Discovery
LDAP and SLP discovery use the schema defined in Lightweight Directory Access Protocol (LDAP): Schema for Printer Services [RFC3712] [RFC4511] [RFC4515].
Both LDAP and SLP impose hard limits on the lengths of string values, typically 127 or 255 octets depending on the attribute. These limits are sometimes smaller than the limits imposed by the corresponding IPP attributes.
For example, the IPP "printer-device-id" attribute has a maximum length of 1023 octets, however the corresponding LDAP "printer-device-id" attribute has a maximum length of 255 octets. Printers MUST truncate long strings as defined in section 13.
4.4 SSDP Discovery
The Simple Service Discovery Protocol (SSDP) is a multicast protocol used to support discovery of Universal Plug-and-Play (UPnP) [UPNP1.1] network devices and services. This document defines a new device template named "Printer:2" that is compliant with the UPnP Device Architecture, Version 1.1. The goal of Printer:2 is to modify the UPnP Printer Device template as minimally as possible to support the discovery of Printers. In this case UPnP is being used as a Discovery Service for an Printer and provides basic information about the capabilities of a Print class device without having to query the Printer's IPP attributes. After Discovery, all additional communication with the device is done via IPP.
Page 41 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
77
78
709710
711
712713714
715
716
717
718
719720
721722723
724725726
727
728729730731732733734735
Working Draft – IPP Everywhere November 16, 2012
Figure 1 - UPnP Printer:2 Functional Diagram
Figure 1 illustrates a Printer Device with the required service being the IPPEverywhere Service. The Printer Device includes the location of the endpoints for communicating with the device. The Printer:2 advertisement includes the equivalent of the DNS-SD TXT records for the Printer discovered with Printer:2.
The IPPEverywhere Service is REQUIRED in a Printer:2 Device. Additional services MAY be present such as the optional PrintBasic service. The PrintBasic Service includes print-related attributes along with all Job-related attributes (e.g., JobName, DocumentFormat, Copies, etc). The optional PrintEnhancedLayout Service extends the PrintBasic service with additional operations and semantics. Both PrintBasic and PrintEnhancedLayout are OPTIONAL and provided only for legacy device support.
Page 42 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
79
80
736
737
738
739740741742
743744745746747748
Working Draft – IPP Everywhere November 16, 2012
4.4.1 Device Definitions
4.4.1.1 Device Type
The following device type identifies a device that is compliant with this template:
urn:schemas-upnp-org:device:printer:2
4.4.1.2 Device Model
Products that expose devices of the type printer:2 must implement minimum version numbers of all required embedded devices and services specified in Table 4.
Table 4 - Device Requirements for urn:schemas-upnp-org:printer:2
Device Type
Root Req or Opt (note 1)
Service Type Req or Opt (note 1)
Service ID
(note 2)
Printer:2 Root R PrintBasic:1 O 1
PrintEnhancedLayout:1 O 2
IPPEverywhere:1 R 3
Note 1: R = Required, O = Optional, X = Non-standard. Note 2: Prefixed by urn:upnp-org:serviceId:
4.4.1.3 Description of Device Requirements
The IPPEverywhere Service is a required service for a Printer:2 Device.
4.4.1.4 Relationships Between Services
The Printer Device only REQUIRES one service, the IPPEverywhere Service. When PrintBasic or PrintEnhancedLayout are implemented, they are independent of IPPEverywhere, although PrintEnhancedLayout has a strong tie to PrintBasic. Again, these optional services are only present for backward compatibility
Page 43 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
81
82
749
750
751
752
753
754755
756
757758
759
760
761
762763764765
Working Draft – IPP Everywhere November 16, 2012
4.4.2 Theory of Operation
4.4.2.1 Discovery
When a device is added to the network, the UPnP discovery protocol allows that device to advertise its services to User control points on the network. The UPnP discovery protocol is based on SSDP. The Printer Device must announce itself as:
1. a root device2. a device UUID for its device type3. a device type
4.4.2.2 Job Submission and Control
Job Submission and Control are handled through standard IPP operations.
4.4.3 XML Device Description
The following XML describes a typical Printer device:
<?xml version="1.0"?><root xmlns="urn:schemas-upnp-org:device-1-0"><specVersion> <major>1</major> <minor>0</minor></specVersion><URLBase>base URL for all relative URLs</URLBase><device> <deviceType>urn:schemas-upnp-org:device:Printer:2</deviceType> <friendlyName>printer-info string</friendlyName> <manufacturer>manufacturer name</manufacturer> <manufacturerURL>URL to manufacturer site</manufacturerURL> <modelDescription>printer-make-and-model string</modelDescription> <modelName>model name</modelName> <modelNumber>model number</modelNumber> <modelURL>URL to model site</modelURL> <serialNumber>manufacturer's serial number</serialNumber> <UDN>urn:uuid:UUID</UDN> <UPC>Universal Product Code</UPC> <iconList> <icon>
Page 44 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
83
84
766
767
768769770
771772773
774
775
776
777
778779780781782783784785786787788789790791792793794795796797798
Working Draft – IPP Everywhere November 16, 2012
<mimetype>image/format</mimetype> <width>horizontal pixels</width> <height>vertical pixels</height> <depth>color depth</depth> <url>URL to icon</url> </icon> XML to declare other icons, if any, go here. </iconList> <serviceList> <service> <serviceType>urn:schemas-pwg.org:service:IPPEverywhere:1 </serviceType> <serviceId>urn:upnp-org:serviceId:3</serviceId> <adminurl>printer-more-info string</adminurl> <note>printer-location string</note> <air>Type of authentication required for the services.</air> <tls>Version of TLS supported.</tls> <rp>This key is used to specify the print queue name.</rp> <pdlp>Comma-separated list of MIME types supported by printing.</pdlp> <Bind>Set value to “T” if the printer is capable of binding its output, “F” if its not.</Bind> <Collate>Set value to “T” if the printer is capable of generating collated copies, “F” if its not.</Collate> <Color>Set value to “T” if the printer is capable of generating color output, “F” if its not.</Color> <Copies>Set value to “T” if the printer is capable of generating fast copies, “F” if its not.</Copies> <Duplex>Set value to “T” if the printer is capable of generating two-sided output, “F” if its not.</Duplex> <PaperCustom>Set value to “T” if the printer can handle custom paper sizes, “F” if its not.</PaperCustom> <PaperMax> “less-than-legal-A4”, “legal-A4”, “isoC-A2”, or “greater-than-isoC-A2”</PaperMax> <Punch> Set value to the number of holes of the hole puncher supported by the printer.</Punch> <Sort> Set value to “T” if the printer is capable of sort- ing its output, “F” if its not.</Sort> <Staple> Set value to “T” if the printer is capable of sta- pling output, “F” if its not.</Sort> </service> </serviceList> <deviceList>
Page 45 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
85
86
799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841
Working Draft – IPP Everywhere November 16, 2012
Description of embedded devices added by UPnP vendor (if any) go here. </deviceList> <presentationURL>URL for presentation</presentationURL></device></root>
4.5 WS-Discovery
Printers using OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1 [WSDD-DISCOVERY-1.1] may be discovered using the IPP Everywhere namespace (http://www.pwg.org/schemas/2012/4/ipp-everywhere) and LDAP Printer Schema. Here is an example probe message:
<s:Envelope xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:ippe="http://www.pwg.org/schemas/2012/4/ipp-everywhere" xmlns:s="http://www.w3.org/2003/05/soap-envelope" > <s:Header> <a:Action> http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe </a:Action> <a:MessageID> uuid:0a6dc791-2be6-4991-9af1-454778a1917a </a:MessageID> <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To> </s:Header> <s:Body> <d:Probe> <d:Types>ippe:Print</d:Types> <d:Scopes MatchBy="http://schemas.xmlsoap.org/ws/2005/04/discovery/ldap" > ldap:///ou=engineering,o=examplecom,c=us </d:Scopes> </d:Probe> </s:Body> </s:Envelope>
Page 46 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
87
88
842843844845846
847
848849850851
852853854855856857858859860861862863864865866867868869870871872873874875
Working Draft – IPP Everywhere November 16, 2012
5. Protocol Binding
Printers and Clients MUST support IPP/2.0, IPP/2.1, and/or IPP/2.2 as defined in Internet Printing Protocol 2.0 Second Edition [PWG5100.12] and the IPP Job and Printer Extensions - Set 3 [PWG5100.13].
While this specification defines an IPP binding, the same set of Semantic Elements can be applied to any protocol that conforms to the PWG Semantic Model.
5.1 HTTP Features
In additional to the IPP over HTTP conformance requirements defined in section 7.3 of the Internet Printing Protocol Version 2.0 Second Edition [PWG5100.12], Printers MUST support the following additional HTTP headers and status codes defined in Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616].
5.1.1 Host
Printers MUST validate the Host request header and SHOULD use the Host value in generated URIs.
5.1.2 If-Modified-Since, Last-Modified, and 304 Not Modified
Printers MUST support the If-Modified-Since request header (section 14.25 [RFC2616]), the corresponding response status ("304 Not Modified", section 10.3.5 [RFC2616]), and the Last-Modified response header (section 14.29 [RFC2616]).
The If-Modified-Since request header allows a Client to efficiently determine whether a particular resource file (icon, ICC profile, localization file, etc.) has been updated since the last time the Client requested it.
5.1.3 Cache-Control
Printers and Clients MUST conform to the caching semantics defined in section 13 [RFC2616]. Typically, most resource files provided by a Printer in a GET response will be cacheable but IPP responses in a POST response are not. Therefore, Printers MAY
Page 47 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
89
90
876
877878879
880881
882
883884885886
887
888889
890
891892893
894895896
897
898899900
Working Draft – IPP Everywhere November 16, 2012
provide a Cache-Control header in GET responses with an appropriate "max-age" value and MUST provide a Cache-Control header in IPP POST responses with the value "no-cache".
Page 48 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
91
92
901902903
904
Working Draft – IPP Everywhere November 16, 2012
5.2 IPP Operations
Table 5 lists the REQUIRED operations for a Printer. The Create-Job and Send-Document operations are required in order to support reliable job management (e.g., cancellation) during print job submission, but Printers are not required to support multiple document jobs.
Table 5 - IPP Everywhere Required Operations
Code Operation Name Reference
0x0002 Print-Job RFC 2911
0x0004 Validate-Job RFC 2911
0x0005 Create-Job (note 1) RFC 2911
0x0006 Send-Document (note 1) RFC 2911
0x0008 Cancel-Job RFC 2911
0x0009 Get-Job-Attributes RFC 2911
0x000A Get-Jobs RFC 2911
0x000B Get-Printer-Attributes RFC 2911
0x0039 Cancel-My-Jobs (note 2) PWG 5100.11
0x003B Close-Job (note 2) PWG 5100.11
0x003C Identify-Printer (note 3) PWG 5100.13
Note 1: REQUIRED in addition to those operations defined for the IPP/2.0 conformance level.Note 2: REQUIRED in addition to those operations defined for the IPP/2.0 and IPP/2.1 conformance levels.Note 3: REQUIRED in addition to those operations defined for the IPP/2.0, IPP/2.1, and IPP/2.2 conformance levels.
Page 49 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
93
94
905
906907908909
910
911912913914915916
Working Draft – IPP Everywhere November 16, 2012
5.3 IPP Printer Description Attributes
Table 6 lists the REQUIRED Printer Description attributes for a Printer.
Table 6 - IPP Everywhere Required Printer Description Attributes
Attribute Reference
charset-configured RFC 2911
charset-supported RFC 2911
color-supported RFC 2911
compression-supported RFC 2911
copies-default (note 5) RFC 2911
copies-supported (note 5) RFC 2911
document-format-default RFC 2911
document-format-supported RFC 2911
document-password-supported PWG 5100.13
feed-orientation-default (note 9) PWG 5100.11
feed-orientation-supported (note 9) PWG 5100.11
finishings-default (note 7) RFC 2911
finishings-supported (note 7) RFC 2911
generated-natural-language-supported RFC 2911
identify-actions-default (note 3) PWG 5100.13
identify-actions-supported (note 3) PWG 5100.13
ipp-extensions-supported (note 3) PWG 5100.13
ipp-versions-supported RFC 2911
Page 50 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
95
96
917
918
919
Working Draft – IPP Everywhere November 16, 2012
Attribute Reference
job-account-id-default (note 4) PWG 5100.3
job-account-id-supported (note 4) PWG 5100.3
job-accounting-user-id-default (note 4) PWG 5100.3
job-accounting-user-id-supported (note 4) PWG 5100.3
job-constraints-supported (note 3) PWG 5100.13
job-creation-attributes-supported (note 2) PWG 5100.11
job-ids-supported (note 2) PWG 5100.11
job-mandatory-attributes-default (note 4) PWG 5100.7
job-mandatory-attributes-supported (note 4) PWG 5100.7
job-password-supported (note 8) PWG 5100.11
job-password-encryption-supported (note 8) PWG 5100.11
job-preferred-attributes-supported (note 3) PWG 5100.13
job-resolvers-supported (note 3) PWG 5100.13
media-bottom-margin-supported (note 3) PWG 5100.13
media-col-database (note 2) PWG 5100.11
media-col-database.media-source-properties (note 9)
PWG 5100.13
media-col-default (note 1) PWG 5100.3
media-col-ready (note 2) PWG 5100.3
Page 51 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
97
98
Working Draft – IPP Everywhere November 16, 2012
Attribute Reference
media-col-ready.media-source-properties (note 9)
PWG 5100.13
media-col-supported (note 1) PWG 5100.3
media-default RFC 2911
media-left-margin-supported (note 3) PWG 5100.13
media-ready (note 2) RFC 2911
media-right-margin-supported (note 3) PWG 5100.13
media-size-supported (note 1) PWG 5100.3
media-source-supported (note 3) PWG 5100.13
media-supported RFC 2911
media-top-margin-supported (note 3) PWG 5100.13
media-type-supported (note 1) PWG 5100.3
multiple-document-jobs-supported (note 1) RFC 2911
multiple-operation-timeout (note 1) RFC 2911
multiple-operation-timeout-action (note 3) PWG 5100.13
natural-language-configured RFC 2911
operations-supported RFC 2911
orientation-requested-default RFC 2911
orientation-requested-supported RFC 2911
output-bin-default PWG 5100.2
output-bin-supported PWG 5100.2
Page 52 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
99
100
Working Draft – IPP Everywhere November 16, 2012
Attribute Reference
overrides-supported (note 2) PWG 5100.6
page-ranges-supported (note 6) RFC 2911
pages-per-minute RFC 2911
pages-per-minute-color RFC 2911
print-color-mode-default (note 3) PWG 5100.13
print-color-mode-supported (note 3) PWG 5100.13
print-content-optimize-default (note 3) PWG 5100.7
print-content-optimize-supported (note 3) PWG 5100.7
print-rendering-intent-default (note 3) PWG 5100.13
print-rendering-intent-supported (note 3) PWG 5100.13
print-quality-default RFC 2911
print-quality-supported RFC 2911
printer-alert (note 2) PWG 5100.9
printer-alert-description (note 2) PWG 5100.9
printer-charge-info (note 4) PWG 5100.13
printer-charge-info-uri (notes 4 and 10) PWG 5100.13
printer-config-change-date-time (note 3) PWG 5100.13
printer-config-change-time (note 3) PWG 5100.13
printer-device-id (note 2) PWG 5107.2
printer-geo-location (note 3) PWG 5100.13
printer-get-attributes-supported (note 3) PWG 5100.13
Page 53 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
101
102
Working Draft – IPP Everywhere November 16, 2012
Attribute Reference
printer-icc-profiles (notes 3 and 10) PWG 5100.13
printer-icons (notes 3 and 10) PWG 5100.13
printer-info RFC 2911
printer-is-accepting-jobs RFC 2911
printer-location RFC 2911
printer-make-and-model RFC 2911
printer-mandatory-job-attributes (note 4) PWG 5100.13
printer-more-info (note 10) RFC 2911
printer-name RFC 2911
printer-organization (note 3) PWG 5100.13
printer-organizational-unit (note 3) PWG 5100.13
printer-resolution-default RFC 2911
printer-resolution-supported RFC 2911
printer-state RFC 2911
printer-state-change-data-time (note 2) RFC 3995
printer-state-change-time (note 1) RFC 3995
printer-state-message RFC 2911
printer-state-reasons RFC 2911
printer-supply (note 3) PWG 5100.13
printer-supply-description (note 3) PWG 5100.13
printer-supply-info-uri (notes 3 and 10) PWG 5100.13
Page 54 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
103
104
Working Draft – IPP Everywhere November 16, 2012
Attribute Reference
printer-up-time RFC 2911
printer-uri-supported (note 10) RFC 2911
printer-uuid (note 3) PWG 5100.13
pwg-raster-document-resolution-supported (note 3)
PWG 5102.4
pwg-raster-document-sheet-back (note 3) PWG 5102.4
pwg-raster-document-type-supported
(note 3)
PWG 5102.4
queued-job-count RFC 2911
sides-default RFC 2911
sides-supported RFC 2911
uri-security-supported RFC 2911
uri-authentication-supported RFC 2911
which-jobs-supported (note 2) PWG 5100.11
Note 1: REQUIRED in addition to those attributes defined for the IPP/2.0 conformance level.Note 2: REQUIRED in addition to those attributes defined for the IPP/2.0 and IPP/2.1 conformance levels.Note 3: REQUIRED in addition to those attributes defined for the IPP/2.0, IPP/2.1, and IPP/2.2 conformance levels.Note 4: CONDITIONALLY REQUIRED for Printers that implement Paid Imaging services.Note 5: CONDITIONALLY REQUIRED for Printers that support the "application/openxps" or "application/pdf" MIME media types.
Page 55 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
105
106
920921922923924925926927928929
Working Draft – IPP Everywhere November 16, 2012
Note 6: CONDITIONALLY REQUIRED for Printers that support the "application/openxps" or "application/pdf" MIME media types.Note 7: CONDITIONALLY REQUIRED for Printers with finishers.Note 8: CONDITIONALLY REQUIRED for Printers that support the Print to a Recipient (section 3.2.2.8) use case.Note 9: CONDITIONALLY REQUIRED for Printers that support long-edge feed media.Note 10: URIs SHOULD use Host value from HTTP header (section 5.1.1) and MUST NOT use link-local addresses (section 8.4).
5.3.1 media-col-database (1setOf collection)
The REQUIRED "media-col-database" Printer attribute lists the supported combinations of "media-col" member attributes for a Printer. In addition to the requirements set forth in IPP: Job and Printer Extensions - Set 2 [PWG5100.11], this specification defines how a Printer advertises custom and roll-fed media capabilities in the "media-col-database" attribute.
Custom media sizes are described using rangeOfInteger values for the "x-dimension" and "y-dimension" member attributes of the "media-size" member attribute. Dimensions are provided for sheets in portrait orientation, that is the "x-dimension" ranges refer to the short axis and the "y-dimension" ranges refer to the long axis of the sheet. For example, a Printer supporting sheet media from 50x50mm to 330.2x482.6mm from the by-pass tray could report:
media-col-database = ... { media-size = { x-dimension = 5000-33020 y-dimension = 5000-48260 } media-source = 'by-pass-tray' } ...
Similarly, roll media sizes are also described using rangeOfInteger values, however the "x-dimension" value refers to the cross-feed (width) dimension and the "y-dimension" value refers to the feed (length) dimension. The supported ranges provide the capabilities of the Printer and not of any loaded media which is reported separately in the "media-col-ready" and "media-ready" attributes. For example, a Printer supporting rolls 8 to 60 inches wide and 6 inches to 300 feet long would report:
Page 56 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
107
108
930931932933934935936937938
939
940941942943944
945946947948949950
951952953954955956
957958959960961962
Working Draft – IPP Everywhere November 16, 2012
media-col-database = ... { media-size = { x-dimension = 20320-152400 y-dimension = 1524-9144000 } ...
5.3.2 media-col-ready (1setOf collection)
The REQUIRED "media-col-ready" Printer attribute lists the loaded media combinations of "media-col" member attributes for a Printer. In addition to the requirements set forth in IPP: Production Printing Attributes - Set 1 [PWG5100.3], this specification defines how a Printer advertises manually-fed and roll-fed media in the "media-col-ready" attribute.
Manual feed media sizes MUST NOT be reported in the "media-col-ready" attribute. By definition the 'manual-feed' media source requires the Printer to ask the User/Operator to load the requested media, thus the media can never be "ready" for use. However, many Printers offer a multi-purpose tray that serves as both a manual feed source and an ad-hoc paper tray. Printers that provide such a multi-purpose tray MUST advertise media loaded in the tray using a different media source such as 'by-pass-tray'.
Roll media sizes are described using an integer value for the "x-dimension" and a rangeOfInteger value for the "y-dimension" member attributes of the "media-size" member attribute. The "x-dimension" value refers to the width of the loaded roll, the lower bound of the "y-dimension" value refers to the minimum length allowed, and the upper bound of the "y-dimension" value refers to the remaining length of the loaded roll or, if the remainder is not known, the maximum length allowed.
5.3.3 media-ready (1setOf (type3 keyword | name(MAX))
The REQUIRED "media-ready" Printer attribute lists the loaded media for a Printer. In addition to the requirements set forth in Internet Printing Protocol/1.1: Model and Semantics [RFC2911], this specification defines how a Printer advertises custom, manually-fed, and roll-fed media in the "media-ready" attribute.
Manual feed media sizes MUST NOT be reported in the "media-ready" attribute. By definition the 'manual-feed' media source requires the Printer to ask the User/Operator to load the requested media, thus the media can never be "ready" for use. However, many Printers offer a multi-purpose tray that serves as both a manual feed source and an ad-
Page 57 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
109
110
963964965966
967
968969970971
972973974975976977
978979980981982983
984
985986987988
989990991992
Working Draft – IPP Everywhere November 16, 2012
hoc paper tray. Printers that provide such a multi-purpose tray MUST advertise media loaded in the tray.
Custom media sizes are described using the "custom" self-describing media size names defined in section 5 of the PWG Media Standardized Names [PWG5101.1] specification. For example, a custom media size of 4x8 inches might be listed with the name "custom_current_4x8in". The size name MUST include the source name if more than one custom size is loaded, for example "custom_current.tray-1_4x8in".
Similarly, roll media sized are described using "roll" self-describing media size names with the width of the loaded roll and a length of 0. For example, a 36 inch roll might be listed with the name "roll_current_36x0in". As for custom sizes, the size name MUST include the source name if more than one roll is loaded, for example "roll_current.roll-1_36x0in".
5.3.4 media-size-supported (1setOf collection)
The REQUIRED "media-size-supported" Printer attribute lists the supported media sizes for a Printer. In addition to the requirements set forth in [PWG5100.3], this specification defines how a Printer advertises custom and roll-fed media in the "media-size" attribute.
Custom media sizes are described using rangeOfInteger values for the "x-dimension" and "y-dimension" member attributes. Dimensions are provided for sheets in portrait orientation, that is the "x-dimension" ranges refer to the short axis and the "y-dimension" ranges refer to the long axis of the sheet. For example, a Printer supporting sheet media from 50x50mm to 330.2x482.6mm from the by-pass tray would report:
media-size-supported = ... { x-dimension = 5000-33020 y-dimension = 5000-48260 } ...
Similarly, roll media sizes are also described using rangeOfInteger values, however the "x-dimension" value refers to the cross-feed (width) dimension and the "y-dimension" value refers to the feed (length) dimension. The supported ranges provide the capabilities of the Printer and not of any loaded media which is reported separately in the "media-col-ready" and "media-ready" attributes. For example, a Printer supporting rolls 8 to 60 inches wide and 6 inches to 300 feet long would report:
Page 58 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
111
112
993994
995996997998999
1000100110021003
1004
100510061007
10081009101010111012
1013101410151016
101710181019102010211022
Working Draft – IPP Everywhere November 16, 2012
media-size-supported = ... { x-dimension = 20320-152400 y-dimension = 1524-9144000 } ...
5.3.5 media-supported (1setOf (type3 keyword | name(MAX))
The REQUIRED "media-supported" Printer attribute lists the supported media sizes for a Printer. In addition to the requirements set forth in [RFC2911], this specification defines how a Printer advertises custom and roll-fed media in the "media-supported" attribute.
Custom media sizes are described using two self-describing media names. The "custom_min_WIDTHxHEIGHTunits" value provides the minimum custom media dimensions and the "custom_max_WIDTHxHEIGHTunits" value provides the maximum custom media dimensions. The size name MUST include the source name if different dimensions are supported by each source. Dimensions are provided for sheets in portrait orientation, that is the "WIDTH" values refer to the short axis and the "HEIGHT" values refer to the long axis of the sheet. For example, a Printer supporting sheet media from 50x50mm to 330.2x482.6mm from the by-pass tray could report:
media-supported = ... custom_max.by-pass-tray_330.2x482.6mm custom_min.by-pass-tray_50x50mm ...
Similarly, roll media sizes are described using the "roll_min_WIDTHxHEIGHTunits" and "roll_max_WIDTHxHEIGHTunits" names. The "WIDTH" values refer to the supported roll widths while the "HEIGHT" values refer to the supported roll lengths. The size name MUST include the source name if the Printer supports multiple source with different roll limits.
For example, a Printer supporting a single roll 8 to 60 inches wide and 6 inches to 300 feet long would report:
media-supported = ... roll_max_60x3600in roll_min_8x6in ...
Page 59 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
113
114
1023102410251026
1027
102810291030
10311032103310341035103610371038
1039104010411042
10431044104510461047
10481049
1050105110521053
Working Draft – IPP Everywhere November 16, 2012
A Printer supporting two rolls, one 8 to 60 inches wide and 6 inches to 300 feet long and the other 8 to 36 inches wide and 6 inches to 150 feet long would report:
media-size-supported = ... roll_max.roll-1_60x3600in roll_min.roll-1_8x6in roll_max.roll-2_36x1800in roll_min.roll-2_8x6in ...
5.3.6 printer-device-id (text(1023))
The REQUIRED "printer-device-id" Printer attribute provides the IEEE 1284 Device ID [IEEE1284] string for the Imaging Device. Because discovery protocols often have lower limits on the length of string values, Printers MUST list the Device ID key/value pairs in the following order:
1. All required (MANUFACTURER/MFG, MODEL/MDL, and COMMAND SET/CMD) key/value pairs,
2. All optional key/value pairs, and3. All vendor key/value pairs
For interoperability, Printers MUST NOT report standard key/value pairs using non-standard abbreviations. For example, "MANU" is sometimes used as an abbreviation for "MANUFACTURER", however the only allowed abbreviation is "MFG".
The optional and vendor key/value pairs can be prioritized by Client software requirements. This allows the Printer to truncate the Device ID string on key/value boundaries as needed (section 13.4) without loss of critical information needed for selection of device-specific or generic driver software on the Client.
Page 60 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
115
116
10541055
105610571058105910601061
1062
1063106410651066
1067106810691070
107110721073
1074107510761077
1078
Working Draft – IPP Everywhere November 16, 2012
5.4 IPP Operation Attributes
Table 7 lists the REQUIRED operation attributes for a Printer.
Table 7 - IPP Everywhere Required Operation Attributes
Attribute Reference
compression RFC 2911
document-format RFC 2911
document-format-version (note 1) PWG 5100.7
document-name RFC 2911, PWG 5100.5
document-password (note 4) PWG 5100.13
first-index (note 3) PWG 5100.13
first-job-id RFC 2911
identify-actions (note 3) PWG 5100.13
ipp-attribute-fidelity RFC 2911
job-ids (note 2) PWG 5100.11
job-mandatory-attributes (note 6) PWG 5100.7
job-name RFC 2911
job-password (note 5) PWG 5100.11
job-password-encryption (note 5) PWG 5100.11
last-document (note 1) RFC 2911
limit RFC 2911
requesting-user-name RFC 2911
Page 61 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
117
118
1079
1080
1081
Working Draft – IPP Everywhere November 16, 2012
Attribute Reference
requesting-user-uri (note 3) PWG 5100.13
which-jobs (note 2) RFC 2911, PWG 5100.11
Note 1: REQUIRED in addition to those attributes defined for the IPP/2.0 conformance level.Note 2: REQUIRED in addition to those attributes defined for the IPP/2.0 and IPP/2.1 conformance levels.Note 3: REQUIRED in addition to those attributes defined for the IPP/2.0, IPP/2.1, and IPP/2.2 conformance levels.Note 4: CONDITIONALLY REQUIRED for Printers that support the "application/openxps" or "application/pdf" MIME media types.Note 5: CONDITIONALLY REQUIRED for Printers that support the Print to a Recipient (section 3.2.2.8) use case.Note 6: CONDITIONALLY REQUIRED for Printers that implement Paid Imaging services.
Page 62 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
119
120
108210831084108510861087108810891090109110921093
1094
Working Draft – IPP Everywhere November 16, 2012
5.5 IPP Job Template Attributes
Table 8 lists the REQUIRED Job Template attributes for a Printer.
Table 8 - IPP Everywhere Required Job Template Attributes
Attribute Reference
copies (note 5) RFC 2911
feed-orientation (note 8) PWG 5100.11
finishings (note 7) RFC 2911
job-account-id (note 4) PWG 5100.3
job-accounting-user-id (note 4) PWG 5100.3
media RFC 2911
media-col (note 1) PWG 5100.3
media-col.media-bottom-margin (note 3) PWG 5100.13
media-col.media-left-margin (note 3) PWG 5100.13
media-col.media-right-margin (note 3) PWG 5100.13
media-col.media-size (note 1) PWG 5100.3
media-col.media-source (note 3) PWG 5100.13
media-col.media-top-margin (note 3) PWG 5100.13
media-col.media-type (note 1) PWG 5100.3
multiple-document-handling (note 6) RFC 2911
orientation-requested RFC 2911
output-bin PWG 5100.2
overrides (note 2) PWG 5100.6
Page 63 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
121
122
1095
1096
1097
Working Draft – IPP Everywhere November 16, 2012
Attribute Reference
page-ranges (note 6) RFC 2911
print-color-mode (note 3) PWG 5100.13
print-content-optimize (note 3) PWG 5100.7
print-rendering-intent (note 3) PWG 5100.13
print-quality RFC 2911
printer-resolution RFC 2911
sides RFC 2911
Note 1: REQUIRED in addition to those attributes defined for the IPP/2.0 conformance level.Note 2: REQUIRED in addition to those attributes defined for the IPP/2.0 and IPP/2.1 conformance levels.Note 3: REQUIRED in addition to those attributes defined for the IPP/2.0, IPP/2.1, and IPP/2.2 conformance levels.Note 4: CONDITIONALLY REQUIRED for Printers that implement paid imaging services.Note 5: CONDITIONALLY REQUIRED for Printers that support the "application/openxps", "application/pdf", or "image/jpeg" MIME media types.Note 6: CONDITIONALLY REQUIRED for Printers that support the "application/openxps" or "application/pdf" MIME media types.Note 7: CONDITIONALLY REQUIRED for Printers with finishers.Note 8: CONDITIONALLY REQUIRED for Printers that support long-edge feed media.
Page 64 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
123
124
1098109911001101110211031104110511061107110811091110
1111
Working Draft – IPP Everywhere November 16, 2012
5.6 IPP Job Description Attributes
Table 9 lists the REQUIRED Job Description attributes for a Printer.
Table 9 - IPP Everywhere Required Job Description Attributes
Attribute Source
compression-supplied (note 1) PWG 5100.7
date-time-at-completed (note 2) RFC 2911
date-time-at-creation (note 2) RFC 2911
date-time-at-processing (note 2) RFC 2911
document-format-supplied (note 1) PWG 5100.7
document-format-version-supplied (note 1) PWG 5100.7
document-name-supplied (note 1) PWG 5100.7
job-id RFC 2911
job-impressions (note 2) RFC 2911
job-impressions-completed (note 2) RFC 2911
job-name RFC 2911
job-originating-user-name RFC 2911
job-printer-up-time RFC 2911
job-printer-uri (note 4) RFC 2911
job-state RFC 2911
job-state-message (note 3) RFC 2911
job-state-reasons RFC 2911
Page 65 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
125
126
1112
1113
1114
Working Draft – IPP Everywhere November 16, 2012
Attribute Source
job-uri (note 4) RFC 2911
job-uuid (note 3) PWG 5100.13
time-at-completed RFC 2911
time-at-creation RFC 2911
time-at-processing RFC 2911
Note 1: REQUIRED in addition to those attributes defined for the IPP/2.0 conformance level.Note 2: REQUIRED in addition to those attributes defined for the IPP/2.0 and IPP/2.1 conformance levels.Note 3: REQUIRED in addition to those attributes defined for the IPP/2.0, IPP/2.1, and IPP/2.2 conformance levels.Note 4: URIs SHOULD use Host value from HTTP header (section 5.1.1) and MUST NOT use link-local addresses (section 8.4).
5.6.1 job-id (integer)
The REQUIRED "job-id" Job Description attribute contains the ID of the Job. In order to support reliable job submission and management, Printers MUST NOT reuse "job-id" values since the last power cycle of the Printer and SHOULD NOT reuse "job-id" values for the life of the Printer as described in section 3.1.2.3.9 of the Internet Printing Protocol/1.1: Implementer's Guide [RFC3196].
5.6.2 job-uri (uri)
The REQUIRED "job-uri" Job Description attribute contains the URI of the Job. In order to support reliable job submission and management, Printers MUST NOT reuse "job-uri" values since the Printer was last powered up and SHOULD NOT reuse "job-uri" values for the life of the Printer as described in section 3.1.2.3.9 of the Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]. In addition, the "job-uri" value SHOULD be derived from the "job-id" value as described in the IPP URL Scheme [RFC3510].
Page 66 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
127
128
11151116111711181119112011211122
1123
11241125112611271128
1129
113011311132113311341135
Working Draft – IPP Everywhere November 16, 2012
6. Document Formats
Printers MUST support documents conforming to the PWG Raster Format [PWG5102.4] ("image/pwg-raster") and JPEG File Information Format Version 1.02 [JFIF] ("image/jpeg"), specifically the metadata and JPEG subset defined in the Standard of the Camera & Imaging Products Association, CIPA DC-008-Translation-2010, Exchangeable image file format for digital still cameras: Exif Version 2.3 [EXIF].
IPP/2.1 and IPP/2.2 Printers MUST and IPP/2.0 Printers SHOULD support documents conforming to Document management — Portable document format — Part 1: PDF 1.7 [ISO32000] ("application/pdf"). IPP/2.0, IPP/2.1, and IPP/2.2 Printers are defined in IPP/2.0 Second Edition [PWG5100.12].
Printers SHOULD support documents conforming to the Open XML Paper Specification [ECMA388] ("application/openxps").
6.1 Supporting Long-Edge Feed Media with PWG Raster Format Documents
Printers that support long-edge feed media MUST support the "feed-orientation" Job Template attribute and corresponding "feed-orientation-default" and "feed-orientation-supported" Printer attributes. In addition, Printers that support long-edge feed media MUST report the "media-source-properties" member attribute in the "media-col-database" and "media-col-ready" Printer attributes.
When submitting a PWG Raster document in a job or document creation request, Clients MUST additionally query the Printer for the "feed-orientation-supported", "media-col-database", and/or "media-col-ready" Printer attributes in order to provide a document in the correct orientation and dimensions for the Printer.
Figures 2 through 5 show how raster data must be formatted for each feed orientation.
Page 67 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
129
130
1136
11371138113911401141
1142114311441145
11461147
11481149
11501151115211531154
1155115611571158
1159
1160
Working Draft – IPP Everywhere November 16, 2012
Figure 2 - PWG Raster Bitmaps with Portrait Feed Orientation
Page 68 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
131
132
1161
1162
1163
Working Draft – IPP Everywhere November 16, 2012
Figure 3 - PWG Raster Bitmaps with Landscape Feed Orientation
Page 69 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
133
134
1164
1165
Working Draft – IPP Everywhere November 16, 2012
Figure 4 - PWG Raster Bitmaps with Reverse Landscape Feed Orientation
Page 70 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
135
136
1166
1167
1168
1169
Working Draft – IPP Everywhere November 16, 2012
Figure 5 - PWG Raster Bitmaps with Reverse Portrait Feed Orientation
7. Additional Values for Existing Attributes
7.1 ipp-features-supported (1setOf type2 keyword)
This specification defines the REQUIRED keyword 'ipp-everywhere' for the "ipp-features-supported" Printer attribute.
Page 71 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
137
138
1170
1171
1172
11731174
1175
Working Draft – IPP Everywhere November 16, 2012
8. Additional Semantics for Existing Value Tags
This specification amends the definition of the nameWithLanguage, nameWithoutLanguage, naturalLanguage, textWithLanguage, textWithoutLanguage, and URI value tags defined in IPP/1.1: Model and Semantics [RFC2911] with additional restrictions to improve interoperability.
8.1 nameWithLanguage and nameWithoutLanguage
Name values MUST NOT contain characters in the "C0 Control Character Set" or the DEL character as defined in Unicode Format for Network Interchange [RFC5198]. Printers MUST transcode and filter values from MIBs and other sources to conform to the added restrictions.
8.2 naturalLanguage
NaturalLanguage values MUST conform to and be compared as defined in Content Language Headers [RFC3282], Matching of Language Tags [RFC4647], and Tags for Identifying Languages [RFC5646], which are the current set of RFCs replacing Tags for the Identification of Languages [RFC1766] that was used in IPP/1.1: Model and Semantics [RFC2911]. The shortest language tag MUST be used, e.g., "en" instead of "eng" for English. Printers SHOULD also support legacy language tags such as:
'no'; replaced by 'nb' (Norwegian Bokmål),'zh-cn'; replaced by 'zh-hans' (Simplified Chinese), and'zh-tw'; replaced by 'zh-hant' (Traditional Chinese)
8.3 textWithLanguage and textWithoutLanguage
Text values MUST NOT contain the DEL character or characters in the "C0 Control Character Set" other than CR, LF, and HT [RFC5198]. Printers MUST transcode and filter values from MIBs and other sources to conform to the added restrictions.
Page 72 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
139
140
1176
1177117811791180
1181
1182118311841185
1186
118711881189119011911192
119311941195
1196
119711981199
Working Draft – IPP Everywhere November 16, 2012
8.4 uri
URI values MUST NOT contain link-local addresses in the host field. Printers MUST NOT generate URI values with link-local addresses and SHOULD NOT generate URI values with addresses obtained via Dynamic Host Control Protocol (DHCP) [RFC2131] or other auto-configuration protocols. Printers SHOULD use the HTTP Host: header value when generating URIs for use in Client responses.
Page 73 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
141
142
1200
12011202120312041205
1206
Working Draft – IPP Everywhere November 16, 2012
9. Conformance Requirements
This section summarizes the Conformance Requirements detailed in the definitions in this document for Clients and Printers.
9.1 Conformance Requirements for Clients
In order for a Client to claim conformance to this specification a Client MUST support the following:
1. DNS Service Discovery as defined in section 4.2 and/or WS-Discovery as defined in section 4.5
2. IPP/2.0 as defined in section 53. The REQUIRED operations listed in Table 54. The REQUIRED Printer Description attributes listed in Table 65. The REQUIRED operation attributes listed in Table 76. The REQUIRED Job Template attributes listed in Table 87. The REQUIRED Job Description attributes listed in Table 98. The REQUIRED document formats listed in section 69. The "feed-orientation-supported" Printer attribute and "media-source-properties"
member attribute of the "media-col-database" and "media-col-ready" Printer attributes as reported by the Printer and defined in section 6.1
10.The internationalization considerations as defined in section 1011.The security considerations as defined in section 11
9.2 Conformance Requirements for Printers
In order for a Printer to claim conformance to this specification a Printer MUST support the following:
1. DNS Service Discovery as defined in section 4.22. WS-Discovery as defined in section 4.53. IPP/2.0 as defined in section 54. The REQUIRED operations listed in Table 55. The REQUIRED Printer Description attributes listed in Table 6
Page 74 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
143
144
1207
12081209
1210
12111212
12131214121512161217121812191220122112221223122412251226
1227
12281229
12301231123212331234
Working Draft – IPP Everywhere November 16, 2012
6. The REQUIRED operation attributes listed in Table 77. The REQUIRED Job Template attributes listed in Table 88. The REQUIRED Job Description attributes listed in Table 99. The REQUIRED document formats listed in section 610.The 'ipp-everywhere' value for the "ipp-features-supported" Printer Description
attribute as defined in section 7.111.The additional semantics for attribute values as defined in section 812.The internationalization considerations as defined in section 1013.The security considerations as defined in section 1114.The safe string truncation rules as defined in section 13
9.3 Conditional Conformance Requirements for Printers
Printers that support the "image/jpeg" [JFIF] MIME media type MUST support:
1. The "copies-default", and "copies-supported" Printer Description attributes as defined in section 5.3.
2. The "copies Job Template attribute as defined in section 5.5.
Printers that support the "application/openxps" [ECMA388] or "application/pdf" [ISO32000] MIME media types MUST support:
3. The "copies-default", "copies-supported", "document-password-supported", and "page-ranges-supported" Printer Description attributes as defined in section 5.3,
4. The "document-password" Operation attribute as defined in section 5.4, and5. The "copies", "multiple-document-handling", "overrides", and "page-ranges" Job
Template attributes as defined in section 5.5.
Printers that support the Print to a Recipient use case (section 3.2.2.8) MUST support:
1. The "job-password-supported" and "job-password-encryption-supported" Printer Description attributes as defined in section 5.3, and
2. The "job-password" and "job-password-encryption" Operation attributes as defined in section 5.4.
Printers that provide Paid Print services MUST support:
Page 75 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
145
146
1235123612371238123912401241124212431244
1245
1246
124712481249
12501251
12521253125412551256
1257
1258125912601261
1262
Working Draft – IPP Everywhere November 16, 2012
1. The "job-account-id-default", "job-account-id-supported", "job-accounting-user-id-default", "job-accounting-user-id-supported", "job-mandatory-attributes-default", "job-mandatory-attributes-supported", and "printer-mandatory-job-attributes" Printer Description attributes as defined in section 5.3,
2. The "job-mandatory-attributes" operation attribute as defined in section 5.4, and3. The "job-account-id" and "job-accounting-user-id" Job Template attributes as
defined in section 5.5.
Printers that support long-edge feed media MUST support:
1. The "feed-orientation-default" and "feed-orientation-supported" Printer Description attributes as defined in section 5.3.
2. The "media-source-properties" member attribute of the "media-col-database" and "media-col-ready" Printer Description attributes as defined in section 5.3.
3. The "feed-orientation" Job Template attribute as defined in section 5.5.
Page 76 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
147
148
1263126412651266126712681269
1270
12711272127312741275
1276
Working Draft – IPP Everywhere November 16, 2012
10. Internationalization Considerations
For interoperability and basic support for multiple languages, conforming implementations MUST support:
1. The Universal Character Set (UCS) Transformation Format -- 8 bit (UTF-8) [RFC3629] encoding of Unicode [UNICODE] [ISO10646]; and
2. The Unicode Format for Network Interchange [RFC5198] which requires transmission of well-formed UTF-8 strings and recommends transmission of normalized UTF-8 strings in Normalization Form C (NFC) [UAX15].
Unicode NFC is defined as the result of performing Canonical Decomposition (into base characters and combining marks) followed by Canonical Composition (into canonical composed characters wherever Unicode has assigned them).
WARNING – Performing normalization on UTF-8 strings received from IPP Clients and subsequently storing the results (e.g., in IPP Job objects) could cause false negatives in IPP Client searches and failed access (e.g., to IPP Printers with percent-encoded UTF-8 URIs now 'hidden').
11. Security Considerations
The IPP extensions defined in this document require the same security considerations as defined in the IPP/1.1: Model and Semantics [RFC2911]. In addition, Printers MUST validate the HTTP Host request header in order to protect against DNS rebinding attacks.
Page 77 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
149
150
1277
12781279
12801281128212831284
128512861287
1288128912901291
1292
129312941295
1296
Working Draft – IPP Everywhere November 16, 2012
12. IANA Considerations
[Editor's note - replace PWG5100.EVE and PWG5100.13 references below with final document numbers]
12.1 Attribute Value Registrations
The keyword attribute values defined in this document will be published by IANA according to the procedures in the IPP Model and Semantics [RFC2911] section 6.1 in the following file:
http://www.iana.org/assignments/ipp-registrations
The registry entries will contain the following information:
Attributes (attribute syntax) Keyword Attribute Value Reference ----------------------- ---------ipp-features-supported (1setOf type2 keyword) [PWG5100.13] ipp-everywhere [PWG5100.EVE]
13. Safe String Truncation
Strings can be truncated or omitted when transferred over alternate protocols. Printers MUST truncate long strings at logical boundaries. The following subsections describe how this truncation is performed for different kinds of strings.
13.1 Plain Text Strings
Plain text strings MUST be truncated at the end of a valid character sequence. For example, strings using the UTF-8 transformation format of ISO 10646 [STD0063][ISO10646-1] SHOULD be represented using the Unicode Format for Network Interchange [RFC5198] and MUST be truncated at the end of a valid UTF-8 sequence.
For example, the 9 octet UTF-8 sequence 0x48.65.CA.81.6C.6C.6F.C2.81 (Héllo¡) would be shortened to fit within 6 octets by composing the é (0x65.CA.81 becomes 0xC3.A9)
Page 78 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
151
152
1297
12981299
1300
130113021303
1304
1305
13061307130813091310
1311
131213131314
1315
1316131713181319
13201321
Working Draft – IPP Everywhere November 16, 2012
and removing the trailing UTF-8 sequence 0xC2.81 (¡), resulting in the 6 octet UTF-8 sequence 0x48.C3.A9.6C.6C.6F (Héllo).
13.2 URIs
URIs MUST be truncated so that the URI remains valid and accepted by the Printer. For example, the 46 octet URI "ipp://printer.example.com/ipp/really-long-name" might be shortened to fit within 32 octets by removing the last path name component, resulting in the 29 octet URI "ipp://printer.example.com/ipp". Similarly, the 52 octet URI "ipp://printer.example.com/ipp?query-string" might be shortened to fit within 32 octets by removing the query string.
As recommended by the Uniform Resource Identifier (URI): Generic Syntax [STD66], Printers SHOULD omit the port number from the URI when it has the default value, e.g., 80 for "http", 443 for "https", and 631 for "ipp" and "ipps" URIs.
13.3 MIME Media Types
MIME media type strings MUST be truncated at the end of the media subtype, removing any parameters that are included with the media type. If the resulting string still exceeds the maximum length it MUST be discarded. For example, the 24 octet MIME media type "text/plain;charset=utf-8" would be shortened to fit within 16 octets by removing the trailing parameter, resulting in the 10 octet MIME media type "text/plain".
13.4 IEEE 1284 Device ID Strings
IEEE 1284 device identifier strings contain a list of delimited key/value pairs. Device ID strings MUST be truncated at the end of a value key/value pair with the shortest form of a key used. For example, the 57 octet IEEE 1284 device ID string "MANUFACTURER:Example;MODEL:Laser Printer;COMMAND SET:PS;" would be shortened to fix within 32 octets by substituting the abbreviated key names and removing the trailing key/value pair, resulting in the 32 octet string "MFG:Example;MDL:Laser Printer;".
Page 79 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
153
154
13221323
1324
132513261327132813291330
133113321333
1334
13351336133713381339
1340
1341134213431344134513461347
Working Draft – IPP Everywhere November 16, 2012
13.5 Delimited Lists
Delimited Lists combine one or more string types listed in the previous sections, separated by a delimiting character such as a comma or semicolon. Delimited lists MUST first be shortened by removal of unnecessary path components (URIs) and parameters (MIME media types) and second truncated at a delimiting character. For example, the 40 octet list of MIME media types "text/plain;charset=utf-8,application/pdf" would be shortened to fit within 32 octets by removing the MIME media type parameter, resulting in the 26 octet list "text/plain,application/pdf". The same list would be shortened to fit within 16 octets by also removing the last MIME media type, resulting in the 10 octet list "text/plain".
14. References
14.1 Normative References
[ECMA388] "Open XML Paper Specification", June 2009, Standard ECMA-388, http://www.ecma-international.org/publications/standards/Ecma-388.htm
[EXIF] "Standard of the Camera & Imaging Products Association, CIPA DC-008-Translation-2010, Exchangeable image file format for digital still cameras: Exif Version 2.3", http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-008-2010_E.pdf
[IEEE1284] "Standard Signaling Method for a Bi-directional Parallel Peripheral Interface for Personal Computers", IEEE 1284, January 2000
[ISO10646] "Information technology -- Universal Coded Character Set (UCS)", ISO/IEC 10646:2011
[ISO29500-2] "Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 2: Open Packaging Conventions", ISO/IEC 29500-2:2012, September 2012
Page 80 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
155
156
1348
134913501351135213531354135513561357
1358
1359
136013611362
1363136413651366
13671368
13691370
137113721373
Working Draft – IPP Everywhere November 16, 2012
[ISO32000] "Document management — Portable document format — Part 1: PDF 1.7", ISO 32000-2008
[JFIF] E. Hamilton, "JPEG File Interchange Format Version 1.02", September 1992, http://www.w3.org/Graphics/JPEG/jfif3.pdf
[PWG5100.3] K. Ocke, T. Hastings, "Internet Printing Protocol (IPP): Production Printing Attributes – Set1", PWG 5100.3-2001, February 2001, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf
[PWG5100.7] T. Hastings, P. Zehler, "Standard for The Internet Printing Protocol (IPP): Job Extensions", PWG 5100.7-2003, October 2003, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippjobext10-20031031-5100.7.pdf
[PWG5100.9] I. McDonald, C. Whittle, "Internet Printing Protocol (IPP)/ Printer State Extensions v1.0", PWG 5100.9-2009, July 2009, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippstate10-20090731-5100.9.pdf
[PWG5100.11] T. Hastings, D. Fullman, "IPP: Job and Printer Operations - Set 2", PWG 5100.11-2010, October 2010, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext10-20101030-5100.11.pdf
[PWG5100.12] R. Bergman, H. Lewis, I. McDonald, M. Sweet, "IPP/2.0 Second Edition", PWG 5100.12-2011, February 2011, ftp://www.pwg.org/pub/pwg/candidates/cs-ipp20-2011MMDD-5100.12.pdf
[PWG5100.13] M. Sweet, I. McDonald, "IPP: Job and Printer Extensions - Set 3 (JPS3)", PWG 5100.13-2012, July 2012, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf
[PWG5101.2] R. Bergman, T. Hastings, "Standard for Media Standardized Names", PWG 5101.2-2002, February 2002,
Page 81 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
157
158
13741375
13761377
1378137913801381
1382138313841385
1386138713881389
1390139113921393
1394139513961397
1398139914001401
14021403
Working Draft – IPP Everywhere November 16, 2012
ftp://ftp.pwg.org/pub/pwg/candidates/cs-pwgmsn10-20020226-5101.1.pdf
[PWG5102.4] M. Sweet, "PWG Raster Format", PWG 5102.4-2012, April 2012, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippraster10-20120420-5102.4.pdf
[PWG5107.1] R. Bergman, M. Fenelon, I. McDonald, I. Pavicevic, "Printer Port Monitor MIB 1.0", PWG 5107.1-2005, October 2005, ftp://ftp.pwg.org/pub/pwg/candidates/cs-pmpportmib10-20051025-5107.1.pdf
[PWG5107.2] I. McDonald, "PWG Command Set Format for IEEE 1284 Printer ID v1.0", PWG 5107.2-2010, May 2010, ftp://ftp.pwg.org/pub/pwg/candidates/cs-pmp1284cmdset10-20100531-5107.2.pdf
[RFC2083] T. Boutell, "PNG (Portable Network Graphics) Specification Version 1.0", RFC 2083, March 1997, http://www.ietf.org/rfc/rfc2083.txt
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119/BCP 14, March 1997, http://www.ietf.org/rfc/rfc2119.txt
[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997, http://www.ietf.org/rfc/rfc2131.txt
[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997, http://www.ietf.org/rfc/rfc2136.txt
[RFC2246] T.Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt
[RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999, http://www.ietf.org/rfc/rfc2608.txt
Page 82 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
159
160
14041405
140614071408
1409141014111412
1413141414151416
14171418
141914201421
14221423
142414251426
14271428
142914301431
Working Draft – IPP Everywhere November 16, 2012
[RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, http://www.ietf.org/rfc/rfc2616.txt
[RFC2782] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000, http://www.ietf.org/rfc/rfc2782.txt
[RFC2911] T. Hastings, R. Herriot, R. deBry, S. Isaacson, P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000, http://www.ietf.org/rfc/rfc2911.txt
[RFC3282] H. Alvestrand, "Content Language Headers", RFC 3282, May 2002, http://www.ietf.org/rfc/rfc3282.txt
[RFC3382] R. deBry, R. Herriot, T. Hastings, K. Ocke, P. Zehler, "Internet Printing Protocol (IPP): The 'collection' attribute syntax", RFC 3382, September 2002, http://www.ietf.org/rfc/rfc3382.txt
[RFC3712] P. Fleming, I. McDonald, "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", RFC 3712, February 2004, http://www.ietf.org/rfc/rfc3712.txt
[RFC3805] R. Bergman, H. Lewis, I. McDonald, "Printer MIB v2", RFC 3805, June 2004, http://www.ietf.org/rfc/rfc3805.txt
[RFC3806] R. Bergman, H. Lewis, I. McDonald, "Printer Finishing MIB", RFC 3806, June 2004, http://www.ietf.org/rfc/rfc3806.txt
[RFC3927] S. Cheshire, B. Aboba, E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005, http://www.ietf.org/rfc/rfc3927.txt
[RFC3995] R. Herriot, T. Hastings, "IPP Event Notifications and Subscriptions", RFC 3995, March 2005, http://www.ietf.org/rfc/rfc3955.txt
Page 83 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
161
162
143214331434
143514361437
143814391440
14411442
144314441445
144614471448
14491450
14511452
145314541455
14561457
Working Draft – IPP Everywhere November 16, 2012
[RFC4122] P. Leach, M. Mealling, R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, http://www.ietf.org/rfc/rfc4122.txt
[RFC4346] T.Dierks, E. Rescorla, "Transport Layer Security 1.1", RFC 4346, April 2006, http://www.ietf.org/rfc/rfc4346.txt
[RFC4510] K. Zeilenga, "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006, http://www.ietf.org/rfc/rfc4510.txt
[RFC4519] A. Sciberras, "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006, http://www.ietf.org/rfc/rfc4519.txt
[RFC4647] A. Phillips, Ed., M. Davis, Ed., "Matching of Language Tags", RFC 4647, September 2006, http://www.ietf.org/rfc/rfc4647.txt
[RFC5198] J. Klensin, M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008, http://www.ietf.org/rfc/rfc5198.txt
[RFC5246] T.Dierks, E. Rescorla, "Transport Layer Security 1.2", RFC 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt
[RFC5646] A. Phillips, Ed., M. Davis, Ed., "Tags for Identifying Languages", RFC 5646, September 2009, http://www.ietf.org/rfc/rfc5646.txt
[RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010, http://www.ietf.org/rfc/rfc5870.txt
[STD63] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 3629/STD 63, November 2003, http://www.ietf.org/rfc/rfc3629.txt
[STD66] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986/STD 66, January 2005, http://www.ietf.org/rfc/rfc3986.txt
Page 84 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
163
164
145814591460
14611462
146314641465
146614671468
14691470
14711472
14731474
14751476
147714781479
14801481
148214831484
Working Draft – IPP Everywhere November 16, 2012
[UPNP1.1] "UPnP™ Device Architecture 1.1", October 2008, http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
[WGS84] National Geospatial-Intelligence Agency, "Department of Defense World Geodetic System 1984, Its Definition and Relationships With Local Geodetic Systems, Third Edition", NIMA Technical Report TR8350.2, January 2000,http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf
[WSDD-DISCOVERY-1.1]OASIS, "OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1", July 2009, http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html
[X.520] International Telecommunication Union, "Information technology - Open Systems Interconnection - The Directory: Selected attribute types", ITU-T X.520, November 2008.
[XML11] W3C, "Extensible Markup Language (XML) 1.1 (Second Edition)", August 2006, http://www.w3.org/TR/2006/REC-xml11-20060816/
14.2 Informative References
[BONJOUR] Apple Inc., "Bonjour Printing Specification Version 1.02", April 2005, http://developer.apple.com/bonjour/
[CUPSIPP] Apple Inc., "CUPS Implementation of IPP", http://www.cups.org/spec-ipp.html
[DNS-SD] S. Cheshire, M. Krocmal, "DNS-Based Service Discovery", Internet Draft, https://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/
[IPPS] I. McDonald, M. Sweet, "IPP over HTTPS Transport Binding and 'ipps' URI Scheme", Internet Draft, https://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/
Page 85 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
165
166
148514861487
14881489149014911492
14931494149514961497
149814991500
15011502
1503
15041505
15061507
15081509
151015111512
Working Draft – IPP Everywhere November 16, 2012
[LDAPSCHEMA] P. Fleming, I. McDonald, "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", Internet Draft, https://datatracker.ietf.org/doc/draft-mcdonald-ldap-printer-schema/
[mDNS] S. Cheshire, M. Krocmal, "Multicast DNS", Internet Draft, https://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/
[RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995, http://www.ietf.org/rfc/rfc1766.txt
[RFC3196] T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst, "Internet Printing Protocol/1.1: Implementer's Guide", RFC 3196, November 2001, http://www.ietf.org/rfc/rfc3196.txt
[RFC3510] R. Herriot, I. McDonald, "Internet Printing Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003, http://www.ietf.org/rfc/rfc3510.txt
Page 86 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
167
168
151315141515
15161517
15181519
152015211522
15231524
1525
Working Draft – IPP Everywhere November 16, 2012
15. Authors' Addresses
Primary authors:
Michael SweetApple Inc.10431 N. De Anza Blvd.MS 38-4LPTCupertino CA 95014
Ira McDonaldHigh NorthPO Box 221Grand Marais, MI 49839
Andrew MitchellHewlett Packard Company
Justin HutchingsMicrosoft Corporation
Send comments to the PWG IPP Mailing List:
[email protected] (subscribers only)
To subscribe, see the PWG web page:
http://www.pwg.org/
Implementers of this specification document are encourages to join the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values.
The editor would like to especially thank the following individuals who also contributed significantly to the development of this document:
Page 87 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
169
170
1526
1527
1528152915301531153215331534153515361537153815391540154115421543
1544
1545
1546
1547
154815491550
15511552
Working Draft – IPP Everywhere November 16, 2012
Jerry Thrasher - LexmarkPeter Zehler - Xerox
Page 88 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
171
172
15531554
Working Draft – IPP Everywhere November 16, 2012
16. Change History
[ PWG Secretary: This section must be removed when Document is approved ]
16.1 November 16, 2012
1. Section 4.1: Added "based on one or more specified Printer attribute values".2. Section 5.3.6: Added "For interoperability" to start of sentence.
16.2 November 4, 2012
1. Global: Dropped use of "Coloring" throughout; instead use "filtering".2. Global: Dropped "IPP Everywhere" prefix from Client and Printer3. Global: Changed "printer" to "Printer" where needed4. GP113: Section 3.4 - changed "generic drivers" to "vendor-neutral Client
software".5. GP28, GP30, GP39: Section 3.2.x - changed "user" to "Jane", "John", etc. when
we are talking about a person doing something interactive with the client user interface.
6. Section 2.2: Updated "Job" definition to match format of "Document" based on PWG F2F review
7. Section 2.3: Dropped "Discovery Protocol", updated "Discovery", "Enumeration", "Operator", and "User" definitions based on PWG F2F review
8. Section 3.1: Current XML spec is 1.1.9. Added normative references for LDAP (RFC 4510) and SLP (RFC 2608)10.Section 3.2.1.8: Expanded QRCodes11.Section 3.2.2.5: "An assistant" instead of "A resort assistant"12.Section 4: Reworded Discovery protocol requirements.13.Added normative reference to IEEE 128414.Section 5.3.6: Added reference to IEEE 1284 and a clarification that printers
must not use non-standard abbreviations of standard keywords.15.Table 6: Added job-account-id-default/-supported, job-accounting-user-id-
default/-supported, job-mandatory-attributes-default/-supported16.Table 7: Added job-mandatory-attributes
Page 89 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
173
174
1555
1556
1557
15581559
1560
15611562156315641565156615671568156915701571157215731574157515761577157815791580158115821583
Working Draft – IPP Everywhere November 16, 2012
17.Table 8: Removed job-mandatory-attributes, job-account-id, dropped job-billing-info
18.Section 8.4: Added reference to DHCP RFC 213119.Section 9.1: Added I18N and security considerations to client requirements20.Section 9.3: Updated paid print service attribute lists.21.Section 10: Added text from IPP/2.0 SE.
16.3 September 26, 2012
1. MS15: Section 6 expanded discussion of Exif to clarify we just care about JPEG bits
2. GP110: Section 2.2 changed "control" to "manage" in definition of Operator3. GP90, GP106, GP107: Added new section 2.4 for acronyms and organizations4. GP111: Section 3.2.x changed "enumeration" to "Enumeration"5. GP112: Section 4.2, changed "Service (SRV)" to "service (SRV)"6. GP115: Section 4.2.3 changed list of Key/Value pairs to a table7. GP116: Figure 1 updated "IPP Everywhere Service" to "IPPEverywhere
Service"8. GP117: Replaced "so-called" with actual text ("C0 Control Character Set").9. GP118: Section 9.3 fixed section references10.NC1: Section 6 remove IPP Everywhere from requirements, added reference to
PWG 5100.12.
16.4 September 6, 2012
1. GP1: Changed all occurrences of "MDNS" to "mDNS"2. GP3: Updated definition of "Device"3. GP4: Changed "IPP Printer" to "Printer"4. GP5: Updated definition of "Job" and added definition of "Document"5. GP6: Added historical reference to RFC 2911 for "Coloring"6. GP7: Updated definition of "Discovery Protocol"7. GP8: Updated definition of "Operator"8. JT3: Updated definition of "User"9. GP9, JT2, WW2: Changed usage of "Visible" and "Visibility" to "Network
Accessible" and "Network Accessibility"
Page 90 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
175
176
158415851586158715881589
1590
1591159215931594159515961597159815991600160116021603
1604
1605160616071608160916101611161216131614
Working Draft – IPP Everywhere November 16, 2012
10.GP10: Expanded XML and OPC acronyms11.GP11: Added informational reference to Bonjour Printing specification12.GP12: Expanded DNS and SRV acronyms13.GP13: Expanded TXT acronym14.GP14: Expanded SLP acronym15.GP15: Section 3.2.1 changed Server to Print and Imaging Device to Printer16.GP17: Section 3.2.1.1 changed "displays" to "provides".17.GP18: Expanded URI acronym18.GP19: Expanded DNS-SD acronym19.GP20, GP31: Changed all occurrences of "user" with "User"20.GP21, GP22: Changed "visible" to "network accessible"21.GP23: Section 3.2.1.7 changed proximity and nearby to printers within a
geographic area22.GP24: Section 3.2.1.8 added some of the precondition text to the initial
description23.GP25: Section 3.2.1.9 "application (print) protocol" 24.GP26: Section 3.2.2 dropped first (redundent) sentence.25.GP29: Section 3.2.2 dropped parenthesis around "or Service"26.GP33: Section 3.2.2.1 changed "local document" to "attached document data"27.GP34: Section 3.2.2.2 changed "remote document" to "document URI"28.GP35: Section 3.2.2.3 clarified the User is running a photo app, which is how it
knows it is printing a photo29.GP37: Section 3.2.2.3 added orientation to the list of information reported by the
printer30.GP38: Section 3.2.2.4 "the accounting program"31.GP40: Section 3.2.2.4 clarified that the orientation and pagination are
previewed32.GP41: Section 3.2.2.4 ready media also provides orientation, type, etc.
information33.WW6: Section 3.2.2.4 changed "document data containing the checks" to "...
check information".34.GP42: Section 3.2.2.5 changed "factotum" and "gopher" to "resort assistant"35.GP43: Section 3.2.2.5 fixed up reading of lead paragraph36.GP44: Section 3.2.2.6 - "the word processor"37.GP45: Section 3.2.2.6 - The word processor produces the document data38.GP46, WW9: Section 3.2.2.6 - Printers are associated with a Service
Page 91 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
177
178
161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650
Working Draft – IPP Everywhere November 16, 2012
39.GP47: Section 3.2.2.6 expanded PIN acronym40.GP48: Section 3.2.2.6 expanded ID acronym41.WW9: Section 3.2.2.6: Changed "follow me" to "release and print" to avoid
trademarked terminology42.GP49: Section 3.2.2.6 added precondition about printer capabilities43.GP50, WW10: Section 3.2.2.7 updated to match style of other use cases44.GP51: Section 3.2.2.9 updated to read "produce part or all of the final output"45.GP52: New Section 3.2.3.1 for print action canceled46.GP52: Section 3.2.3.2 removed canceled print action, added more information
about what the client does47.GP53: Section 3.2.3.3 changed "Printer" to "selected Printer"48.GP54: Section 3.2.3.4 added precondition about authorization info49.GP54: Section 3.2.3.5 added precondition about authentication info50.GP55: Section 3.2.3.5 changed "document" to "Job document(s)"51.GP56: Section 3.2.3.7 changed "accessing" to "accepting"52.GP60: Section 3.2.3.8 changed "resource" to "resources" (plural)53.GP61: Section 3.2.3.10 changed "displays" to "provides"54.GP62: Section 3.3, item 1 changed to read "The actual method of geo-location
and geographic area detection"55.GP64: Section 3.3, item 4 changed "locate" to "find Network Accessible"56.GP66: Section 4.1 changed "coloring" to "Coloring", "discovery" to "Discovery",
added back reference to section 2.357.GP67: Sections 4.2 and 4.2.1 changed to use "Service (SRV)" consistently58.GP69: Section 4.2.3 changed "Service Information (TXT)" to "Text (TXT)",
added "that provides service information" to the descriptive text.59.MS6: Section 4.2.3 added prioritized list of key/value pairs60.MS9: Section 4.2.3 clarified what the packet size limits are for61.GP71: Section 4.2.3.1 expanded "SSL" and "TLS" acronyms62.GP72: Section 4.2.3.2 expanded "pdl" acronym63.GP73: Section 4.2.3.2 expanded "MIME" acronym64.MS8: Section 4.2.3.3 added "qtotal" subsection65.JH9: Section 4.2.3.4: Updated to allow any IETF-defined TLS version.66.GP75: Section 4.2.3.5 now list both COMMAND SET and CMD67.GP76: Section 4.2.3.6 now list both MANUFACTURER and MFG 68.GP77: Section 4.2.3.7 now list both MODEL and MDL69.MS10: Section 4.2.3.9 made DUUID optional
Page 92 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
179
180
165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686
Working Draft – IPP Everywhere November 16, 2012
70.GP81: Section 4.4 dropped "UDP"71.GP82: Section 4.4 added "(UPnP)"72.GP83: Section 4.4 clarified that the UPnP Printer Device template is being
modified73.GP88: Section 4.4.x be consistent with naming - "IPPEverywhere service" for
the UPnP class of the same name74.GP90: Section 4.5 expanded OASIS acronym75.GP91: Section 5.3.x changed ranges from "A-B" to "A to B".76.MS1: Section 5.3.5 changed "media-size-supported" to "media-supported"77.GP92: Section 5.3.6 expanded IEEE78.GP93: Section 5.3.6 dropped MANU abbreviation79.JH11: Section 5.3.6 added "on key/value boundaries"80.MS11: Section 6.1 changed title to "Supporting Long-Edge Feed Media with
PWG Raster Format Documents"81.GP97: Section 8.1 changed to "C0 Controls" instead of "C0 block"82.GP101: Section 8.3 changed to "C0 Controls"83.GP103: Section 8.4 expanded DHCP84.MS12: Sections 9.1 and 9.2 - added bullets for sections 6.1, 8, 10, 11, and 1385.MS13: Section 10 added reference to network unicode86.JH1: Section 14.2: Added informational references to Bonjour and CUPS IPP
documentation87.MS2: Global change "might report" to "could report" or "would report"88.MS4: Global change "in width" to "wide"89.MS5: Global change "in length" to "long"90.JH12: Global change - Printers MUST support DNS-SD and WS-Discovery,
Clients MUST support DNS-SD and/or WS-Discovery
16.5 July 24, 2012
1. MS1: Section 5.3.5 (media-supported) - clarify examples for roll feed2. MS2: Section 5.3.7 (Notes for Long-Edge Feed ...) - Moved under section 63. MS3: Section 5.3.2 (media-col-ready) - Clarified difference in semantics and
behavior for manual-feed vs. by-pass-tray (or any regular tray)4. MS3: Section 5.3.3 (media-ready) - Talk briefly about manual feed vs. by-pass-
tray
Page 93 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
181
182
16871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712
1713
171417151716171717181719
Working Draft – IPP Everywhere November 16, 2012
5. MS2: Section 6 (Document Formats) - Added figures 2 to 5 showing different feed orientations
16.6 June 27, 2012
1. Status: Stable2. Added roll-fed media information in media-col-database, media-col-ready,
media-ready, media-size, and media-supported subsections.
16.7 May 30, 2012
1. Added informative references for DNS-SD and IPPS Internet Drafts2. Updated references for mDNS and LDAP Printer Schema Internet Drafts3. Section 4.2: Updated to use references4. Table 4: Removed duplicate "required"5. Section 8.2: Conformance Requirements for Printers6. Section 8.3: Dropped "objects" from title7. Section 12.2: ", e.g., ..."8. Section 6: Added reference to EXIF spec9. Section 8 Additional Semantics for Existing Value Tags: Added with sections for
name, naturalLanguage, text, and URI values10.Section 5.1.1: Added Host section11.Tables 5 and 8: Added references to Host and URI sections12.Added references for RFC 3282, 4647, and 5646
16.8 April 20, 2012
1. Status: Prototype2. Updated reference to PWG Raster (now a candidate standard)3. Updated definitions for logical and physical device to match up with ISO DPA4. Updated definition for Job to be zero-or-more documents5. Clarified out-of-scope (section 3.3)6. Section 4.1: fixed broken reference7. Table 1: Added note for DNS-SD elements that are only available via IPP,
added DUUID for device-uuid
Page 94 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
183
184
17201721
1722
172317241725
1726
1727172817291730173117321733173417351736173717381739
1740
17411742174317441745174617471748
Working Draft – IPP Everywhere November 16, 2012
8. Section 4.2: Clarified requirements for mDNS vs. dynamic DNS9. Section 4.2.3: Added subsection for DUUID (device-uuid), fixed broken
reference to Table 2 that inserted large gobs of old text10.Section 4.5 WS-Discovery: OASIS, not OASYS11.Section 5.1 HTTP Features: "the following additional HTTP headers"12.Section 5.1.1: Added reference to RFC 2616 for section references.13.Section 5.3: Added detailed conformance text for long-edge feed printers and
client support14.Section 5.6.1 job-id: Added reference to RFC 319615.Section 5.6.2 job-uri: Added references to RFC 3196 and 351016.Section 7.1: Change to ipp-features-supported17.Section 8: Split client and printer conformance requirements, added client
conformance requirement for media-source-properties and feed-orientation18.Section 11.1: Changed to ipp-features-supported19.Section 12: Changed to "Safe String Truncation", clarified intro text20.Section 12.2 URIs: Added query string and reference to STD6621.Section 12.3 MIME Media Types: discarded instead of omitted22.Section 12.5 Lists: typos23.Section 13.2: Added informative references to RFC 3196 and RFC 3510
16.9 April 8, 2012
1. Title: Dropped version number (just "IPP Everywhere")2. Section 2.2: Added Logical and Physical Device, Paid Imaging Services, fixed
references and referenced terminology3. Section 2.3: Updated definition of Visible (submit imaging job creation requests)
and added definition of Secure Print.4. Section 3.3: Added out-of-scope list.5. Section 4.2.2: Added default accuracy value.6. Section 4.2.3: Added discussion of total length limits, priority, and behaviors7. Table 2: Fixed section references8. Section 4.2.3.7: Added note for why we use printer-uuid and not device-uuid for
UUID key.9. Section 4.5: New WS-Discovery section with Justin's proposed example.10.Sections 5.3, 5.5, 8.2: Added new conditional requirement for feed-orientation
and media-source-properties with printers that support long-edge feed media.
Page 95 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
185
186
1749175017511752175317541755175617571758175917601761176217631764176517661767
1768
17691770177117721773177417751776177717781779178017811782
Working Draft – IPP Everywhere November 16, 2012
11.Section 5.6: Added new subsections for job-id and job-uri.12.Section 8.2: Converted to numbered list of requirements as needed, added
missing attributes.13.Section 12: New smart string truncation reference.14.Section 13.1: Added references for WS-Discovery and RFC 380615.Everywhere: Change "ipp-everywhere-1.0" to just "ipp-everywhere".16.All tables: Updated requirements text and added "Required" to titles
16.10 February 1, 2012
17.Updated terminology.18.Added section for WS-Discovery19.Table 1: Updated LDAP attributes, added printer-charge-info20.Updated note 3 for all tables21.Updated LDAP and SLP section to talk about length limits22.Fixed footer23.Updated all attribute tables - xxx-default and xxx-supported are now in the
Printer Description table, xxx-preferred has been removed, several Job Template attributes have been moved to the operation attributes table, and other general sync-up with JPS3
24.Added section on HTTP requirements/features25.Added section on printer-device-id ordering of key/value pairs26.Added missing references
16.11 September 27, 2011
1. Updated title to "IPP Everywhere 1.0"2. Updated terminology3. Updated references for OpenXPS and Bonjour4. Filled in use cases from common use case document5. Updated DNS SD (Bonjour) TXT record information.6. Added SSDP/UPNP information from Andrew Mitchell's May 2011 whitepaper7. Revamped transport binding section and added new content from JPS3 and
PWG Raster8. Added conformance requirements
Page 96 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
187
188
1783178417851786178717881789
1790
1791179217931794179517961797179817991800180118021803
1804
180518061807180818091810181118121813
Working Draft – IPP Everywhere November 16, 2012
9. Added security considerations10.Added IANA considerations
16.12 August 3, 2011
1. Updated document status (interim)2. Added OpenXPS and Port Monitor MIB references3. Added usb_* key definitions4. Added placeholder for UPNP5. Cleaned up discovery attribute table6. Added ipp-extensions-supported keyword definition.7. Other changes per April 2011 F2F review (see posted minutes)
16.13 March 16, 2011
Initial revision.
Page 97 of 97 Copyright © 2011-2012 The Printer Working Group. All rights reserved.
189
190
18141815
1816
1817181818191820182118221823
1824
1825