分享
 
 
 

RFC2639 - Internet Printing Protocol/1.0: Implementers Guide

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

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

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

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 RFC2119 [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.

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

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

Printer Operations

Requests Responses

Operation Print- Pri Crea Get- Get- All

Attributes Job, nt- te- Printer Jobs Opera-

Vali- URI Job Attri- tions

date-Job (O) (O) butes

Operation attributes-OPTIONAL to be supplied by the sender

status-message O

compression O O

document-format R R O

document-name O O

document-natural- O O

language

ipp-attribute- R R R

fidelity

job-impressions O O O

job-k-octets O O O

job-media-sheets O O O

limit R

message

my-jobs R

requested- R R

attributes

which-jobs R

* "job-id" is REQUIRED only if used together with

"printer-uri" to identify the target job; otherwise, "job-

uri" is REQUIRED.

Table 2. Summary of operation attributes for Job operations

Requests Responses

Operation Send- Send- Cancel Get- All

Attributes Document URI -Job Job- Opera-

(O) (O) Attri- tions

butes

Operation parameters--REQUIRED to be supplied by the sender

operation-id R R R R

status-code R

request-id R R R R R

version-number R R R R R

Operation attributes-REQUIRED to be supplied by the sender

attributes- R R R R R

charset

attributes- R R R R R

natural-language

document-uri R

job-id* R R R R

job-uri* R R R R

last-document R R

printer-uri R R R R

Operation attributes-RECOMMENDED to be supplied by the

sender

job-name

requesting-user- R R R R

name

Job Operations

Requests Responses

Operation Attributes Send- Send- Cance Get- All

Document URI l-Job Job- Opera-

(O) (O) Attri- tions

butes

Operation attributes.OPTIONAL to be supplied by the sender

status-message O

compression O O

document-format R R

document-name O O

document-natural- O O

language

ipp-attribute-

fidelity

job-impressions

job-k-octets

job-media-sheets

limit

message O

my-jobs

requested-attributes R

which-jobs

* "job-id" is REQUIRED only if used together with "printer-

uri" to identify the target job; otherwise, "job-uri" is

REQUIRED.

2.2 Suggested Operation Processing Steps for IPP Objects

This section suggests the steps and error checks that an IPP object

MAY perform when processing requests and returning responses. An IPP

object MAY perform some or all of the error checks. However, some

implementations MAY choose to be more forgiving than the error checks

shown here, in order to be able to accept requests from non-

conforming clients. Not performing all of these error checks is a

so-called "forgiving" implementation. On the other hand, clients

that successfully submit requests to IPP objects that do perform all

the error checks will be more likely to be able to interoperate with

other IPP object implementations. Thus an implementer of an IPP

object needs to decide whether to be a "forgiving" or a "strict"

implementation. Therefore, the error status codes returned may

differ between implementations. Consequentially, client SHOULD NOT

eXPect exactly the error code processing described in this section.

When an IPP object receives a request, the IPP object either accepts

or rejects the request. In order to determine whether or not to

accept or reject the request, the IPP object SHOULD execute the

following steps. The order of the steps may be rearranged and/or

combined, including making one or multiple passes over the request.

A client MUST supply requests that would pass all of the error checks

indicated here in order to be a conforming client. Therefore, a

client SHOULD supply requests that are conforming, in order to avoid

being rejected by some IPP object implementations and/or riSKINg

different semantics by different implementations of forgiving

implementations. For example, a forgiving implementation that

accepts multiple occurrences of the same attribute, rather than

rejecting the request might use the first occurrences, while another

might use the last occurrence. Thus such a non-conforming client

would get different results from the two forgiving implementations.

In the following, processing continues step by step until a "RETURNS

the xxx status code ." statement is encountered. Error returns are

indicated by the verb: "REJECTS". Since clients have difficulty

getting the status code before sending all of the document data in a

Print-Job request, clients SHOULD use the Validate-Job operation

before sending large documents to be printed, in order to validate

whether the IPP Printer will accept the job or not.

It is assumed that security authentication and authorization has

already taken place at a lower layer.

2.2.1 Suggested Operation Processing Steps for all Operations

This section is intended to apply to all operations. The next

section contains the additional steps for the Print-Job, Validate-

Job, Print-URI, Create-Job, Send-Document, and Send-URI operations

that create jobs, adds documents, and validates jobs.

2.2.1.1 Validate version number

Every request and every response contains the "version-number"

attribute. The value of this attribute is the major and minor

version number of the syntax and semantics that the client and IPP

object is using, respectively. The "version-number" attribute

remains in a fixed position across all future versions so that all

clients and IPP object that support future versions can determine

which version is being used. The IPP object checks to see if the

major version number supplied in the request is supported. If not,

the Printer object REJECTS the request and RETURNS the 'server-

error-version-not-supported' status code in the response. The IPP

object returns in the "version-number" response attribute the major

and minor version for the error response. Thus the client can learn

at least one major and minor version that the IPP object supports.

The IPP object is encouraged to return the closest version number to

the one supplied by the client.

The checking of the minor version number is implementation dependent,

however if the client supplied minor version is explicitly supported,

the IPP object MUST respond using that identical minor version

number. If the requested minor version is not supported (the

requested minor version is either higher or lower) than a supported

minor version, the IPP object SHOULD return the closest supported

minor version.

2.2.1.2 Validate operation identifier

The Printer object checks to see if the "operation-id" attribute

supplied by the client is supported as indicated in the Printer

object's "operations-supported" attribute. If not, the Printer

REJECTS the request and returns the 'server-error-operation-not-

supported' status code in the response.

2.2.1.3 Validate the request identifier

The Printer object SHOULD NOT check to see if the "request-id"

attribute supplied by the client is in range: between 1 and 2**31 - 1

(inclusive), but copies all 32 bits.

Note: The "version-number", "operation-id", and the "request-id"

parameters are in fixed octet positions in the IPP/1.0 encoding. The

"version-number" parameter will be the same fixed octet position in

all versions of the protocol. These fields are validated before

proceeding with the rest of the validation.

2.2.1.4 Validate attribute group and attribute presence and order

The order of the following validation steps depends on

implementation.

2.2.1.4.1 Validate the presence and order of attribute groups

Client requests and IPP object responses contain attribute groups

that Section 3 requires to be present and in a specified order. An

IPP object verifies that the attribute groups are present and in the

correct order in requests supplied by clients (attribute groups

without an * in the following tables).

If an IPP object receives a request with (1) required attribute

groups missing, or (2) the attributes groups are out of order, or (3)

the groups are repeated, the IPP object REJECTS the request and

RETURNS the 'client-error-bad-request' status code. For example, it

is an error for the Job Template Attributes group to occur before the

Operation Attributes group, for the Operation Attributes group to be

omitted, or for an attribute group to occur more than once, except in

the Get-Jobs response.

Since this kind of attribute group error is most likely to be an

error detected by a client developer rather than by a customer, the

IPP object NEED NOT return an indication of which attribute group was

in error in either the Unsupported Attributes group or the Status

Message. Also, the IPP object NEED NOT find all attribute group

errors before returning this error.

2.2.1.4.2 Ignore unknown attribute groups in the expected position

Future attribute groups may be added to the specification at the end

of requests just before the Document Content and at the end of

response, except for the Get-Jobs response, where it maybe there or

before the first job attributes returned. If an IPP object receives

an unknown attribute group in these positions, it ignores the entire

group, rather than returning an error, since that group may be a new

group in a later minor version of the protocol that can be ignored.

(If the new attribute group cannot be ignored without confusing the

client, the major version number would have been increased in the

protocol document and in the request). If the unknown group occurs

in a different position, the IPP object REJECTS the request and

RETURNS the 'client-error-bad-request' status code.

Clients also ignore unknown attribute groups returned in a response.

Note: By validating that requests are in the proper form, IPP

objects force clients to use the proper form which, in turn,

increases the chances that customers will be able to use such clients

from multiple vendors with IPP objects from other vendors.

2.2.1.4.3 Validate the presence of a single occurrence of required

Operation attributes

Client requests and IPP object responses contain Operation attributes

that [RFC2566] Section 3 requires to be present. Attributes within a

group may be in any order, except for the ordering of target,

charset, and natural languages attributes. These attributes MUST be

first, and MUST be supplied in the following order: charset, natural

language, and then target. An IPP object verifies that the attributes

that Section 4 requires to be supplied by the client have been

supplied in the request (attributes without an * in the following

tables). An asterisk (*) indicates groups and Operation attributes

that the client may omit in a request or an IPP object may omit in a

response.

If an IPP object receives a request with required attributes missing

or repeated from a group or in the wrong position, the behavior of

the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible

implementations are:

1.REJECTS the request and RETURNS the 'client-error-bad-request'

status code

2.accepts the request and uses the first occurrence of the

attribute no matter where it is

3.accepts the request and uses the last occurrence of the

attribute no matter where it is

4.accept the request and assume some default value for the missing

attribute

Therefore, client MUST send conforming requests, if they want to

receive the same behavior from all IPP object implementations. For

example, it is an error for the "attributes-charset" or "attributes-

natural-language" attribute to be omitted in any operation request,

or for an Operation attribute to be supplied in a Job Template group

or a Job Template attribute to be supplied in an Operation Attribute

group in a create request. It is also an error to supply the

"attributes-charset" attribute twice.

Since these kinds of attribute errors are most likely to be detected

by a client developer rather than by a customer, the IPP object NEED

NOT return an indication of which attribute was in error in either

the Unsupported Attributes group or the Status Message. Also, the

IPP object NEED NOT find all attribute errors before returning this

error.

The following tables list all the attributes for all the operations

by attribute group in each request and each response. The order of

the groups is the order that the client supplies the groups as

specified in [RFC2566] Section 3. The order of the attributes within

a group is arbitrary, except as noted for some of the special

operation attributes (charset, natural language, and target). The

tables below use the following notation:

R indicates a REQUIRED attribute that an IPP object MUST support

O indicates an OPTIONAL attribute that an IPP object NEED NOT

support

* indicates that a client MAY omit the attribute in a request

and that an IPP object MAY omit the attribute in a

response. The absence of an * means that a client MUST

supply the attribute in a request and an IPP object MUST

supply the attribute in a response.

Operation Requests

The tables below show the attributes in their proper attribute groups

for operation requests:

Note: All operation requests contain "version-number", "operation-

id", and "request-id" parameters.

Print-Job Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

printer-uri (R)

requesting-user-name (R*)

job-name (R*)

ipp-attribute-fidelity (R*)

document-name (R*)

document-format (R*)

document-natural-language (O*)

compression (O*)

job-k-octets (O*)

job-impressions (O*)

job-media-sheets (O*)

Group 2: Job Template Attributes (R*)

<Job Template attributes> (O*)

(see [RFC2566] Section 4.2)

Group 3: Document Content (R)

<document content>

Validate-Job Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

printer-uri (R)

requesting-user-name (R*)

job-name (R*)

ipp-attribute-fidelity (R*)

document-name (R*)

document-format (R*)

document-natural-language (O*)

compression (O*)

job-k-octets (O*)

job-impressions (O*)

job-media-sheets (O*)

Group 2: Job Template Attributes (R*)

<Job Template attributes> (O*)

(see [RFC2566] Section 4.2)

Create-Job Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

printer-uri (R)

requesting-user-name (R*)

job-name (R*)

ipp-attribute-fidelity (R*)

job-k-octets (O*)

job-impressions (O*)

job-media-sheets (O*)

Group 2: Job Template Attributes (R*)

<Job Template attributes> (O*) (see

(see [RFC2566] Section 4.2)

Print-URI Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

printer-uri (R)

document-uri (R)

requesting-user-name (R*)

job-name (R*)

ipp-attribute-fidelity (R*)

document-name (R*)

document-format (R*)

document-natural-language (O*)

compression (O*)

job-k-octets (O*)

job-impressions (O*)

job-media-sheets (O*)

Group 2: Job Template Attributes (R*)

<Job Template attributes> (O*) (see

(see [RFC2566] Section 4.2)

Send-Document Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

(printer-uri & job-id) job-uri (R)

last-document (R)

requesting-user-name (R*)

document-name (R*)

document-format (R*)

document-natural-language (O*)

compression (O*)

Group 2: Document Content (R*)

<document content>

Send-URI Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

(printer-uri & job-id) job-uri (R)

last-document (R)

document-uri (R)

requesting-user-name (R*)

document-name (R*)

document-format (R*)

document-natural-language (O*)

compression (O*)

Cancel-Job Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

(printer-uri & job-id) job-uri (R)

requesting-user-name (R*)

message (O*)

Get-Printer-Attributes Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

printer-uri (R)

requesting-user-name (R*)

requested-attributes (R*)

document-format (R*)

Get-Job-Attributes Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

(printer-uri & job-id) job-uri (R)

requesting-user-name (R*)

requested-attributes (R*)

Get-Jobs Request:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

printer-uri (R)

requesting-user-name (R*)

limit (R*)

requested-attributes (R*)

which-jobs (R*)

my-jobs (R*)

Operation Responses

The tables below show the response attributes in their proper

attribute groups for responses.

Note: All operation responses contain "version-number", "status-

code", and "request-id" parameters.

Print-Job Response:

Print-URI Response:

Create-Job Response:

Send-Document Response:

Send-URI Response:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

status-message (O*)

Group 2: Unsupported Attributes (R*) (see Note 3)

<unsupported attributes> (R*)

Group 3: Job Object Attributes(R*) (see Note 2)

job-uri (R)

job-id (R)

job-state (R)

job-state-reasons (O*)

job-state-message (O*)

number-of-intervening-jobs (O*)

Validate-Job Response:

Cancel-Job Response:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

status-message (O*)

Group 2: Unsupported Attributes (R*) (see Note 3)

<unsupported attributes> (R*)

Note 2 - the Job Object Attributes and Printer Object Attributes are

returned only if the IPP object returns one of the success status

codes.

Note 3 - the Unsupported Attributes Group is present only if the

client included some Operation and/or Job Template attributes or

values that the Printer doesn't support whether a success or an error

return.

Get-Printer-Attributes Response:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

status-message (O*)

Group 2: Unsupported Attributes (R*) (see Note 4)

<unsupported attributes> (R*)

Group 3: Printer Object Attributes(R*) (see Note 2)

<requested attributes> (R*)

Note 4 - the Unsupported Attributes Group is present only if the

client included some Operation attributes that the Printer doesn't

support whether a success or an error return.

Get-Job-Attributes Response:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

status-message (O*)

Group 2: Unsupported Attributes (R*) (see Note 4)

<unsupported attributes> (R*)

Group 3: Job Object Attributes(R*) (see Note 2)

<requested attributes> (R*)

Get-Jobs Response:

Group 1: Operation Attributes (R)

attributes-charset (R)

attributes-natural-language (R)

status-message (O*)

Group 2: Unsupported Attributes (R*) (see Note 4)

<unsupported attributes> (R*)

Group 3: Job Object Attributes(R*) (see Note 2, 5)

<requested attributes> (R*)

Note 5: for the Get-Jobs operation the response contains a separate

Job Object Attributes group 3 to N containing requested-attributes

for each job object in the response.

2.2.1.5 Validate the values of the REQUIRED Operation attributes

An IPP object validates the values supplied by the client of the

REQUIRED Operation attribute that the IPP object MUST support. The

next section specifies the validation of the values of the OPTIONAL

Operation attributes that IPP objects MAY support.

The IPP object performs the following syntactic validation checks of

each Operation attribute value:

a)that the length of each Operation attribute value is correct for

the attribute syntax tag supplied by the client according to

[RFC2566] Section 4.1,

b)that the attribute syntax tag is correct for that Operation

attribute according to [RFC2566] Section 3,

c)that the value is in the range specified for that Operation

attribute according to [RFC2566] Section 3,

d)that multiple values are supplied by the client only for

operation attributes that are multi-valued, i.e., that are

1setOf X according to [RFC2566] Section 3.

If any of these checks fail, the IPP object REJECTS the request and

RETURNS the 'client-error-bad-request' or the 'client-error-request-

value-too-long' status code. Since such an error is most likely to

be an error detected by a client developer, rather than by an end-

user, the IPP object NEED NOT return an indication of which attribute

had the error in either the Unsupported Attributes Group or the

Status Message. The description for each of these syntactic checks

is explicitly expressed in the first IF statement in the following

table.

In addition, the IPP object checks each Operation attribute value

against some Printer object attribute or some hard-coded value if

there is no "xxx-supported" Printer object attribute defined. If its

value is not among those supported or is not in the range supported,

then the IPP object REJECTS the request and RETURNS the error status

code indicated in the table by the second IF statement. If the value

of the Printer object's "xxx-supported" attribute is 'no-value'

(because the system administrator hasn't configured a value), the

check always fails.

attributes-charset (charset)

IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-

error-bad-request'.

IF the value length is greater than 63 octets, REJECT/RETURN '

client-error-request-value-too-long'.

IF NOT in the Printer object's "charset-supported" attribute,

REJECT/RETURN "client-error-charset-not-supported".

attributes-natural-language(naturalLanguage)

IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN

'client-error-bad-request'.

IF the value length is greater than 63 octets, REJECT/RETURN '

client-error-request-value-too-long'.

ACCEPT the request even if not a member of the set in the Printer

object's "generated-natural-language-supported" attribute. If

the supplied value is not a member of the Printer object's

"generated-natural-language-supported" attribute, use the

Printer object's "natural-language-configured" value.

requesting-user-name

IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF the IPP object can oBTain a better authenticated name, use it

instead.

job-name(name)

IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NOT supplied by the client, the Printer object creates a name

from the document-name or document-uri.

document-name (name)

IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

ipp-attribute-fidelity (boolean)

IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,

REJECT/RETURN 'client-error-bad-request'.

IF the value length is NOT equal to 1 octet, REJECT/RETURN '

client-error-request-value-too-long'

IF NOT supplied by the client, the IPP object assumes the value

'false'.

document-format (mimeMediaType)

IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN

'client-error-bad-request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NOT in the Printer object's "document-format-supported"

attribute, REJECT/RETURN 'client-error-document-format-not-

supported'

IF NOT supplied by the client, the IPP object assumes the value of

the Printer object's "document-format-default" attribute.

document-uri (uri)

IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-

error-bad-request'.

IF the value length is greater than 1023 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-

request'.

IF scheme is NOT in the Printer object's "reference-uri-schemes-

supported" attribute, REJECT/RETURN 'client-error-uri-scheme-

not-supported'.

The Printer object MAY check to see if the document exists and is

Accessible. If the document is not found or is not accessible,

REJECT/RETURN 'client-error-not found'.

last-document (boolean)

IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,

REJECT/RETURN 'client-error-bad-request'.

IF the value length is NOT equal to 1 octet, REJECT/RETURN '

client-error-request-value-too-long'

job-id (integer(1:MAX))

IF NOT an single 'integer' value equal to 4 octets AND in the

range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.

IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-

error-not-found' or 'client-error-gone' status code, if keep

track of recently deleted jobs.

requested-attributes (1setOf keyword)

IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error-

bad-request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

Ignore unsupported values which are the keyword names of

unsupported attributes. Don't bother to copy such requested

(unsupported) attributes to the Unsupported Attribute response

group since the response will not return them.

which-jobs (type2 keyword)

IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NEITHER 'completed' NOR 'not-completed', copy the attribute and

the unsupported value to the Unsupported Attributes response

group and REJECT/RETURN 'client-error-attributes-or-values-

not-supported'.

Note: a Printer still supports the 'completed' value even if it

keeps no completed/canceled/aborted jobs: by returning no jobs

when so queried.

IF NOT supplied by the client, the IPP object assumes the 'not-

completed' value.

my-jobs (boolean)

IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,

REJECT/RETURN 'client-error-bad-request'.

IF the value length is NOT equal to 1 octet, REJECT/RETURN '

client-error-request-value-too-long'

IF NOT supplied by the client, the IPP object assumes the 'false'

value.

limit (integer(1:MAX))

IF NOT a single 'integer' value equal to 4 octets AND in the range

1 to MAX, REJECT/RETURN 'client-error-bad-request'.

IF NOT supplied by the client, the IPP object returns all jobs, no

matter how many.

2.2.1.6 Validate the values of the OPTIONAL Operation attributes

OPTIONAL Operation attributes are those that an IPP object MAY or MAY

NOT support. An IPP object validates the values of the OPTIONAL

attributes supplied by the client. The IPP object performs the same

syntactic validation checks for each OPTIONAL attribute value as in

Section 2.2.1.5. As in Section 2.2.1.5, if any fail, the IPP object

REJECTS the request and RETURNS the 'client-error-bad-request' or the

'client-error-request-value-too-long' status code.

In addition, the IPP object checks each Operation attribute value

against some Printer attribute or some hard-coded value if there is

no "xxx-supported" Printer attribute defined. If its value is not

among those supported or is not in the range supported, then the IPP

object REJECTS the request and RETURNS the error status code

indicated in the table. If the value of the Printer object's "xxx-

supported" attribute is 'no-value' (because the system administrator

hasn't configured a value), the check always fails.

If the IPP object doesn't recognize/support an attribute, the IPP

object treats the attribute as an unknown or unsupported attribute

(see the last row in the table below).

document-natural-language (naturalLanguage)

IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN '

client-error-bad-request'.

IF the value length is greater than 63 octets, REJECT/RETURN '

client-error-request-value-too-long'.

IF NOT a value that the Printer object supports in document

formats, (no corresponding "xxx-supported" Printer attribute),

REJECT/RETURN 'client-error-natural-language-not-supported'.

compression (type3 keyword)

IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 255 octets, REJECT/RETURN '

client-error-request-value-too-long'.

IF NOT in the Printer object's "compression-supported" attribute,

copy the attribute and the unsupported value to the Unsupported

Attributes response group and REJECT/RETURN 'client-error-

attributes-or-values-not-supported'.

job-k-octets (integer(0:MAX))

IF NOT a single 'integer' value equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in the range of the Printer object's "job-k-octets-

supported" attribute, copy the attribute and the unsupported

value to the Unsupported Attributes response group and

REJECT/RETURN 'client-error-attributes-or-values-not-

supported'.

job-impressions (integer(0:MAX))

IF NOT a single 'integer' value equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in the range of the Printer object's "job-impressions-

supported" attribute, copy the attribute and the unsupported

value to the Unsupported Attributes response group and

REJECT/RETURN 'client-error-attributes-or-values-not-

supported'.

job-media-sheets (integer(0:MAX))

IF NOT a single 'integer' value equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in the range of the Printer object's "job-media-sheets-

supported" attribute, copy the attribute and the unsupported

value to the Unsupported Attributes response group and

REJECT/RETURN 'client-error-attributes-or-values-not-

supported'.

message (text(127))

IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 127 octets,

REJECT/RETURN 'client-error-request-value-too-long'.

unknown or unsupported attribute

IF the attribute syntax supplied by the client is supported but

the length is not legal for that attribute syntax,

REJECT/RETURN 'client-error-request-value-too-long'.

ELSE copy the attribute and value to the Unsupported Attributes

response group and change the attribute value to the "out-of-

band" 'unsupported' value, but otherwise ignore the attribute.

Note: Future Operation attributes may be added to the protocol

specification that may occur anywhere in the specified group.

When the operation is otherwise successful, the IPP object returns

the 'successful-ok-ignored-or-substituted-attributes' status code.

Ignoring unsupported Operation attributes in all operations is

analogous to the handling of unsupported Job Template attributes

in the create and Validate-Job operations when the client supplies

the "ipp-attribute-fidelity" Operation attribute with the 'false'

value. This last rule is so that we can add OPTIONAL Operation

attributes to future versions of IPP so that older clients can

inter-work with new IPP objects and newer clients can inter-work

with older IPP objects. (If the new attribute cannot be ignored

without performing unexpectedly, the major version number would

have been increased in the protocol document and in the request).

This rule for Operation attributes is independent of the value of

the "ipp-attribute-fidelity" attribute. For example, if an IPP

object doesn't support the OPTIONAL "job-k-octets" attribute', the

IPP object treats "job-k-octets" as an unknown attribute and only

checks the length for the 'integer' attribute syntax supplied by

the client. If it is not four octets, the IPP object REJECTS the

request and RETURNS the 'client-error-bad-request' status code,

else the IPP object copies the attribute to the Unsupported

Attribute response group, setting the value to the "out-of-band" '

unsupported' value, but otherwise ignores the attribute.

2.2.2 Suggested Additional Processing Steps for Operations that

Create/Validate Jobs and Add Documents

This section in combination with the previous section recommends the

processing steps for the Print-Job, Validate-Job, Print-URI, Create-

Job, Send-Document, and Send-URI operations that IPP objects SHOULD

use. These are the operations that create jobs, validate a Print-Job

request, and add documents to a job.

2.2.2.1 Default "ipp-attribute-fidelity" if not supplied

The Printer object checks to see if the client supplied an "ipp-

attribute-fidelity" Operation attribute. If the attribute is not

supplied by the client, the IPP object assumes that the value is

'false'.

2.2.2.2 Check that the Printer object is accepting jobs

If the value of the Printer object's "printer-is-accepting-jobs" is

'false', the Printer object REJECTS the request and RETURNS the

'server-error-not-accepting-jobs' status code.

2.2.2.3 Validate the values of the Job Template attributes

An IPP object validates the values of all Job Template attribute

supplied by the client. The IPP object performs the analogous

syntactic validation checks of each Job Template attribute value that

it performs for Operation attributes (see Section 2.2.1.5.):

a)that the length of each value is correct for the attribute

syntax tag supplied by the client according to [RFC2566] Section

4.1.

b)that the attribute syntax tag is correct for that attribute

according to [RFC2566] Sections 4.2 to 4.4.

c)that multiple values are supplied only for multi-valued

attributes, i.e., that are 1setOf X according to [RFC2566]

Sections 4.2 to 4.4.

As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP

object REJECTS the request and RETURNS the 'client-error-bad-request'

or 'client-error-request-value-too-long' status code as appropriate,

independent of the value of the "ipp-attribute-fidelity". Since such

an error is most likely to be an error detected by a client

developer, rather than by an end-user, the IPP object NEED NOT return

an indication of which attribute had the error in either the

Unsupported Attributes Group or the Status Message. The description

for each of these syntactic checks is explicitly expressed in the

first IF statement in the following table.

Each Job Template attribute MUST occur no more than once. If an IPP

Printer receives a create request with multiple occurrences of a Job

Template attribute, it MAY:

1.reject the operation and return the 'client-error-bad syntax'

error status code

2.accept the operation and use the first occurrence of the

attribute

3.accept the operation and use the last occurrence of the

attribute

depending on implementation. Therefore, clients MUST NOT supply

multiple occurrences of the same Job Template attribute in the Job

Attributes group in the request.

2.2.3 Algorithm for job validation

The process of validating a Job-Template attribute "xxx" against a

Printer attribute "xxx-supported" can use the following validation

algorithm (see section 3.2.1.2 in [RFC2566]).

To validate the value U of Job-Template attribute "xxx" against the

value V of Printer "xxx-supported", perform the following algorithm:

1.If U is multi-valued, validate each value X of U by performing

the algorithm in Table 3 with each value X. Each validation is

separate from the standpoint of returning unsupported values.

Example: If U is "finishings" that the client supplies with

'staple', 'bind' values, then X takes on the successive values:

'staple', then 'bind'

2.If V is multi-valued, validate X against each Z of V by

performing the algorithm in Table 3 with each value Z. If a

value Z validates, the validation for the attribute value X

succeeds. If it fails, the algorithm is applied to the next

value Z of V. If there are no more values Z of V, validation

fails.

Example: If V is "sides-supported" with values: 'one-sided',

'two-sided-long', and 'two-sided-short', then Z takes on the

successive values: 'one-sided', 'two-sided-long', and

'two-sided-short'. If the client supplies "sides" with 'two-

sided-long', the first comparison fails ('one-sided' is not

equal to 'two-sided-long'), the second comparison succeeds

('two-sided-long' is equal to 'two-sided-long"), and the third

comparison ('two-sided-short' with 'two-sided-long') is not even

performed.

3.If both U and V are single-valued, let X be U and Z be V and use

the validation rules in Table 3.

Table 3 - Rules for validating single values X against Z

attribute attribute validated if:

syntax of X syntax of Z

integer rangeOfInteger X is within the range of

Z

uri uriScheme the uri scheme in X is

equal to Z

any boolean the value of Z is TRUE

any any X and Z are of the same

type and are equal.

If the value of the Printer object's "xxx-supported" attribute is '

no-value' (because the system administrator hasn't configured a

value), the check always fails. If the check fails, the IPP object

copies the attribute to the Unsupported Attributes response group

with its unsupported value. If the attribute contains more than one

value, each value is checked and each unsupported value is separately

copied, while supported values are not copied. If an IPP object

doesn't recognize/support a Job Template attribute, i.e., there is no

corresponding Printer object "xxx-supported" attribute, the IPP

object treats the attribute as an unknown or unsupported attribute

(see the last row in the table below).

If some Job Template attributes are supported for some document

formats and not for others or the values are different for different

document formats, the IPP object SHOULD take that into account in

this validation using the value of the "document-format" supplied by

the client (or defaulted to the value of the Printer's "document-

format-default" attribute, if not supplied by the client). For

example, if "number-up" is supported for the 'text/plain' document

format, but not for the 'application/postscript' document format, the

check SHOULD (though it NEED NOT) depend on the value of the

"document-format" operation attribute. See "document-format" in

[RFC2566] section 3.2.1.1 and 3.2.5.1.

Note: whether the request is accepted or rejected is determined by

the value of the "ipp-attribute-fidelity" attribute in a subsequent

step, so that all Job Template attribute supplied are examined and

all unsupported attributes and/or values are copied to the

Unsupported Attributes response group.

job-priority (integer(1:100))

IF NOT a single 'integer' value with a length equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT supplied by the client, use the value of the Printer

object's "job-priority-default" attribute at job submission

time.

IF NOT in the range 1 to 100, inclusive, copy the attribute and

the unsupported value to the Unsupported Attributes response

group.

Map the value to the nearest supported value in the range 1:100 as

specified by the number of discrete values indicated by the

value of the Printer's "job-priority-supported" attribute. See

the formula in [RFC2566] Section 4.2.1.

job-hold-until (type3 keyword name)

IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-

error-bad-request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NOT supplied by the client, use the value of the Printer

object's "job-hold-until" attribute at job submission time.

IF NOT in the Printer object's "job-hold-until-supported"

attribute, copy the attribute and the unsupported value to the

Unsupported Attributes response group.

job-sheets (type3 keyword name)

IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-

error-bad-request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NOT in the Printer object's "job-sheets-supported" attribute,

copy the attribute and the unsupported value to the Unsupported

Attributes response group.

multiple-document-handling (type2 keyword)

IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NOT in the Printer object's "multiple-document-handling-

supported" attribute, copy the attribute and the unsupported

value to the Unsupported Attributes response group.

copies (integer(1:MAX))

IF NOT a single 'integer' value with a length equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in range of the Printer object's "copies-supported"

attribute copy the attribute and the unsupported value to the

Unsupported

Attributes response group.

finishings (1setOf type2 enum)

IF NOT an 'enum' value(s) each with a length equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in the Printer object's "finishings-supported" attribute,

copy the attribute and the unsupported value(s), but not any

supported values, to the Unsupported Attributes response group.

page-ranges (1setOf rangeOfInteger(1:MAX))

IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8

octets, REJECT/RETURN 'client-error-bad-request'.

IF first value is greater than second value in any range, the

ranges are not in ascending order, or ranges overlap,

REJECT/RETURN 'client-error-bad-request'.

IF the value of the Printer object's "page-ranges-supported"

attribute is 'false', copy the attribute to the Unsupported

Attributes response group and set the value to the "out-of-

band" 'unsupported' value.

sides (type2 keyword)

IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-

request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NOT in the Printer object's "sides-supported" attribute, copy

the attribute and the unsupported value to the Unsupported

Attributes response group.

number-up (integer(1:MAX))

IF NOT a single 'integer' value with a length equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT a value or in the range of one of the values of the Printer

object's "number-up-supported" attribute, copy the attribute

and value to the Unsupported Attribute response group.

orientation-requested (type2 enum)

IF NOT a single 'enum' value with a length equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in the Printer object's "orientation-requested-supported"

attribute, copy the attribute and the unsupported value to the

Unsupported Attributes response group.

media (type3 keyword name)

IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-

error-bad-request'.

IF the value length is greater than 255 octets, REJECT/RETURN

'client-error-request-value-too-long'.

IF NOT in the Printer object's "media-supported" attribute, copy

the attribute and the unsupported value to the Unsupported

Attributes response group.

printer-resolution (resolution)

IF NOT a single 'resolution' value with a length equal to 9

octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in the Printer object's "printer-resolution-supported"

attribute, copy the attribute and the unsupported value to the

Unsupported Attributes response group.

print-quality (type2 enum)

IF NOT a single 'enum' value with a length equal to 4 octets,

REJECT/RETURN 'client-error-bad-request'.

IF NOT in the Printer object's "print-quality-supported"

attribute, copy the attribute and the unsupported value to the

Unsupported Attributes response group.

unknown or unsupported attribute (i.e., there is no corresponding

Printer object "xxx-supported" attribute)

IF the attribute syntax supplied by the client is supported but

the length is not legal for that attribute syntax,

REJECT/RETURN 'client-error-bad-request' if the length of the

attribute syntax is fixed or 'client-error-request-value-too-

long' if the length of the attribute syntax is variable.

ELSE copy the attribute and value to the Unsupported Attributes

response group and change the attribute value to the "out-of-

band" 'unsupported' value. Any remaining Job Template

Attributes are either unknown or unsupported Job Template

attributes and are validated algorithmically according to their

attribute syntax for proper length (see below).

If the attribute syntax is supported AND the length check

fails, the IPP object REJECTS the request and RETURNS the '

client-error-bad-request' if the length of the attribute syntax

is fixed or the 'client-error-request-value-too-long' status

code if the length of the attribute syntax is variable.

Otherwise, the IPP object copies the unsupported Job Template

attribute to the Unsupported Attributes response group and

changes the attribute value to the "out-of-band" 'unsupported'

value. The following table shows the length checks for all

attribute syntaxes. In the following table: "<=" means less

than or equal, "=" means equal to:

Name Octet length check for read-write attributes

----------- --------------------------------------------

'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63

'textWithoutLanguage' <= 1023

'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63

'nameWithoutLanguage' <= 255

'keyword' <= 255

'enum' = 4

'uri' <= 1023

'uriScheme' <= 63

'charset' <= 63

'naturalLanguage' <= 63

'mimeMediaType' <= 255

'octetString' <= 1023

'boolean' = 1

'integer' = 4

'rangeOfInteger' = 8

'dateTime' = 11

'resolution' = 9

'1setOf X'

2.2.3.1 Check for conflicting Job Template attributes values

Once all the Operation and Job Template attributes have been checked

individually, the Printer object SHOULD check for any conflicting

values among all the supported values supplied by the client. For

example, a Printer object might be able to staple and to print on

transparencies, however due to physical stapling constraints, the

Printer object might not be able to staple transparencies. The IPP

object copies the supported attributes and their conflicting

attribute values to the Unsupported Attributes response group. The

Printer object only copies over those attributes that the Printer

object either ignores or substitutes in order to resolve the

conflict, and it returns the original values which were supplied by

the client. For example suppose the client supplies "finishings"

equals 'staple' and "media" equals 'transparency', but the Printer

object does not support stapling transparencies. If the Printer

chooses to ignore the stapling request in order to resolve the

conflict, the Printer objects returns "finishings" equal to 'staple'

in the Unsupported Attributes response group. If any attributes are

multi-valued, only the conflicting values of the attributes are

copied.

Note: The decisions made to resolve the conflict (if there is a

choice) is implementation dependent.

2.2.3.2 Decide whether to REJECT the request

If there were any unsupported Job Template attributes or

unsupported/conflicting Job Template attribute values and the client

supplied the "ipp-attribute-fidelity" attribute with the 'true'

value, the Printer object REJECTS the request and return the status

code:

(1) 'client-error-conflicting-attributes' status code, if there

were any conflicts between attributes supplied by the client.

(2) 'client-error-attributes-or-values-not-supported' status code,

otherwise.

Note: Unsupported Operation attributes or values that are returned

do not affect the status returned in this step. If the unsupported

Operation attribute was a serious error, the above already rejected

the request in a previous step. If control gets to this step with

unsupported Operation attributes being returned, they are not serious

errors.

2.2.3.3 For the Validate-Job operation, RETURN one of the success

status codes

If the requested operation is the Validate-Job operation, the Printer

object returns:

(1) the "successful-ok" status code, if there are no unsupported

or conflicting Job Template attributes or values.

(2) the "successful-ok-conflicting-attributes, if there are any

conflicting Job Template attribute or values.

(3) the "successful-ok-ignored-or-substituted-attributes, if there

are only unsupported Job Template attributes or values.

Note: Unsupported Operation attributes or values that are returned

do not affect the status returned in this step. If the unsupported

Operation attribute was a serious error, the above already rejected

the request in a previous step. If control gets to this step with

unsupported Operation attributes being returned, they are not serious

errors.

2.2.3.4 Create the Job object with attributes to support

If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied

by the client), the Printer object:

(1) creates a Job object, assigns a unique value to the job's

"job-uri" and "job-id" attributes, and initializes all of the

job's other supported Job Description attributes.

(2) removes all unsupported attributes from the Job object.

(3) for each unsupported value, removes either the unsupported

value or substitutes the unsupported attribute value with some

supported value. If an attribute has no values after removing

unsupported values from it, the attribute is removed from the

Job object (so that the normal default behavior at job

processing time will take place for that attribute).

(4) for each conflicting value, removes either the conflicting

value or substitutes the conflicting attribute value with some

other supported value. If an attribute has no values after

removing conflicting values from it, the attribute is removed

from the Job object (so that the normal default behavior at

job processing time will take place for that attribute).

If there were no attributes or values flagged as unsupported, or the

value of 'ipp-attribute-fidelity" was 'false', the Printer object is

able to accept the create request and create a new Job object. If

the "ipp-attribute-fidelity" attribute is set to 'true', the Job

Template attributes that populate the new Job object are necessarily

all the Job Template attributes supplied in the create request. If

the "ipp-attribute-fidelity" attribute is set to 'false', the Job

Template attributes that populate the new Job object are all the

client supplied Job Template attributes that are supported or that

have value substitution. Thus, some of the requested Job Template

attributes may not appear in the Job object because the Printer

object did not support those attributes. The attributes that

populate the Job object are persistently stored with the Job object

for that Job. A Get-Job-Attributes operation on that Job object will

return only those attributes that are persistently stored with the

Job object.

Note: All Job Template attributes that are persistently stored with

the Job object are intended to be "override values"; that is, they

that take precedence over whatever other embedded instructions might

be in the document data itself. However, it is not possible for all

Printer objects to realize the semantics of "override". End users

may query the Printer's "pdl-override-supported" attribute to

determine if the Printer either attempts or does not attempt to

override document data instructions with IPP attributes.

There are some cases, where a Printer supports a Job Template

attribute and has an associated default value set for that attribute.

In the case where a client does not supply the corresponding

attribute, the Printer does not use its default values to populate

Job attributes when creating the new Job object; only Job Template

attributes actually in the create request are used to populate the

Job object. The Printer's default values are only used later at Job

processing time if no other IPP attribute or instruction embedded in

the document data is present.

Note: If the default values associated with Job Template attributes

that the client did not supply were to be used to populate the Job

object, then these values would become "override values" rather than

defaults. If the Printer supports the 'attempted' value of the

"pdl-override-supported" attribute, then these override values could

replace values specified within the document data. This is not the

intent of the default value mechanism. A default value for an

attribute is used only if the create request did not specify that

attribute (or it was ignored when allowed by "ipp-attribute-fidelity"

being 'false') and no value was provided within the content of the

document data.

If the client does not supply a value for some Job Template

attribute, and the Printer does not support that attribute, as far as

IPP is concerned, the result of processing that Job (with respect to

the missing attribute) is undefined.

2.2.3.5 Return one of the success status codes

Once the Job object has been created, the Printer object accepts the

request and returns to the client:

(1) the 'successful-ok' status code, if there are no unsupported

or conflicting Job Template attributes or values.

(2) the 'successful-ok-conflicting-attributes' status code, if

there are any conflicting Job Template attribute or values.

(3) the 'successful-ok-ignored-or-substituted-attributes' status

code, if there are only unsupported Job Template attributes or

values.

Note: Unsupported Operation attributes or values that are returned

do not affect the status returned in this step. If the unsupported

Operation attribute was a serious error, the above already rejected

the request in a previous step. If control gets to this step with

unsupported Operation attributes being returned, they are not serious

errors.

The Printer object also returns Job status attributes that indicate

the initial state of the Job ('pending', 'pending-held', '

processing', etc.), etc. See Print-Job Response, [RFC2566] section

3.2.1.2.

2.2.3.6 Accept appended Document Content

The Printer object accepts the appended Document Content data and

either starts it printing, or spools it for later processing.

2.2.3.7 Scheduling and Starting to Process the Job

The Printer object uses its own configuration and implementation

specific algorithms for scheduling the Job in the correct processing

order. Once the Printer object begins processing the Job, the

Printer changes the Job's state to 'processing'. If the Printer

object supports PDL override (the "pdl-override-supported" attribute

set to 'attempted'), the implementation does its best to see that IPP

attributes take precedence over embedded instructions in the document

data.

2.2.3.8 Completing the Job

The Printer object continues to process the Job until it can move the

Job into the 'completed' state. If an Cancel-Job operation is

received, the implementation eventually moves the Job into the '

canceled' state. If the system encounters errors during processing

that do not allow it to progress the Job into a completed state, the

implementation halts all processing, cleans up any resources, and

moves the Job into the 'aborted' state.

2.2.3.9 Destroying the Job after completion

Once the Job moves to the 'completed', 'aborted', or 'canceled'

state, it is an implementation decision as to when to destroy the Job

object and release all associated resources. Once the Job has been

destroyed, the Printer would return either the "client-error-not-

found" or "client-error-gone" status codes for operations directed at

that Job.

Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id"

value for a sufficiently long time after a job has been destroyed, so

that stale references kept by clients are less likely to access the

wrong (newer) job.

2.2.3.10 Interaction with "ipp-attribute-fidelity"

Some Printer object implementations may support "ipp-attribute-

fidelity" set to 'true' and "pdl-override-supported" set to '

attempted' and yet still not be able to realize exactly what the

client specifies in the create request. This is due to legacy

decisions and assumptions that have been made about the role of job

instructions embedded within the document data and external job

instructions that accompany the document data and how to handle

conflicts between such instructions. The inability to be 100%

precise about how a given implementation will behave is also

compounded by the fact that the two special attributes, "ipp-

attribute-fidelity" and "pdl-override-supported", apply to the whole

job rather than specific values for each attribute. For example, some

implementations may be able to override almost all Job Template

attributes except for "number-up".

2.3 Status codes returned by operation

This section lists all status codes once in the first operation

(Print-Job). Then it lists the status codes that are different or

specialized for subsequent operations under each operation.

2.3.1 Printer Operations

2.3.1.1 Print-Job

The Printer object MUST return one of the following "status-code"

values for the indicated reason. Whether all of the document data

has been accepted or not before returning the success or error

response depends on implementation. See Section 14 for a more

complete description of each status code.

For the following success status codes, the Job object has been

created and the "job-id", and "job-uri" assigned and returned in the

response:

successful-ok: no request attributes were substituted or ignored.

successful-ok-ignored-or-substituted-attributes: some supplied

(1) attributes were ignored or (2) unsupported attribute

syntaxes or values were substituted with supported values or

were ignored. Unsupported attributes, attribute syntaxes, or

values MUST be returned in the Unsupported Attributes group of

the response.

successful-ok-conflicting-attributes: some supplied attribute

values conflicted with the values of other supplied attributes

and were either substituted or ignored. Attributes or values

which conflict with other attributes and have been substituted

or ignored MUST be returned in the Unsupported Attributes group

of the response as supplied by the client.

[RFC2566] section 3.1.6 Operation Status Codes and Messages states:

If the Printer object supports the "status-message" operation

attribute, it SHOULD use the REQUIRED 'utf-8' charset to return

a status message for the following error status codes (see

section 14): 'client-error-bad-request', 'client-error-

charset-not-supported', 'server-error-internal-error', '

server-error-operation-not-supported', and 'server-error-

version-not-supported'. In this case, it MUST set the value of

the "attributes-charset" operation attribute to 'utf-8' in the

error response.

For the following error status codes, no job is created and no "job-

id" or "job-uri" is returned:

client-error-bad-request: The request syntax does not conform to

the specification.

client-error-forbidden: The request is being refused for

authorization or authentication reasons. The implementation

security policy is to not reveal whether the failure is one of

authentication or authorization.

client-error-not-authenticated: Either the request requires

authentication information to be supplied or the authentication

information is not sufficient for authorization.

client-error-not-authorized: The requester is not authorized to

perform the request on the target object.

client-error-not-possible: The request cannot be carried out

because of the state of the system. See also 'server-error-

not-accepting-jobs' status code which MUST take precedence if

the Printer object's "printer-accepting-jobs" attribute is '

false'.

client-error-timeout: not applicable.

client-error-not-found: the target object does not exist.

client-error-gone: the target object no longer exists and no

forwarding address is known.

client-error-request-entity-too-large: the size of the request

and/or print data exceeds the capacity of the IPP Printer to

process it.

client-error-request-value-too-long: the size of request variable

length attribute values, such as 'text' and 'name' attribute

syntaxes, exceed the maximum length specified in [RFC2566] for

the attribute and MUST be returned in the Unsupported

Attributes Group.

client-error-document-format-not-supported: the document format

supplied is not supported. The "document-format" attribute

with the unsupported value MUST be returned in the Unsupported

Attributes Group. This error SHOULD take precedence over any

other 'xxx-not-supported' error, except 'client-error-charset-

not-supported'.

client-error-attributes-or-values-not-supported: one or more

supplied attributes, attribute syntaxes, or values are not

supported and the client supplied the "ipp-attributes-fidelity"

operation attribute with a 'true' value. They MUST be returned

in the Unsupported Attributes Group as explained below.

client-error-uri-scheme-not-supported: not applicable.

client-error-charset-not-supported: the charset supplied in the

"attributes-charset" operation attribute is not supported. The

Printer's "configured-charset" MUST be returned in the response

as the value of the "attributes-charset" operation attribute

and used for any 'text' and 'name' attributes returned in the

error response. This error SHOULD take precedence over any

other error, unless the request syntax is so bad that the

client's supplied "attributes-charset" cannot be determined.

client-error-conflicting-attributes: one or more supplied

attribute va attribute values conflicted with each other and

the client supplied the "ipp-attributes-fidelity" operation

attribute with a 'true' value. They MUST be returned in the

Unsupported Attributes Group as explained below.

server-error-internal-error: an unexpected condition prevents the

request from being fulfilled.

server-error-operation-not-supported: not applicable (since

Print-Job is REQUIRED).

server-error-service-unavailable: the service is temporarily

overloaded.

server-error-version-not-supported: the version in the request is

not supported. The "closest" version number supported MUST be

returned in the response.

server-error-device-error: a device error occurred while

receiving or spooling the request or document data or the IPP

Printer object can only accept one job at a time.

server-error-temporary-error: a temporary error such as a buffer

full write error, a memory overflow, or a disk full condition

occurred while receiving the request and/or the document data.

server-error-not-accepting-jobs: the Printer object's "printer-

is-not-accepting-jobs" attribute is 'false'.

server-error-busy: the Printer is too busy processing jobs to

accept another job at this time.

server-error-job-canceled: the job has been canceled by an

operator or the system while the client was transmitting the

document data.

2.3.1.2 Print-URI

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to Print-URI with the following

specializations and differences. See Section 14 for a more complete

description of each status code.

server-error-uri-scheme-not-supported: the URI scheme supplied in

the "document-uri" operation attribute is not supported and is

returned in the Unsupported Attributes group.

2.3.1.3 Validate-Job

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to Validate-Job. See Section 14

for a more complete description of each status code.

2.3.1.4 Create-Job

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to Create-Job with the following

specializations and differences. See Section 14 for a more complete

description of each status code.

server-error-operation-not-supported: the Create-Job operation is

not supported.

2.3.1.5 Get-Printer-Attributes

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to the Get-Printer-Attributes

operation with the following specializations and differences. See

Section 14 for a more complete description of each status code.

For the following success status codes, the requested attributes are

returned in Group 3 in the response:

successful-ok: no request attributes were substituted or ignored

(same as Print-Job) and no requested attributes were

unsupported.

successful-ok-ignored-or-substituted-attributes: same as Print-

Job, except the "requested-attributes" operation attribute MAY,

but NEED NOT, be returned with the unsupported values.

successful-ok-conflicting-attributes: same as Print-Job.

For the error status codes, Group 3 is returned containing no

attributes or is not returned at all:

client-error-not-possible: Same as Print-Job, in addition the

Printer object is not accepting any requests.

client-error-request-entity-too-large: same as Print-job, except

that no print data is involved.

client-error-attributes-or-values-not-supported: not applicable,

since unsupported operation attributes MUST be ignored and '

successful-ok-ignored-or-substituted-attributes' returned.

client-error-conflicting-attributes: same as Print-Job, except

that "ipp-attribute-fidelity" is not involved.

server-error-operation-not-supported: not applicable (since Get-

Printer-Attributes is REQUIRED).

server-error-device-error: same as Print-Job, except that no

document data is involved.

server-error-temporary-error: same as Print-Job, except that no

document data is involved.

server-error-not-accepting-jobs: not applicable.

server-error-busy: same as Print-Job, except the IPP object is

too busy to accept even query requests.

server-error-job-canceled: not applicable.

2.3.1.6 Get-Jobs

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to the Get-Jobs operation with the

following specializations and differences. See Section 14 for a

more complete description of each status code.

For the following success status codes, the requested attributes are

returned in Group 3 in the response:

successful-ok: no request attributes were substituted or ignored

(same as Print-Job) and no requested attributes were

unsupported.

successful-ok-ignored-or-substituted-attributes: same as Print-

Job, except the "requested-attributes" operation attribute MAY,

but NEED NOT, be returned with the unsupported values.

successful-ok-conflicting-attributes: same as Print-Job.

For any error status codes, Group 3 is returned containing no

attributes or is not returned at all. The following brief error

status code descriptions contain unique information for use with

Get-Jobs operation. See section 14 for the other error status codes

that apply uniformly to all operations:

client-error-not-possible: Same as Print-Job, in addition the

Printer object is not accepting any requests.

client-error-request-entity-too-large: same as Print-job, except

that no print data is involved.

client-error-document-format-not-supported: not applicable.

client-error-attributes-or-values-not-supported: not applicable,

since unsupported operation attributes MUST be ignored and '

successful-ok-ignored-or-substituted-attributes' returned.

client-error-conflicting-attributes: same as Print-Job, except

that "ipp-attribute-fidelity" is not involved.

server-error-operation-not-supported: not applicable (since Get-

Jobs is REQUIRED).

server-error-device-error: same as Print-Job, except that no

document data is involved.

server-error-temporary-error: same as Print-Job, except that no

document data is involved.

server-error-not-accepting-jobs: not applicable.

server-error-job-canceled: not applicable.

2.3.2 Job Operations

2.3.2.1 Send-Document

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to the Get-Printer-Attributes

operation with the following specializations and differences. See

Section 14 for a more complete description of each status code.

For the following success status codes, the document has been added

to the specified Job object and the job's "number-of-documents"

attribute has been incremented:

successful-ok: no request attributes were substituted or ignored

(same as Print-Job).

successful-ok-ignored-or-substituted-attributes: same as Print-

Job.

successful-ok-conflicting-attributes: same as Print-Job.

For the error status codes, no document has been added to the Job

object and the job's "number-of-documents" attribute has not been

incremented:

client-error-not-possible: Same as Print-Job, except that the

Printer's "printer-is-accepting-jobs" attribute is not

involved, so that the client is able to finish submitting a

multi-document job after this attribute has been set to 'true'.

Another condition is that the state of the job precludes Send-

Document, i.e., the job has already been closed out by the

client. However, if the IPP Printer closed out the job due to

timeout, the 'client-error-timeout' error status SHOULD be

returned instead.

client-error-timeout: This request was sent after the Printer

closed the job, because it has not received a Send-Document or

Send-URI operation within the Printer's "multiple-operation-

time-out" period.

client-error-request-entity-too-large: same as Print-Job.

client-error-conflicting-attributes: same as Print-Job, except

that "ipp-attributes-fidelity" operation attribute is not

involved.

server-error-operation-not-supported: the Send-Document request

is not supported.

server-error-not-accepting-jobs: not applicable.

server-error-job-canceled: the job has been canceled by an

operator or the system while the client was transmitting the

data.

2.3.2.2 Send-URI

All of the Print-Job status code descriptions in Section 3.2.1.2

Print-Job Response with the specializations described for Send-

Document are applicable to Send-URI. See Section 14 for a more

complete description of each status code.

server-error-uri-scheme-not-supported: the URI scheme supplied in

the "document-uri" operation attribute is not supported and the

"document-uri" attribute MUST be returned in the Unsupported

Attributes group.

2.3.2.3 Cancel-Job

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to Cancel-Job with the following

specializations and differences. See Section 14 for a more complete

description of each status code.

For the following success status codes, the Job object is being

canceled or has been canceled:

successful-ok: no request attributes were substituted or ignored

(same as Print-Job).

successful-ok-ignored-or-substituted-attributes: same as Print-

Job.

successful-ok-conflicting-attributes: same as Print-Job.

For any of the error status codes, the Job object has not been

canceled or was previously canceled.

client-error-not-possible: The request cannot be carried out

because of the state of the Job object ('completed', '

canceled', or 'aborted') or the state of the system.

client-error-not-found: the target Printer and/or Job object does

not exist.

client-error-gone: the target Printer and/or Job object no longer

exists and no forwarding address is known.

client-error-request-entity-too-large: same as Print-Job, except

no document data is involved.

client-error-document-format-not-supported: not applicable.

client-error-attributes-or-values-not-supported: not applicable,

since unsupported operation attributes and values MUST be

ignored.

client-error-conflicting-attributes: same as Print-Job, except

that the Printer's "printer-is-accepting-jobs" attribute is not

involved.

server-error-operation-not-supported: not applicable (Cancel-Job

is REQUIRED).

server-error-device-error: same as Print-Job, except no document

data is involved.

server-error-temporary-error: same as Print-Job, except no

document data is involved.

server-error-not-accepting-jobs: not applicable.

server-error-job-canceled: not applicable.

2.3.2.4 Get-Job-Attributes

All of the Print-Job status codes described in Section 3.2.1.2

Print-Job Response are applicable to Get-Job-Attributes with the

following specializations and differences. See Section 14 for a more

complete description of each status code.

For the following success status codes, the requested attributes are

returned in Group 3 in the response:

successful-ok: no request attributes were substituted or ignored

(same as Print-Job) and no requested attributes were

unsupported.

successful-ok-ignored-or-substituted-attributes: same as Print-

Job, except the "requested-attributes" operation attribute MAY,

but NEED NOT, be returned with the unsupported values.

successful-ok-conflicting-attributes: same as Print-Job.

For the error status codes, Group 3 is returned containing no

attributes or is not returned at all.

client-error-not-possible: Same as Print-Job, in addition the

Printer object is not accepting any requests.

client-error-document-format-not-supported: not applicable.

client-error-attributes-or-values-not-supported: not applicable.

client-error-uri-scheme-not-supported: not applicable.

client-error-conflicting-attributes: not applicable

server-error-operation-not-supported: not applicable (since Get-

Job-Attributes is REQUIRED).

server-error-device-error: same as Print-Job, except no document

data is involved.

server-error-temporary-error: sane as Print-Job, except no

document data is involved.

server-error-not-accepting-jobs: not applicable. server-error-

job-canceled: not applicable.

2.4 Validate-Job

The Validate-Job operation has been designed so that its

implementation may be a part of the Print-Job operation. Therefore,

requiring Validate-Job is not a burden on implementers. Also it is

useful for client's to be able to count on its presence in all

conformance implementations, so that the client can determine before

sending a long document, whether the job will be accepted by the IPP

Printer or not.

2.5 Case Sensitivity in URIs

IPP client and server implementations must be aware of the diverse

uppercase/lowercase nature of URIs. RFC2396 defines URL schemes and

Host names as case insensitive but reminds us that the rest of the

URL may well demonstrate case sensitivity. When creating URL's for

fields where the choice is completely arbitrary, it is probably best

to select lower case. However, this cannot be guaranteed and

implementations MUST NOT rely on any fields being case-sensitive or

case-insensitive in the URL beyond the URL scheme and host name

fields.

The reason that the IPP specification does not make any restrictions

on URIs, is so that implementations of IPP may use off-the-shelf

components that conform to the standards that define URIs, such as

RFC2396 and the HTTP/1.1 specifications [RFC2068]. See these

specifications for rules of matching, comparison, and case-

sensitivity.

It is also recommended that System Administrators and implementations

avoid creating URLs for different printers that differ only in their

case. For example, don't have Printer1 and printer1 as two different

IPP Printers.

The HTTP/1.1 specification [RFC2068] contains more details on

comparing URLs.

2.6 Character Sets, natural languages, and internationalization

This section discusses character set support, natural language

support and internationalization.

2.6.1 Character set code conversion support

IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY

support additional charsets. It is RECOMMENDED that an IPP object

also support US-ASCII, since many clients support US-ASCII, and

indicate that UTF-8 and US-ASCII are supported by populating the

Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An

IPP object is required to code covert with as little loss as possible

between the charsets that it supports, as indicated in the Printer's

"charsets-supported" attribute.

How should the server handle the situation where the "attributes-

charset" of the response itself is "us-ascii", but one or more

attributes in that response is in the "utf-8" format?

Example: Consider a case where a client sends a Print-Job request

with "utf-8" as the value of "attributes-charset" and with the "job-

name" attribute supplied. Later another client submits a Get-Job-

Attribute or Get-Jobs request. This second request contains the

"attributes-charset" with value "us-ascii" and "requested-attributes"

attribute with exactly one value "job-name".

According to the RFC2566 document (section 3.1.4.2), the value of the

"attributes-charset" for the response of the second request must be

"us-ascii" since that is the charset specified in the request. The

"job-name" value, however, is in "utf-8" format. Should the request

be rejected even though both "utf-8" and "us-ascii" charsets are

supported by the server? or should the "job-name" value be converted

to "us-ascii" and return "successful-ok-conflicting-attributes"

(0x0002) as the status code?

Answer: An IPP object that supports both utf-8 (REQUIRED) and us-

ascii, the second paragraph of section 3.1.4.2 applies so that the

IPP object MUST accept the request, perform code set conversion

between these two charsets with "the highest fidelity possible" and

return 'successful-ok', rather than a warning 'successful-ok-

conflicting-attributes, or an error. The printer will do the best it

can to convert between each of the character sets that it supports--

even if that means providing a string of question marks because none

of the characters are representable in US ASCII. If it can't perform

such conversion, it MUST NOT advertise us-ascii as a value of its

"attributes-charset-supported" and MUST reject any request that

requests 'us-ascii'.

One IPP object implementation strategy is to convert all request text

and name values to a Unicode internal representation. This is 16-bit

and virtually universal. Then convert to the specified operation

attributes-charset on output.

Also it would be smarter for a client to ask for 'utf-8', rather than

'us-ascii' and throw away characters that it doesn't understand,

rather than depending on the code conversion of the IPP object.

2.6.2 What charset to return when an unsupported charset is requested?

Section 3.1.4.1 Request Operation attributes was clarified in

November 1998 as follows:

All clients and IPP objects MUST support the 'utf-8' charset

[RFC2044] and MAY support additional charsets provided that they

are registered with IANA [IANA-CS]. If the Printer object does

not support the client supplied charset value, the Printer object

MUST reject the request, set the "attributes-charset" to 'utf-8'

in the response, and return the 'client-error-charset-not-

supported' status code and any 'text' or 'name' attributes using

the 'utf-8' charset.

Since the client and IPP object MUST support UTF-8, returning any

text or name attributes in UTF-8 when the client requests a charset

that is not supported should allow the client to display the text or

name.

Since such an error is a client error, rather than a user error, the

client should check the status code first so that it can avoid

displaying any other returned 'text' and 'name' attributes that are

not in the charset requested.

Furthermore, [RFC2566] section 14.1.4.14 client-error-charset-not-

supported (0x040D) was clarified in November 1998 as follows:

For any operation, if the IPP Printer does not support the charset

supplied by the client in the "attributes-charset" operation

attribute, the Printer MUST reject the operation and return this

status and any 'text' or 'name' attributes using the 'utf-8'

charset (see Section 3.1.4.1).

2.6.3 Natural Language Override (NLO)

The 'text' and 'name' attributes each have two forms. One has an

implicit natural language, and the other has an explicit natural

language. The 'textWithoutLanguage' and 'textWithoutLanguage' are

the two 'text' forms. The 'nameWithoutLanguage" and '

nameWithLanguage are the two 'name' forms. If a receiver (IPP object

or IPP client) supports an attribute with attribute syntax 'text', it

MUST support both forms in a request and a response. A sender (IPP

client or IPP object) MAY send either form for any such attribute.

When a sender sends a WithoutLanguage form, the implicit natural

language is specified in the "attributes-natural-language" operation

attribute which all senders MUST include in every request and

response.

When a sender sends a WithLanguage form, it MAY be different from the

implicit natural language supplied by the sender or it MAY be the

same. The receiver MUST treat either form equivalently.

There is an implementation decision for senders, whether to always

send the WithLanguage forms or use the WithoutLanguage form when the

attribute's natural language is the same as the request or response.

The former approach makes the sender implementation simpler. The

latter approach is more efficient on the wire and allows inter-

working with non-conforming receivers that fail to support the

WithLanguage forms. As each approach have advantages, the choice is

completely up to the implementer of the sender.

Furthermore, when a client receives a 'text' or 'name' job attribute

that it had previously supplied, that client MUST NOT expect to see

the attribute in the same form, i.e., in the same WithoutLanguage or

WithLanguage form as the client supplied when it created the job.

The IPP object is free to transform the attribute from the

WithLanguage form to the WithoutLanguage form and vice versa, as long

as the natural language is preserved. However, in order to meet this

latter requirement, it is usually simpler for the IPP object

implementation to store the natural language explicitly with the

attribute value, i.e., to store using an internal representation that

resembles the WithLanguage form.

The IPP Printer MUST copy the natural language of a job, i.e., the

value of the "attributes-natural-language" operation attribute

supplied by the client in the create operation, to the Job object as

a Job Description attribute, so that a client is able to query it.

In returning a Get-Job-Attributes response, the IPP object MAY return

one of three natural language values in the response's "attributes-

natural-language" operation attribute: (1) that requested by the

requester, (2) the natural language of the job, or (3) the configured

natural language of the IPP Printer, if the requested language is not

supported by the IPP Printer.

This "attributes-natural-language" Job Description attribute is

useful for an IPP object implementation that prints start sheets in

the language of the user who submitted the job. This same Job

Description attribute is useful to a multi-lingual operator who has

to communicate with different job submitters in different natural

languages. This same Job Description attribute is expected to be

used in the future to generate notification messages in the natural

language of the job submitter.

Early drafts of [RFC2566] contained a job-level natural language

override (NLO) for the Get-Jobs response. A job-level (NLO) is an

(unrequested) Job Attribute which then specified the implicit natural

language for any other WithoutLanguage job attributes returned in the

response for that job. Interoperability testing of early

implementations showed that no one was implementing the job-level NLO

in Get-Job responses. So the job-level NLO was eliminated from the

Get- Jobs response. This simplification makes all requests and

responses consistent in that the implicit natural language for any

WithoutLanguage 'text' or 'name' form is always supplied in the

request's or response's "attributes-natural-language" operation

attribute.

2.7 The "queued-job-count" Printer Description attribute

2.7.1 Why is "queued-job-count" RECOMMENDED?

The reason that "queued-job-count" is RECOMMENDED, is that some

clients look at that attribute alone when summarizing the status of a

list of printers, instead of doing a Get-Jobs to determine the number

of jobs in the queue. Implementations that fail to support the

"queued-job-count" will cause that client to display 0 jobs when

there are actually queued jobs.

We would have made it a REQUIRED Printer attribute, but some

implementations had already been completed before the issue was

raised, so making it a SHOULD was a compromise.

2.7.2 Is "queued-job-count" a good measure of how busy a printer is?

The "queued-job-count" is not a good measure of how busy the printer

is when there are held jobs. A future registration could be to add a

"held-job-count" (or an "active-job-count") Printer Description

attribute if experience shows that such an attribute (combination) is

needed to quickly indicate how busy a printer really is.

2.8 Sending empty attribute groups

The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender

not send an empty attribute group in a request or a response.

However, they REQUIRE a receiver to accept an empty attribute group

as equivalent to the omission of that group. So a client SHOULD omit

the Job Template Attributes group entirely in a create operation that

is not supplying any Job Template attributes. Similarly, an IPP

object SHOULD omit an empty Unsupported Attributes group if there are

no unsupported attributes to be returned in a response.

The [RFC2565] specification REQUIRES a receiver to be able to receive

either an empty attribute group or an omitted attribute group and

treat them equivalently. The term "receiver" means an IPP object for

a request and a client for a response. The term "sender' means a

client for a request and an IPP object for a response.

There is an exception to the rule for Get-Jobs when there are no

attributes to be returned. [RFC2565] contains the following

paragraph:

The syntax allows an xxx-attributes-tag to be present when the

xxx-attribute-sequence that follows is empty. The syntax is

defined this way to allow for the response of Get-Jobs where no

attributes are returned for some job-objects. Although it is

RECOMMENDED that the sender not send an xxx-attributes-tag if

there are no attributes (except in the Get-Jobs response just

mentioned), the receiver MUST be able to decode such syntax.

2.9 Returning unsupported attributes in Get-Xxxx responses

In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes

responses, the client cannot depend on getting unsupported attributes

returned in the Unsupported Attributes group that the client

requested, but are not supported by the IPP object. However, such

unsupported requested attributes will not be returned in the Job

Attributes or Printer Attributes group (since they are unsupported).

Furthermore, the IPP object is REQUIRED to return the 'successful-

ok-ignored-or-substituted-attributes' status code, so that the client

knows that not all that was requested has been returned.

2.10 Returning job-state in Print-Job response

An IPP client submits a small job via Print-Job. By the time the IPP

printer/print server is putting together a response to the operation,

the job has finished printing and been removed as an object from the

print system. What should the job-state be in the response?

The Model suggests that the Printer return a response before it even

accepts the document content. The Job Object Attributes are returned

only if the IPP object returns one of the success status codes. Then

the job-state would always be "pending" or "pending-held".

This issue comes up for the implementation of an IPP Printer object

as a server that forwards jobs to devices that do not provide job

status back to the server. If the server is reasonably certain that

the job completed successfully, then it should return the job-state

as 'completed'. Also the server can keep the job in its "job

history" long after the job is no longer in the device. Then a user

could query the server and see that the job was in the 'completed'

state and completed as specified by the job's "time-at-completed"

time which would be the same as the server submitted the job to the

device.

An alternative is for the server to respond to the client before or

while sending the job to the device, instead of waiting until the

server has finished sending the job to the device. In this case, the

server can return the job's state as 'pending' with the 'job-

outgoing' value in the job's "job-state-reasons" attribute.

If the server doesn't know for sure whether the job completed

successfully (or at all), it could return the (out-of-band) 'unknown'

value.

On the other hand, if the server is able to query the device and/or

setup some sort of event notification that the device initiates when

the job makes state transitions, then the server can return the

current job state in the Print-Job response and in subsequent queries

because the server knows what the job state is in the device (or can

query the device).

All of these alternatives depend on implementation of the server and

the device.

2.11 Flow controlling the data portion of a Print-Job request

A paused printer (or one that is stopped due to paper out or jam or

spool space full or buffer space full, may flow control the data of a

Print-Job operation (at the TCP/IP layer), so that the client is not

able to send all the document data. Consequently, the Printer will

not return a response until the condition is changed.

The Printer should not return a Print-Job response with an error code

in any of these conditions, since either the printer will be resumed

and/or the condition will be freed either by human intervention or as

jobs print.

In writing test scripts to test IPP Printers, the script must also be

written not to expect a response, if the printer has been paused,

until the printer is resumed, in order to work with all possible

implementations.

2.12 Multi-valued attributes

What is the attribute syntax for a multi-valued attribute? Since

some attributes support values in more than one data type, such as

"media", "job-hold-until", and "job-sheets", IPP semantics associate

the attribute syntax with each value, not with the attribute as a

whole. The protocol associates the attribute syntax tag with each

value. Don't be fooled, just because the attribute syntax tag comes

before the attribute keyword. All attribute values after the first

have a zero length attribute keyword as the indication of a

subsequent value of the same attribute.

2.13 Querying jobs with IPP that were submitted using other job

submission protocols

The following clarification was added to [RFC2566] section 8.5:

8.5 Queries on jobs submitted using non-IPP protocols

If the device that an IPP Printer is representing is able to

accept jobs using other job submission protocols in addition to

IPP, it is RECOMMEND that such an implementation at least allow

such "foreign" jobs to be queried using Get-Jobs returning "job-

id" and "job-uri" as 'unknown'. Such an implementation NEED NOT

support all of the same IPP job attributes as for IPP jobs. The

IPP object returns the 'unknown' out-of-band value for any

requested attribute of a foreign job that is supported for IPP

jobs, but not for foreign jobs.

It is further RECOMMENDED, that the IPP Printer generate "job-id"

and "job-uri" values for such "foreign jobs", if possible, so that

they may be targets of other IPP operations, such as Get-Job-

Attributes and Cancel-Job. Such an implementation also needs to

deal with the problem of authentication of such foreign jobs. One

approach would be to treat all such foreign jobs as belonging to

users other than the user of the IPP client. Another approach

would be for the foreign job to belong to 'anonymous'. Only if

the IPP client has been authenticated as an operator or

administrator of the IPP Printer object, could the foreign jobs be

queried by an IPP request. Alternatively, if the security policy

is to allow users to query other users' jobs, then the foreign

jobs would also be visible to an end-user IPP client using Get-

Jobs and Get-Job-Attributes.

Thus IPP MAY be implemented as a "universal" protocol that provides

access to jobs submitted with any job submission protocol. As IPP

becomes widely implemented, providing a more universal access makes

sense.

2.14 The 'none' value for empty sets

[RFC2566] states that the 'none' value should be used as the value of

a 1SetOf when the set is empty. In most cases, sets that are

potentially empty contain keywords so the keyword 'none' is used, but

for the 3 finishings attributes, the values are enums and thus the

empty set is represented by the enum 3. Currently there are no other

attributes with 1SetOf values which can be empty and can contain

values that are not keywords. This exception requires special code

and is a potential place for bugs. It would have been better if we

had chosen an out-of-band value, either "no-value" or some new value,

such as 'none'. Since we didn't, implementations have to deal with

the different representations of 'none', depending on the attribute

syntax.

2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?

In [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute '

my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'

attribute be there to, and if it's not present what should the IPP

printer do?

[RFC2566] Section 8.3 describes the various cases of "requesting-

user-name" being present or not for any operation. If the client

does not supply a value for "requesting-user-name", the printer MUST

assume that the client is supplying some anonymous name, such as

"anonymous".

2.16 The "multiple-document-handling" Job Template attribute and support

of multiple document jobs

ISSUE: IPP/1.0 is silent on which of the four effects an

implementation would perform if it supports Create-Job, but does not

support "multiple-document-handling".

A fix to IPP/1.0 would be to require implementing all four values of

"multiple-document-handling" if Create-Job is supported at all. Or

at least 'single-document-new-sheet' and 'separate-documents-

uncollated-copies'. In any case, an implementation that supports

Create-Job SHOULD also support "multiple-document-handling". Support

for all four values is RECOMMENDED, but at least the 'single-

document-new-sheet' and 'separate-documents-uncollated-copies'

values, along with the "multiple-document-handling-default"

indicating the default behavior and "multiple-document-handling-

supported" values. If an implementation spools the data, it should

also support the 'separate-documents-collated-copies' value as well.

3 Encoding and Transport

This section discusses various aspects of IPP/1.0 Encoding and

Transport [RFC2565].

A server is not required to send a response until after it has

received the client.s entire request. Hence, a client must not

expect a response until after it has sent the entire request.

However, we recommend that the server return a response as soon as

possible if an error is detected while the client is still sending

the data, rather than waiting until all of the data is received.

Therefore, we also recommend that a client listen for an error

response that an IPP server MAY send before it receives all the data.

In this case a client, if chunking the data, can send a premature

zero-length chunk to end the request before sending all the data (and

so the client can keep the connection open for other requests, rather

than closing it). If the request is blocked for some reason, a client

MAY determine the reason by opening another connection to query the

server using Get-Printer-Attributes.

In the following sections, there are a tables of all HTTP headers

which describe their use in an IPP client or server. The following

is an explanation of each column in these tables.

- the .header. column contains the name of a header.

- the .request/client. column indicates whether a client sends the

header.

- the .request/ server. column indicates whether a server supports

the header when received.

- the .response/ server. column indicates whether a server sends

the header.

- the .response /client. column indicates whether a client

supports the header when received.

- the .values and conditions. column specifies the allowed header

values and the conditions for the header to be present in a

request/response.

The table for .request headers. does not have columns for responses,

and the table for .response headers. does not have columns for

requests.

The following is an explanation of the values in the .request/client.

and .response/ server. columns.

- must: the client or server MUST send the header,

- must-if: the client or server MUST send the header when the

condition described in the .values and conditions. column is

met,

- may: the client or server MAY send the header

- not: the client or server SHOULD NOT send the header. It is not

relevant to an IPP implementation.

The following is an explanation of the values in the

.response/client. and .request/ server. columns.

- must: the client or server MUST support the header,

- may: the client or server MAY support the header

- not: the client or server SHOULD NOT support the header. It is

not relevant to an IPP implementation.

3.1 General Headers

The following is a table for the general headers.

General- Request Response Values and Conditions

Header

Client Server Server Client

Cache- must not must not .no-cache. only

Control

Connection must-if must must- must .close. only. Both

if client and server

SHOULD keep a

connection for the

duration of a sequence

of operations. The

client and server MUST

include this header

for the last operation

in such a sequence.

Date may may must may per RFC1123 [RFC1123]

from RFC2068

[RFC2068]

Pragma must not must not .no-cache. only

Transfer- must-if must must- must .chunked. only .

Encoding if Header MUST be present

if Content-Length is

absent.

Upgrade not not not not

Via not not not not

3.2 Request Headers

The following is a table for the request headers.

Request-Header Client Server Request Values and Conditions

Accept may must .application/ipp. only. This

value is the default if the

Request-Header Client Server Request Values and Conditions

client omits it

Accept-Charset not not Charset information is within

the application/ipp entity

Accept-Encoding may must empty and per RFC2068 [RFC2068]

and IANA registry for content-

codings

Accept-Language not not language information is within

the application/ipp entity

Authorization must-if must per RFC2068. A client MUST send

this header when it receives a

401 .Unauthorized. response and

does not receive a .Proxy-

Authenticate. header.

From not not per RFC2068. Because RFC

recommends sending this header

only with the user.s approval, it

is not very useful

Host must must per RFC2068

If-Match not not

If-Modified- not not

Since

If-None-Match not not

If-Range not not

If-Unmodified- not not

Since

Max-Forwards not not

Proxy- must-if not per RFC2068. A client MUST send

Authorization this header when it receives a

401 .Unauthorized. response and a

.Proxy-Authenticate. header.

Range not not

Referer not not

User-Agent not not

3.3 Response Headers

The following is a table for the request headers.

Response- Server Client Response Values and Conditions

Header

Accept-Ranges not not

Age not not

Location must-if may per RFC2068. When URI needs

redirection.

Proxy- not must per RFC2068

Authenticate

Public may may per RFC2068

Retry-After may may per RFC2068

Server not not

Vary not not

Warning may may per RFC2068

WWW- must-if must per RFC2068. When a server needs to

Authenticate authenticate a client.

3.4 Entity Headers

The following is a table for the entity headers.

Entity-Header Request Response Values and Conditions

Client Server Server Client

Allow not not not not

Content-Base not not not not

Content- may must must must per RFC2068 and IANA

Encoding registry for content

codings.

Content- not not not not Application/ipp

Language handles language

Content- must-if must must-if must the length of the

Length message-body per RFC

2068. Header MUST be

present if Transfer-

Entity-Header Request Response Values and Conditions

Client Server Server Client

Encoding is absent.

Content- not not not not

Location

Content-MD5 may may may may per RFC2068

Content-Range not not not not

Content-Type must must must must .application/ipp.

only

ETag not not not not

Expires not not not not

Last-Modified not not not not

3.5 Optional support for HTTP/1.0

IPP implementations consist of an HTTP layer and an IPP layer. In

the following discussion, the term "client" refers to the HTTP client

layer and the term "server" refers to the HTTP server layer. The

Encoding and Transport document [RFC2565] requires that HTTP 1.1 MUST

be supported by all clients and all servers. However, a client

and/or a server implementation may choose to also support HTTP 1.0.

- This option means that a server may choose to communicate with a

(non-conforming) client that only supports HTTP 1.0. In such cases

the server should not use any HTTP 1.1 specific parameters or

features and should respond using HTTP version number 1.0.

- This option also means that a client may choose to communicate with

a (non-conforming) server that only supports HTTP 1.0. In such

cases, if the server responds with an HTTP .unsupported version

number. to an HTTP 1.1 request, the client should retry using HTTP

version number 1.0.

3.6 HTTP/1.1 Chunking

3.6.1 Disabling IPP Server Response Chunking

Clients MUST anticipate that the HTTP/1.1 server may chunk responses

and MUST accept them in responses. However, a (non-conforming) HTTP

client that is unable to accept chunked responses may attempt to

request an HTTP 1.1 server not to use chunking in its response to an

operation by using the following HTTP header:

TE: identity

This mechanism should not be used by a server to disable a client

from chunking a request, since chunking of document data is an

important feature for clients to send long documents.

3.6.2 Warning About the Support of Chunked Requests

This section describes some problems with the use of chunked requests

and HTTP/1.1 servers.

The HTTP/1.1 standard [HTTP] requires that conforming servers support

chunked requests for any method. However, in spite of this

requirement, some HTTP/1.1 implementations support chunked responses

in the GET method, but do not support chunked POST method requests.

Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or

servlets [Servlet] require that the client supply a Content-Length.

These implementations might reject a chunked POST method and return a

411 status code (Length Required), might attempt to buffer the

request and run out of room returning a 413 status code (Request

Entity Too Large), or might successfully accept the chunked request.

Because of this lack of conformance of HTTP servers to the HTTP/1.1

standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP

Printer object implementation support chunked requests and that

conforming clients accept chunked responses. Therefore, IPP object

implementers are warned to seek HTTP server implementations that

support chunked POST requests in order to conform to the IPP standard

and/or use implementation techniques that support chunked POST

requests.

4 References

[CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface

Version 1.1 (CGI/1.1)", Work in Progress.

[HTTP] Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter,

L., Leach, P. and T. Berners-Lee, "Hypertext Transfer

Protocol -- HTTP/1.1", RFC2616, June 1999.

[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,

"Mapping between LPD and IPP Protocols", RFC2569, April

1999.

[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.

Powell, "Internet Printing Protocol/1.0: Model and

Semantics", RFC2566, April 1999.

[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet

Printing Protocol/1.0: Encoding and Transport", RFC2565,

April 1999.

[RFC2568] Zilles, S., "Rationale for the Structure and Model and

Protocol for the Internet Printing Protocol", RFC2568,

April 1999.

[RFC2567] Wright, D., "Design Goals for an Internet Printing

Protocol", RFC2567, April 1999.

[RFC1123] Braden, S., "Requirements for Internet Hosts - Application

and Support", STD 3, RFC1123, October 1989.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision

3", BCP 9, RFC2026, October 1996.

[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.

Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC

2068, January 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC2119, March 1997.

[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform

Resource Identifiers (URI): Generic Syntax", RFC2396,

August 1998.

[Servlet] Servlet Specification Version 2.1

(http://Java.sun.com/products/servlet/2.1/index.Html).

[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02),

November 1996.

4.1 Authors' Addresses

Thomas N. Hastings

Xerox Corporation

701 Aviation Blvd.

El Segundo, CA 90245

EMail: hastings@cp10.es.xerox.com

Carl-Uno Manros

Xerox Corporation

701 Aviation Blvd.

El Segundo, CA 90245

EMail: manros@cp10.es.xerox.com

5 Security Considerations

Security issues are discussed in sections 2.2, 2.3.1, and 8.5.

6 Notices

The IETF 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. Information on the

IETF's procedures with respect to rights in standards-track and

standards-related documentation can be found in BCP-11 [BCP-11].

Copies of claims of rights made available for publication and any

assurances of licenses to be made available, or the result of an

attempt made to obtain a general license or permission for the use of

such proprietary rights by implementers or users of this

specification can be obtained from the IETF Secretariat.

The IETF 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 practice

this standard. Please address the information to the IETF Executive

Director.

Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it 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 and this paragraph 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 Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有