📄 rfc2639.txt
字号:
Network Working Group T. Hastings
Request for Comments: 2639 C. Manros
Category: Informational Xerox Corporation
July 1999
Internet Printing Protocol/1.0: Implementer's Guide
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document is one of a set of documents, which together describe
all aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technologies. This document contains
information that supplements the IPP Model and Semantics [RFC2566]
and the IPP Transport and Encoding [RFC2565] documents. It is
intended to help implementers understand IPP/1.0 and some of the
considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation
for some of the specification decisions is also included.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes
a broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
Hastings & Manros Informational [Page 1]
RFC 2639 IPP/1.0: Implementer's Guide July 1999
administrators. The design goals document calls out a subset of end
user requirements that are satisfied in IPP/1.0. Operator and
administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specifications, and gives background and rationale for the
IETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics",
describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also
addresses how security, internationalization, and directory issues
are addressed.
The document, "Internet Printing Protocol/1.0: Encoding and
Transport", is a formal mapping of the abstract operations and
attributes defined in the model document onto HTTP/1.1. It also
defines the encoding rules for a new Internet media type called
"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some
advice to implementers of gateways between IPP and LPD (Line Printer
Daemon) implementations.
Table of Contents
1 Introduction......................................................4
1.1 Conformance language............................................4
1.2 Other terminology...............................................5
2 Model and Semantics...............................................5
2.1 Summary of Operation Attributes.................................5
2.2 Suggested Operation Processing Steps for IPP Objects ..........10
2.2.1 Suggested Operation Processing Steps for all Operations..11
2.2.1.1 Validate version number...............................11
2.2.1.2 Validate operation identifier.........................11
2.2.1.3 Validate the request identifier.......................11
2.2.1.4 Validate attribute group and attribute presence and
order.................................................12
2.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................19
2.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................23
2.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents.....................26
2.2.2.1 Default "ipp-attribute-fidelity" if not supplied......26
Hastings & Manros Informational [Page 2]
RFC 2639 IPP/1.0: Implementer's Guide July 1999
2.2.2.2 Check that the Printer object is accepting jobs.......26
2.2.2.3 Validate the values of the Job Template attributes....26
2.2.3 Algorithm for job validation...............................27
2.2.3.1 Check for conflicting Job Template attributes values..33
2.2.3.2 Decide whether to REJECT the request..................33
2.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes..................................34
2.2.3.4 Create the Job object with attributes to support......34
2.2.3.5 Return one of the success status codes................36
2.2.3.6 Accept appended Document Content......................36
2.2.3.7 Scheduling and Starting to Process the Job............36
2.2.3.8 Completing the Job....................................37
2.2.3.9 Destroying the Job after completion...................37
2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
2.3 Status codes returned by operation ............................37
2.3.1 Printer Operations.........................................38
2.3.1.1 Print-Job.............................................38
2.3.1.2 Print-URI.............................................40
2.3.1.3 Validate-Job..........................................40
2.3.1.4 Create-Job............................................41
2.3.1.5 Get-Printer-Attributes................................41
2.3.1.6 Get-Jobs..............................................42
2.3.2 Job Operations.............................................43
2.3.2.1 Send-Document.........................................43
2.3.2.2 Send-URI..............................................44
2.3.2.3 Cancel-Job............................................44
2.3.2.4 Get-Job-Attributes....................................45
2.4 Validate-Job...................................................46
2.5 Case Sensitivity in URIs ......................................46
2.6 Character Sets, natural languages, and internationalization....46
2.6.1 Character set code conversion support .....................46
2.6.2 What charset to return when an unsupported charset is
requested?.................................................48
2.6.3 Natural Language Override (NLO) ...........................48
2.7 The "queued-job-count" Printer Description attribute...........50
2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
2.7.2 Is "queued-job-count" a good measure of how busy a printer
is?........................................................50
2.8 Sending empty attribute groups ................................50
2.9 Returning unsupported attributes in Get-Xxxx responses ........51
2.10 Returning job-state in Print-Job response ....................51
2.11 Flow controlling the data portion of a Print-Job request .....52
2.12 Multi-valued attributes ......................................53
2.13 Querying jobs with IPP that were submitted using other job
submission protocols .........................................53
2.14 The 'none' value for empty sets ..............................54
2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54
Hastings & Manros Informational [Page 3]
RFC 2639 IPP/1.0: Implementer's Guide July 1999
2.16 The "multiple-document-handling" Job Template attribute and
support of multiple document jobs.............................54
3 Encoding and Transport...........................................55
3.1 General Headers................................................56
3.2 Request Headers...............................................57
3.3 Response Headers...............................................58
3.4 Entity Headers................................................59
3.5 Optional support for HTTP/1.0..................................60
3.6 HTTP/1.1 Chunking..............................................60
3.6.1 Disabling IPP Server Response Chunking.....................60
3.6.2 Warning About the Support of Chunked Requests..............60
4 References.......................................................61
4.1 Authors' Addresses.............................................62
5 Security Considerations..........................................62
6 Notices..........................................................62
Full Copyright Statement............................................65
1 Introduction
This document contains information that supplements the IPP Model and
Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565]
documents. As such this information is not part of the formal
specifications. Instead information is presented to help implementers
understand the specification, including some of the motivation for
decisions taken by the committee in developing the specification.
Some of the implementation considerations are intended to help
implementers design their client and/or IPP object implementations.
If there are any contradictions between this document and [RFC2566] or
[RFC2565], those documents take precedence over this document.
1.1 Conformance language
Usually, this document does not contain the terminology MUST, MUST
NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
However, when those terms do appear in this document, their intent is
to repeat what the [RFC2566] and [RFC2565] documents require and
allow, rather than specifying additional conformance requirements.
These terms are defined in section 13 on conformance terminology in
[RFC2566], most of which is taken from RFC 2119 [RFC2119].
Implementers should read section 13 in [RFC2566] in order to
understand these capitalized words. The words MUST, MUST NOT, and
REQUIRED indicate what implementations are required to support in a
client or IPP object in order to be conformant to [RFC2566] and
[RFC2565]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed
as an implementer option. The verbs SHOULD and SHOULD NOT indicate
suggested behavior, but which is not required or disallowed,
respectively, in order to conform to the specification.
Hastings & Manros Informational [Page 4]
RFC 2639 IPP/1.0: Implementer's Guide July 1999
1.2 Other terminology
The term "sender" refers to the client that sends a request or an IPP
object that returns a response. The term "receiver" refers to the IPP
object that receives a request and to a client that receives a
response.
2 Model and Semantics
This section discusses various aspects of IPP/1.0 Model and Semantics
[RFC2566].
2.1 Summary of Operation Attributes
Legend for the following table:
R indicates a REQUIRED operation or attribute for an
implementation to support
O indicates an OPTIONAL operation or attribute for an
implementation to support
Hastings & Manros Informational [Page 5]
RFC 2639 IPP/1.0: Implementer's Guide July 1999
Table 1. Summary of operation attributes for Printer operations
Printer Operations
Requests Responses
Operation Print- Pri Crea Get- Get- All
Attributes Job, nt- te- Printer- Jobs Opera-
Validate URI Job Attribut tions
-Job (O) (O) es
Operation parameters--REQUIRED to be supplied by the sender
operation-id R R R R R
status-code R
request-id R R R R R R
version-number R R R R R R
Operation attributes-REQUIRED to be supplied by the sender
attributes-charset R R R R R R
attributes- R R R R R R
natural-language
document-uri R
job-id*
job-uri*
last-document
printer-uri R R R R R
Operation attributes-RECOMMENDED to be supplied by the sender
job-name R R R
requesting-user- R R R R R
name
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -