+++ /dev/null
-INTERNET-DRAFT Roger deBry
-<draft-ietf-ipp-collection-02.txt> Utah Valley State College
- T. Hastings
- Xerox Corporation
- R. Herriot
- Xerox Corporation
- K. Ocke
- Xerox Corporation
- P. Zehler
- Xerox Corporation
- March 9, 2000
-
- Internet Printing Protocol (IPP):
- The 'collection' attribute syntax
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-Status of this Memo:
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
- Abstract
-
- This document specifies an OPTIONAL attribute syntax called
- 'collection' for use with the Internet Printing Protocol/1.0
- (IPP) [RFC2565, RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and
- subsequent versions. A 'collection' is a container holding one or
- more named values, which are called "member" attributes. A
- collection allows data to be grouped like a PostScript dictionary
- or a Java Map.
-
- There are 4 issues in the document.
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 1]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting over HTTP a message
-body whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 2]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- Table of Contents
-
-1 Problem Statement.................................................4
-2 Solution..........................................................4
-3 Definition of a Collection Attribute..............................5
- 3.1 Member Attribute Naming Rules..................................5
- 3.2 Remaining rules for a collection attribute definition..........6
- 3.3 Nested Collections.............................................8
- 3.4 Collection Attributes as Operation Attributes..................9
- 3.5 Collections as Job Template Attributes.........................9
- 3.6 Collections and Get-Printer-Attributes and Get-Job-Attributes
- operations.........................................................10
-4 New Out-of-band value............................................11
- 4.1 'none'........................................................11
-5 Unsupported Values...............................................12
-6 Sample specification.............................................12
-7 Encoding.........................................................13
- 7.1 encoding of a collection (using solution 1a)..................17
- 7.2 Sample Encoding (using solution 1a)...........................19
- 7.3 1setOf Collection encoding (using solution 1a)................20
- 7.4 Sample 1setOf Collection encoding (using solution 1a).........21
-8 Legacy issues....................................................23
-9 IANA Considerations..............................................24
-10 Internationalization Considerations..............................24
-11 Security Considerations..........................................24
-12 References.......................................................24
-13 Author's Addresses...............................................25
-14 Appendix A: Full Copyright Statement.............................26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 3]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-
-
-1 Problem Statement
-
-
-The IPP Model and Semantics [ipp-mod] supports most of the common data
-structures that are available in programming languages. It lacks a
-mechanism for grouping several attributes of different types. The Java
-language uses the Map to solve this problem and PostScript has a
-dictionary. The new mechanism for grouping attributes together must
-allow for optional members and subsequent extension of the collection.
-
-
-The mechanism must be encoded in a manner consistent with existing 1.0
-and 1.1 parsing rules (see [ipp-pro]). Current 1.0 and 1.1 parsers that
-don't support collections should not confuse collections they receive
-with attributes that they do support.
-
-
-2 Solution
-
-
-The new mechanism is a new IPP attribute syntax called a 'collection'.
-As such each collection value is a value of an attribute whose attribute
-syntax type is defined to be a 'collection'. Such an attribute is
-called a collection attribute. The name of the collection attribute
-serves to identify the collection value in an operation request or
-response, as with any attribute value.
-
-The 'collection' attribute syntax is a container holding one or more
-named values (i.e., attributes), which are called member attributes.
-Each collection attribute definition document lists the mandatory and
-optional member attributes of each collection value. A collection value
-is similar to an IPP attribute group in a request or a response, such as
-the operation attributes group. They both consist of a set of
-attributes.
-
-As with any attribute syntax, the collection attribute definition
-document specifies whether the attribute is single-value (collection) or
-multi-valued (1setOf collection).
-
-The name of each member attribute MUST be unique, but MAY be the same as
-the name of a member attribute in another collection type and/or MAY be
-the same as the name of an attribute that is not a member of a
-collection.. The rules for naming member attributes are given in
-section 3.1.
-
-Each member attribute can have any attribute syntax type, including
-'collection', and can be either single-valued or multi-valued. The
-length of a collection value is not limited. However, the length of each
-member attribute MUST NOT exceed the limit of its attribute syntax.
-
-The member attributes in a collection MAY be in any order in a request
-or response. When a client sends a collection attribute to the Printer,
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 4]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-the order that the Printer stores the member attributes of the
-collection value and the order returned in a response MAY be different
-from the order sent by the client.
-
-A collection value MUST NOT contains two or more member attributes with
-the same attribute name. Such a collection is mal-formed. Clients MUST
-NOT submit such malformed requests and Printers MUST NOT return such
-malformed responses. If such a malformed request is submitted to a
-Printer, the Printer MUST reject the request with the 'client-error-bad-
-request' status code (see section 13.1.4.1)
-
-ISSUE 01: In attribute groups [ipp-mod] allows a Printer either (1) to
-reject a request with duplicate named attributes OR (2) to choose
-exactly one of the attributes as the one to be used. Should we REQUIRE
-the Printer to reject duplicate named attributes in a collection value
-as stated above or allow the Printer to choose one member attribute as a
-second alternative as we do with attribute groups?
-
-
-3 Definition of a Collection Attribute
-
-
-This section describes the requirements for any collection attribute
-definition.
-
-
-3.1 Member Attribute Naming Rules
-
-Each collection attribute MUST have a unique name within the scope in
-which the collection attribute occurs. If the collection attribute
-occurs as a member of a request or response attribute group, it MUST be
-unique within that group, same as for any other attribute. If a
-collection attribute occurs as a member attribute of another collection,
-the collection attribute MUST have a unique name within that collection
-value, same as for any other attribute.
-
-Each member attribute in a collection value MUST have unique name within
-that collection value. Member attribute names MAY be reused between
-different collection attributes. An example is the "media" attribute
-which MAY be used as a job template attribute (see [ipp-mod]) and in a
-collection. All attribute names that are reused MUST have an identical
-syntax. All attribute names that are reused MUST have a similar
-semantics. The semantic difference MUST be limited to boundary
-conditions and constraints placed on the reused attributes. All
-attributes that are not reused from elsewhere in the IPP model MUST have
-a globally unique name.
-
-Assume that it is desirable to extend IPP by adding a Job Template
-attribute that allows the client to select the media by its properties,
-e.g., weight, color, size, etc., instead of by name as the "media (type3
-keyword | name) Job Template attribute in IPP/1.1 (see [ipp-mod]). The
-first rule is that the existing attribute MUST NOT be extended by adding
-the 'collection' attribute syntax to the existing "media" attribute.
-That would cause too many interoperability problems and complicates the
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 5]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-validation and defaulting rules as well. Instead, a new attribute will
-be defined with a suffix of "-col" (for collection), e.g., "media-col"
-(collection).
-
-For a second example, suppose it is desirable to extend IPP by allowing
-the client to select the media for the job start sheet. Again, this
-would not be done by adding the 'collection' attribute syntax to the
-existing "job-sheets" (type2 keyword | name) Job Template attribute.
-Instead, a new "job-sheet-col" (collection) Job Template attribute MUST
-be introduced. The member of the "job-sheet-col" collection might be:
-
- "job-sheet-format" (type3 keyword | name)
- "media" (type3 keyword | name)
-
-if any of the "media-supported" (1setOf (type3 keyword | name)) Printer
-attribute values could be specified for job sheets. The reason that the
-"job-sheet-format" member attribute isn't named simply, "job-sheet", is
-because its values only indicate the format, and don't imply any media,
-while the "job-sheets" (type2 keyword | name) Job Template attribute do
-imply a media. This example illustrates when a member attribute can be
-the same as another attribute (in this case a Job Template attribute)
-and when the member attribute MUST have a different name.
-
-If the definers of the "job-sheet-col" (collection) attribute intended
-that the System Administrator be allowed to have a different set of
-media values for job sheets than documents, then the definition document
-for the "job-sheet-col" collection attribute would have the following
-member attributes instead:
-
- "job-sheet-format" (type3 keyword | name)
- "job-sheet-media" (type3 keyword | name)
-
-Then the supported values would be include in a separate "job-sheet-
-media-supported" (1setOf (type3 keyword | name)) Printer attribute.
-
-
-3.2 Remaining rules for a collection attribute definition
-
-When a specification document defines an "xxx" collection attribute,
-i.e., an attribute whose attribute syntax type is 'collection' or
-'1setOf collection'; the definition document MUST include the following
-aspects of the attribute semantics. Suppose the "xxx" collection
-attribute contains an "aaa" member attribute. A simplified example of a
-collection specification is given in section 6
-
- 1. The name of the collection attribute MUST be specified. (e.g.
- "xxx")
-
- 2. The collection attribute syntax MUST be of type 'collection' or
- '1setOf collection'.
-
- 3. The context of the collection attribute MUST be specified, i.e.,
- whether the attribute is an operation attribute, a Job Template
- attribute, a Job Description attribute, a Printer Description
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 6]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- attribute, a member attribute of a particular collection attribute,
- etc.
-
- 4. The member attributes MUST be defined. For each member attribute
- the definition document MUST provide the following:
-
- a)The member attribute's name, "aaa", MUST either (1) reuse the
- attribute name of another attribute if the member attribute
- shares the syntax and semantics with the other attribute or (2)
- be unique across the entire IPP attribute name space
-
- b)Whether the member attribute is REQUIRED or OPTIONAL for the
- Printer to support
-
- c)Whether the member attribute is REQUIRED or OPTIONAL for the
- client to supply in a request
-
- d)The member attribute's syntax type, which can be any attribute
- syntax, including '1setOf X', 'collection', and '1setOf
- collection'. If this attribute name is the same as another
- attribute (case of option a-1 above), it MUST have the same
- attribute syntax, including cardinality (1setOf or not).
-
- e)The semantics of the "aaa" member attribute. The semantic
- definition MUST include a description of any constraint or
- boundary conditions the member attribute places on the
- associated attribute, especially if the attribute is the same as
- another attribute used in a different context (case of option a-
- 1 above)
-
- f)the supported values for the "aaa" member attribute, either
- enumerated explicitly or specified by the values of a referenced
- attribute which may be specified by either:
-
- @ the attribute's definition
-
- @ a Printer attribute, such as "aaa-supported", which
- contains the explicit values supported. The "aaa-supported"
- attribute is a Printer attribute and not in a collection.
- For example, if a collection contains the "media" attribute
- and its supported values are specified by the "media-
- supported" attribute, the "media-supported" attribute is
- the same Printer attribute that the "media" attribute uses.
-
- g)the default value of "aaa" member attribute if it is OPTIONAL
- for a client to supply the "aaa" member attribute in a request.
- The default value is specified by either:
-
- @ the attribute's definition
-
- @ a Printer attribute, such as "aaa-default", which may have
- a collection value
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 7]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- @ or an implementation defined algorithm that takes into
- account the values of the other member attributes of the
- collection value
-
- h)Depending on the collection attributes context, it MUST follow
- the additional rules specified below for the various contexts.
-
-
-3.3 Nested Collections
-
-A member attribute may have a syntax type of 'collection' or '1setOf
-collection'. The following example assumes a "yyy" collection attribute
-is a member attribute of the preceding "xxx" collection attribute. The
-"yyy" collection attribute contains "bbb" member attribute. The
-definition document for the nested collection MUST include:
-
-1.The name of the collection attribute, e.g., "yyy"
-
-2.The collection attribute syntax MUST be of type 'collection' or
- '1setOf collection'
-
-3.The member attributes MUST be defined. For each member attribute the
- definition document MUST provide the following:
-
- a) The member attribute's name, "bbb", MUST either (1) reuse the
- attribute name of another attribute if the member attribute shares
- the syntax and semantics with the other attribute or (2) be unique
- across the entire IPP attribute name space
-
- b) Whether the member attribute is REQUIRED or OPTIONAL for the
- Printer to support
-
- c) Whether the member attribute is REQUIRED or OPTIONAL for the client
- to supply in a request
-
- d) The member attribute's syntax type, which can be any attribute
- syntax, including '1setOf X', 'collection', and '1setOf
- collection'. If this attribute name is the same as another
- attribute (case of option a-1 above), it MUST have the same
- attribute syntax, including cardinality (1setOf or not)
-
- e) The semantics of the member attribute. The semantic definition MUST
- include a description of any constraint or boundary conditions the
- member attribute places on the associated attribute, especially if
- the attribute is the same as another attribute used in a different
- context (case of option a-1 above)
-
- f)
-
- g) Depending on the collection attributes context, it MUST follow the
- additional rules specified below for the various contexts.
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 8]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-3.4 Collection Attributes as Operation Attributes
-
-The definition documents that define a collection attribute for use as
-an operation attribute MUST follow these additional rules:
-
- a)Define in which operation requests the collection attribute is
- intended to be used.
-
- b)Define in which operation responses the collection attribute is
- intended to be used.
-
-
-3.5 Collections as Job Template Attributes
-
-The definition documents for collection attributes that are specified to
-be Job Template attributes (see [ipp-mod] section 4.2) MUST have
-associated printer attributes with suffixes of "-supported" and "-
-default" (or indicate that there is no "-default"), just as for any Job
-Template attribute. Certain Job Template collection attributes also
-have an associated Printer attribute with "-ready" (for example, see the
-"media-ready" attribute in [ipp-mod]). Furthermore member attributes of
-job template attributes are addressed using the same suffix convention.
-
-See also section 3.6 on the interaction of collections and the Get-
-Printer-Attributes and Get-Jobs-Attributes.
-
-For the following rules assume the "xxx" (collection) example from
-section 3.2 is a job template attribute.
-
-1)There MUST be two associated printer attributes. The attributes are
- "xxx-supported" and "xxx-default"
-
-2)The "xxx-default" is a collection with a syntax identical to the
- "xxx" specification in section 3.2 .
-
- @ Each member attribute has the same name as in the "xxx"
- definition.
-
- @ A Get-Printer-Attributes operation MUST return the "xxx-default"
- (collection) Printer attribute and all the member attributes.
- Any default values that have been set MUST be returned. Any
- default values that have not been set MUST return an out of band
- attribute of 'no-value'.
-
-3.If the definition of the collection does not mention an "xxx-ready"
- attribute than it is assumed that one is not defined, though
- implementer's are free to support an "xxx-ready" as an extension.
-
-4.The collection attribute definition document MUST define an "xxx-
- supported" attribute with either a syntax of '1setOf type2 keyword'
- or '1setOf collection':
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 9]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- @ If the definition uses the '1setOf type2 keyword' attribute
- syntax, it MUST be the attribute keyword names of all of the
- member attributes that the Printer implementation supports in a
- Job Creation operation. Furthermore, the definition MUST
- include corresponding definitions of each of the "aaa-supported"
- attributes that correspond to each "aaa" member attribute. Then
- a client can determine the supported values of each member
- attribute in the Job Template collection attribute
-
- @ If the definition uses the '1setOf collection' attribute syntax,
- then the values are the supported instances of the "xxx"
- (collection) attribute that a client can supply in a Job
- Creation operation. It is expected that this second approach
- will be used for small collections whether the number of
- possible collection values is small. For example, a "media-
- size" (collection) member attribute in which the member
- attributes are "x-dimension" (integer) and "y-dimension"
- (integer). The pairs of integers are just like keywords as far
- as the client localization is concerned, except that if the
- client doesn't recognize a size pair of numbers, it can display
- the numbers.
-
- a) The keywords returned lists all the contained member attribute
- names. This example would return the "aaa" keyword.
-
- b) The list is recursive and lists all the member attributes of the
- contained collections. In section 3.3 the printer would return
- "aaa" and "bbb" for collection "xxx"
-
- c) The encoding convention allows the reconstruction of the collection
- structure. The will allow the client to reconstruct the
- collections. The client would know that "aaa" is a member of
- collection "xxx". It can also be derived that collection "bbb" is
- a member of collection "yyy". See section 7 for more information
- on encoding.
-
- d) To obtain the supported values for any member attribute a client
- performs a Get-Printer-Attributes operation explicitly requesting
- the member attribute name with the suffix "supported". If a member
- attribute is itself a collection rule 4 above applies to member
- attribute.
-
-
-3.6 Collections and Get-Printer-Attributes and Get-Job-Attributes
- operations
-
-The behavior of collections for "job-description" and "printer-
-description" is similar to any other attribute. Simple attributes
-return the attribute and its value. For a collection, the collection
-and its entire member attributes and their values are returned. This
-includes any containing collections, its member attributes and their
-values. The same logic applies for the "-default" and "-ready" printer
-attribute associated with a job-template attributes.
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 10]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-Whether the Printer applies individual member attributes independently
-or takes into account the member attributes supplied by the client in
-the collection, depends on implementation. Therefore, a client SHOULD
-query the Printer's "xxx-default" (collection) attribute, allow the user
-to make any changes, and then submit the entire collection to the
-Printer. Then the variability in defaulting between different
-implementations will not cause the user to get unexpected results.
-
-The semantics for "-supported" is different for a collection. Here the
-focus is on the member attributes that the collection supports. This
-solution allows for extension of collections and allowing the member
-attributes of a collection to vary (i.e. mandatory and optional member
-attributes). Once a client determines what member attributes are
-supported in a collection a subsequent request can be constructed to
-determine the supported values for the member attributes.
-
-Another advantage of that the behavior of the "-supported" printer
-collection attribute is limiting the amount of data that is returned on
-general queries. A 'get-printer-attributes' that returns all the
-attributes of a printer will not have to return what may turn out to be
-extensive lists of "-supported" attribute values. An example might be
-"media-col" that could be a representation for media using a collection
-that goes beyond the information currently provided by the job-template
-attribute "media". The "media-col" could now be used to represent a
-job's media, insert sheets and inserted tab sheets. An IPP Printer
-implementation would return the member attributes for each of the "-
-supported" collections.
-
-
-4 New Out-of-band value
-
-
-4.1 'none'
-
-'none' The specified Job Template attribute in the request MUST
- NOT be applied to the job. Specifically, this value
- overrides the Printer's "xxx-default" attribute value for
- the Job Template attribute, if one exists.
-
-
-This "out-of-band" value allows a client to specify "turn-off" a feature
-that is specified by an attribute whose value is a collection. Because a
-client specifies a value, the Printer uses the client-specified value
-and not the Printer's default value.
-
-
-If a Printer supports the use of the 'collection' attribute syntax for
-an attribute, a Printer MUST support the use of the "out-of-band" value
-'none'.
-
-
-A Printer MUST support the "out-of-band" value 'none' as the value for
-an attribute "xxx" if:
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 11]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- @ the definition of the attribute specifies 'none' MUST be
- supported AND
-
-
- @ the definition of the attribute specifies 'none' MAY be
- supported and it is a value of the attribute "xxx-supported".
-
-
-5 Unsupported Values
-
-
-The rules for returning an unsupported collection attribute are an
-extension to the current rules.
-
- If the entire collection attribute is unsupported, then the Printer
- returns just the collection attribute name with the 'unsupported'
- out-of-band value (see the beginning of [ipp-mod] section 4.1) in the
- Unsupported Attributes Group.
-
- If a collection contains unrecognized, unsupported member attributes
- and/or conflicting values, the attribute returned in the Unsupported
- Group is a collection containing the unrecognized, unsupported member
- attributes, and/or conflicting values. The unrecognized member
- attributes have an out-of-band value of 'unsupported' (see the
- beginning of [ipp-mod] section 4.1). The unsupported member
- attributes and conflicting values have their unsupported or
- conflicting values.
-
-
-6 Sample specification
-
-
-This example is for a collection called "media-col". The "media-col"
-attribute is a job template attribute. This collection is simplified
-and fictitious and is used for illustrative purposes only.
-
-Name: media-col
-
-Syntax: collection
-
-Member Attributes:
-
- Name: "media-color"
-
- Syntax: type3 keyword | name
-
- Mandatory
-
- Semantics: This attribute identifies the color of the media. Valid
- values are "red" "white" and "blue"
-
- "media-color-supported" syntax: 1setOf (type2 keyword | name)
-
- Name: "media-size"
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 12]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- Syntax: collection
-
- Member Attributes:
-
- Name: "x-dimension"
-
- Syntax: integer
-
- Mandatory
-
- Semantics: This attribute identifies length of the media in
- inches. Valid values are any integer though in practice
- implementation will constrain the range.
-
- x-supported syntax: rangeOfInteger
-
- Name: "y-dimension"
-
- Syntax: integer
-
- Mandatory
-
- Semantics: This attribute identifies the width of the media in
- inches. Valid values are any integer though in practice
- implementation will constrain the range.
-
- y-supported syntax: rangeOfInteger
-
- Name: name
-
- Syntax: See job template attribute "media"
-
- Optional
-
- Semantics: See job template attribute "media". Additional
- restrictions on "media" in this collection are that the "media"
- value must be valid based on the size and color. When invalid
- names are given based on the size or color, the size or color value
- takes precedence.
-
- Supported values identical to job template attribute "media-
- supported".
-
-
-
-
-7 Encoding
-
-
-This section is still under construction.
-
-We are now down to considering two encodings for collections. The goals
-of the encoding are:
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 13]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- a) must be simple
-
- b) a legacy receiver must correctly ignore a collection value and not
-incorrectly decode part of a collection as a legitimate attribute.
-
- c) it parses an attributes with collection values as a single unknown
-attribute rather than as many unknown attributes.
-
-The two encodings are:
-
- 1) encode attributes within collections in the same way as
- attributes outside of collections, but encode each attribute name
- in a collection so that its name cannot be the same as an attribute
- name outside of a collection. We have considered two solutions for
- encoding attribute names.
-
- a) add a prefix to each collection member attribute name where
- the prefix is the (outer) attribute's name following by a dot
- ("."). Nested collections have extra levels of dotted names.
- For example, the "media-size" attribute in "media-col" is
- encoded as "media-col.media-size" and the "x" attribute in
- "media-size" which is inside "media" is encoded as "media-
- col.media-size.x". The outer attribute name is the "name" of
- the begin-collection and end-collection value.
-
- b) add a hyphen suffix to each attribute name in a collection.
- For example, the "media-size" attribute in "media-col" is
- encoded as "media-size-" and the "x" attribute in "media-size"
- which is inside "media" is encoded as "x-". Note the hyphen
- must be a suffix so that the attribute name follows the rules
- for a legal keyword, and the hyphen is chosen because no
- attributes currently end with a hyphen. The empty name is used
- for the end-collection value and all but the first begin-
- collection value.
-
- 2) encode attributes within a collection as a 1setOf values where
- each attribute whose name is M and whose values are V1 ... Vn are
- encoded as a sequence of n+1 values M, V1, ... Vn. Subsequent
- member attributes continue the value in the 1setOf values.
-
-The following are examples of encodings. In the real encoding, each
-"attribute" consists of
-
- a) a one byte tag
-
- b) a two byte name length whose value is "n"
-
- c) "n" bytes of a name
-
- d) a two bytes value length whose value is "v"
-
- e) "v" bytes of a value
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 14]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-To make it easy to read, we show only items c (the name), a (the tag)
-and e (the value), in that order.
-
-There are 3 encoding examples for each solution:
-
- i) media-col with media-color and media-size as member attributes,
-and where media-size contains "x" and "y" as collection members.
-
- ii) media-size-supported with two collection values.
-
- iii) job-notify with notify-recipients and notify-events which is a
-1setOf keyword with 3 values in this example
-
-Solution 1a)
-
-
-
- Name syntax-type value
- "media-col" begin-collection ""
- "media-col.media-color" keyword white
- "media-col.media-size" begin-collection ""
- "media-col.media-size.x" integer 850
- "media-col.media-size.y" integer 1100
- "media-col.media-size" end-collection ""
- "media-col" end-collection ""
-
- Name syntax-type value
- "media-size-supported" begin-collection ""
- "media-size-supported.x" integer 850
- "media-size-supported.y" integer 1100
- "media-size-supported" end-collection ""
- "media-size-supported" begin-collection ""
- "media-size-supported.x" integer 850
- "media-size-supported.y" integer 1400
- "media-size-supported" end-collection ""
-
- Name syntax-type value
- "job-notify" begin-collection ""
- "job-notify.notify-recipients" url "mailto://bill@foo.com"
- "job-notify.notify-events" keyword job-completed
- "" keyword job-created
- "" keyword job-state-changed
- "job-notify" end-collection ""
-
-
-Solution 1b)
-
- Name syntax-type value
- "media-col" begin-collection ""
- "media-color-" keyword white
- "media-size-" begin-collection ""
- "x-" integer 850
- "y-" integer 1100
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 15]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- "media-size-" end-collection ""
- "" end-collection ""
-
- Name syntax-type value
- "media-size-supported" begin-collection ""
- "x-" integer 850
- "y-" integer 1100
- "" end-collection ""
- "" begin-collection ""
- "x-" integer 850
- "y-" integer 1400
- "" end-collection ""
-
- Name syntax-type value
- "job-notify" begin-collection ""
- "notify-recipients-" url "mailto://bill@foo.com"
- "notify-events-" keyword "job-completed"
- "" keyword "job-created"
- "" keyword "job-state-changed"
- "job-notify" end-collection ""
-
-
-Solution 2)
-
- Name syntax-type value
- "media-col" begin-collection ""
- "" attribute-name "media-color"
- "" keyword white
- "" attribute-name "media-size"
- "" begin-collection ""
- "" attribute-name "x"
- "" integer 850
- "" attribute-name "y"
- "" integer 1100
- "" end-collection ""
- "" end-collection ""
-
- Name syntax-type value
- "media-size-supported" begin-collection ""
- "" attribute-name "x"
- "" integer 850
- "" attribute-name "y"
- "" integer 1100
- "" end-collection ""
- "" begin-collection ""
- "" attribute-name "x"
- "" integer 850
- "" attribute-name "y"
- "" integer 1400
- "" end-collection ""
-
- Name syntax-type value
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 16]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- "job-notify" begin-collection ""
- "" attribute-name "notify-recipients"
- "" url mailto://bill@foo.com"
- "" attribute-name "notify-events"
- "" keyword "job-completed"
- "" keyword "job-created"
- "" keyword "job-state-changed"
- "" end-collection ""
-
-
-
-
-Observations:
-
-Solution 1a have identical properties to solution 1b except that the
-rules for encoding the name are more complicated for 1a, and the name of
-the attribute appears before each end-collection and end-collection in
-1a but only before the first begin-collection in 1b.
-
-If a collection aware client sends a collection to a collection unaware
-Printer:
-
-For solutions 1a and 1b) the Printer sees many attributes in place of
-the collection and it returns in the Unsupported attribute group, all of
-the attributes: the attribute outside the collection and each attribute
-in the collection with it altered name. Thus the unsupported attributes
-have names that the client didn't send and they may be in an order that
-makes it hard to reconstruct the collection. In addition, because the
-"end-collection" has the same name as the attribute for 1a, some
-printers will reject the job because the attribute appears twice. Also,
-1a does not work for a 1setOf collection because the name of the
-attributes appear in front of each begin-collection and thus cannot be
-distinguished from two occurrences of the same attribute.
-
-For solution 2) the Printer sees the collection as a 1setOf values where
-some values have unknown syntax types and other values have known syntax
-types. When a collection-unaware printer discovers it doesn't
-understand an attribute that is a collection, it sees the unknown
-attribute as a 1setOf rather than a collection. It still returns the
-attribute-name with the out-of-band value "unsupported" making it easier
-for the client.
-
-
-
-
-7.1 encoding of a collection (using solution 1a)
-
-NOTE: If we pick another solution to the encoding, this section will
-change.
-
-Each collection MUST have a globally unique name. Each attribute in an
-attribute group or a collection MUST have globally unique name.
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 17]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-Uniqueness is generated by prepending the collection name to the
-attribute using a period, '.' as a separator.
-
-For encoding attributes that have a 'collection' attribute syntax, the
-attribute's name is REQUIRED to be the first part of each of the member
-attribute name separated by a PERIOD (.) character. For example, if a
-"media-col" (collection) Job Template attribute is added to IPP and
-contains a member attribute "color, it MUST be encoded as a "media-
-col.color". In another example, if the "job-sheets" (collection) Job
-Template attribute is added to IPP and reuses the "color" member
-attribute, the "color" attribute MUST be encoded as "job-sheets.color".
-The "xxx.color" attribute has an identical attribute syntax and similar
-semantics.
-
-When encoding a collection attribute "xxx" that contains an attribute
-"aaa". A simplified example of a collection specification is given in
-section 6
-
-1.The beginning of the collection is indicated with a value tag that
- MUST be syntax type 'begincollection' (e.g. 0x34).
-
-2.The length of the collection name (e.g. 0x03)
-
-3.The collection name (e.g. "xxx")
-
-4.A null collection value length (e.g. 0x00)
-
-5.The attributes are encoded as with any other attribute. It is valid
- to have a collection a member of a collection. The modifications
- necessary for encoding member attributes of a collection are as
- follows.
-
- a) The name of the member attribute MUST be prepended with the
- collection name and a period.
-
- b) The length of the member attribute name MUST be adjusted
- appropriately.
-
-6.The end of the collection is indicated with a value tag that MUST be
- syntax type 'endCollection' (e.g. 0x37).
-
-7.The length of the collection name (e.g. 0x03)
-
-8.The collection name (e.g. "xxx")
-
-9.A null collection value length (e.g. 0x00)
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 18]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-7.2 Sample Encoding (using solution 1a)
-
-NOTE: If we pick another solution to the encoding, this section will
-change.
-
-This section defines the encoding of a collection syntax type using
-solution 1a. The collection specified in section 6 is used. The
-encoding is of an implementation that does not support any optional
-attributes. A collection is encoded by using two new tags:
-
-Tag name Tag Meaning
- value
-
-beginCollection 0x34 Begin the named collection.
-
-endCollection 0x37 End the named collection.
-
- A collection value is encoded as a sequence of attribute values
-preceded by a beginCollection attribute and followed by an endCollection
-attribute. The name field of a beginCollection and an endCollection both
-contain the name of the collection type, i.e., the keyword name of the
-collection attribute, which is a string of ASCII characters. The value
-field contains the prefix used for all subordinate member attributes.
-The following example is written in the style of the IPP/1.1 "Encoding
-and Transport" document [ipp-pro]. The following example is for a media
-collection attribute. The media collection contains 2 member
-attributes. One member is "color" that contains a keyword for the
-media's color. The second attribute is a collection that gives the
-media's size. The size collection has two integer attributes "x" and
-"y" that gives the media's size in inches
-
-Octets Symbolic Protocol comments
- Value field
-
-0x34 beginCollecti value-tag Beginning of the collection
- on
-0x0009 name- Length of collection's name
- length
-media-col media-col Name Collection's name
-0x0000 Value-
- length
-
-0x44 keyword type value-tag Member attribute type
-0x000F name- Length of member attribute
- length name
-media-col.color media- Name Name of member attribute
- col.color
-0x0004 value-
- length
-blue blue Value
-
-0x34 beginCollecti value-tag Beginning of the sub-
- on collection
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 19]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-Octets Symbolic Protocol comments
- Value field
-
-0x000E name- Length of sub-collection's
- length name
-media-col.size media- Name Sub-collection's name
- col.size
-0x0000 Value-
- length
-
-0x21 integer type value-tag Member attribute type
-0x0010 name- Length of member attribute
- length name
-media- media- Name Name of member attribute
-col.size.x col.size.x
-0x0004 value-
- length
-0x0006 Value
-
-0x21 integer type value-tag Member attribute type
-0x0007 name- Length of member attribute
- length name
-media- media- Name Name of member attribute
-col.size.y col.size.y
-0x0004 value-
- length
-0x0004 Value
-
-0x37 endCollection value-tag end of the sub-collection
-0x0007 name- Length of sub-collection's
- length name
-media-col.size media- Name Sub-collection's name
- col.size
-0x0000 Value-
- length
-
-0x37 endCollection value-tag end of the collection
-0x0007 name- Length of collection's name
- length
-media-col media-col Name Sub-collection's name
-0x0000 Value-
- length
-
-
-
-7.3 1setOf Collection encoding (using solution 1a)
-
-The encoding of a set of collections follows the standard method of
-encoding multi-valued IPP attributes. The "beginCollection" attribute
-is coded normally. The first instance of the collection follows. The
-"endCollection" MUST appear only once in a collection and MUST follow
-the last member of the set of collection. The member collections of a
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 20]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-set of collections are delineated by a specially encoded
-"beginCollection" attribute. The type MUST be "beginCollection" (i.e.
-0x34). The length of the name field MUST be 0x0000. The name field
-MUST be omitted. The length of the value MUST be the length of the
-collection's prefix. The value MUST be the prefix.
-
-
-7.4 Sample 1setOf Collection encoding (using solution 1a)
-
-NOTE: If we pick another solution to the encoding, this section will
-change.
-
-This section defines the encoding of a collection syntax type using
-solution 1a. The collection specified in section 7 is used. The
-difference is that the type of "media-col" is 1setOf collection instead
-of collection. The encoding is of an implementation that does not
-support any optional attributes.
-
-
-
-Octets Symbolic Protocol comments
- Value field
-
-0x34 beginCollecti value-tag Beginning of the collection
- on
-0x0009 name- Length of collection's name
- length
-media-col media-col Name Collection's name
-0x0000 Value-
- length
-
-0x44 keyword type value-tag Member attribute type
-0x000F name- Length of member attribute
- length name
-media-col.color media- Name Name of member attribute
- col.color
-0x0004 value-
- length
-blue blue Value
-
-0x34 beginCollecti value-tag Beginning of the sub-
- on collection
-0x000E name- Length of sub-collection's
- length name
-media-col.size media- Name Sub-collection's name
- col.size
-0x0000 Value-
- length
-
-0x21 integer type value-tag Member attribute type
-0x00010 name- Length of member attribute
- length name
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 21]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-Octets Symbolic Protocol comments
- Value field
-
-media- media- Name Name of member attribute
-col.size.y col.size.y
-0x0004 value-
- length
-0x0006 Value
-
-0x21 integer type value-tag Member attribute type
-0x00010 name- Length of member attribute
- length name
-media- media- Name Name of member attribute
-col.size.x col.size.x
-0x0004 value-
- length
-0x0004 Value
-
-0x37 endCollection value-tag end of the sub-collection
-0x000E name- Length of sub-collection's
- length name
-media-col.size media- Name Sub-collection's name
- col.size
-0x0000 Value-
- length
-
-
- Second collection in set
-
-0x34 beginCollecti value-tag Beginning of the collection
- on
-0x0000 name- Indicates continuation of
- length set
-0x0000 Value-
- length
-
-0x44 keyword type value-tag Member attribute type
-0x000F name- Length of member attribute
- length name
-media-col.color media- Name Name of member attribute
- col.color
-0x0003 value-
- length
-red red Value
-
-0x34 beginCollecti value-tag Beginning of the sub-
- on collection
-0x000E name- Length of sub-collection's
- length name
-media-col.size media- Name Sub-collection's name
- col.size
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 22]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-Octets Symbolic Protocol comments
- Value field
-
-0x0000 Value-
- length
-
-0x21 integer type value-tag Member attribute type
-0x0010 name- Length of member attribute
- length name
-media- media- Name Name of member attribute
-col.size.y col.size.y
-0x0004 value-
- length
-0x0006 Value
-
-0x21 integer type value-tag Member attribute type
-0x0010 name- Length of member attribute
- length name
-media- media- Name Name of member attribute
-col.size.x col.size.x
-0x0004 value-
- length
-0x0004 Value
-
-0x37 endCollection value-tag end of the sub-collection
-0x000E name- Length of sub-collection's
- length name
-media-col.size media- Name Sub-collection's name
- col.size
-0x0000 Value-
- length
-
-0x37 endCollection value-tag end of the set of
- collections
-0x0009 name- Length of collection's name
- length
-media-col media-col Name collection's name
-0x0000 Value- Length of collection's
- length prefix
-
-
-
-
-
-8 Legacy issues
-
-
-IPP 1.x Printers and Clients will gracefully ignore collections and its
-member attributes if it does not understand the collection. The
-begCollection and endCollection elements each look like an attribute
-with an attribute syntax that the recipient doesn't support and so
-should ignore the entire attribute. The individual member attributes
-will look like ordinary attributes, but since they each are encoded with
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 23]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-a unique name that can't be the same as a top level attribute, each of
-the member attributes will also look like attributes that the recipient
-doesn't support and so should ignore.
-
-
-9 IANA Considerations
-
-
-This attribute syntax will be registered with IANA after the WG approves
-its specification according to the procedures for extension of the
-IPP/1.1 Model and Semantics [ipp-mod].
-
-ISSUE 04 - Since this is intended to be a standards track document, do
-we also register the attribute syntax with IANA?
-
-
-10 Internationalization Considerations
-
-
-This attribute syntax by itself has no impact on internationalization.
-However, the member attributes that are subsequently defined for use in
-a collection may have internationalization considerations, as may any
-attribute, according to [ipp-mod].
-
-
-11 Security Considerations
-
-
-This attribute syntax causes no more security concerns than any other
-attribute syntax. It is only the attributes that are subsequently
-defined to use this or any other attribute syntax that may have security
-concerns, depending on the semantics of the attribute, according to
-[ipp-mod].
-
-
-12 References
-
-[ipp-mod]
- Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P.,
- "Internet Printing Protocol/1.1: Model and Semantics" draft-ietf-
- ipp-model-v11-06.txt, March 1, 2000.
-
-[ipp-ntfy]
- Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
- Bergman, R. " Internet Printing Protocol/1.0 & 1.1: IPP Event
- Notification Specification" draft-ietf-ipp-not-spec-02.txt, work in
- progress, February 2, 2000.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 05.txt, March 1, 2000.
-
-[RFC2565]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 24]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
-[RFC2566]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April 1999.
-
-[RFC2567]
- Wright, D., "Design Goals for an Internet Printing Protocol", RFC
- 2567, April 1999.
-
-[RFC2568]
- Zilles, S., "Rationale for the Structure and Model and Protocol for
- the Internet Printing Protocol", RFC 2568, April 1999.
-
-[RFC2569]
- Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
- LPD and IPP Protocols", RFC 2569, April 1999.
-
-[RFC2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-
-13 Author's Addresses
-
- Roger deBry
- Utah Valley State College
- Orem, UT 84058
- Phone: (801) 222-8000
- EMail: debryro@uvsc.edu
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
- Robert Herriot
- Xerox Corp.
- 3400 Hill View Ave, Building 1
- Palo Alto, CA 94304
- Phone: 650-813-7696
- Fax: 650-813-6860
- e-mail: robert.herriot@pahv.xerox.com
-
- Kirk Ocke
- Xerox Corp.
- 800 Phillips Rd
- M/S 139-05A
- Webster, NY 14580
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 25]
- [Expires: September 9, 2000]
-
-
-
-
-INTERNET-DRAFT IPP: The 'collection' attribute syntax March 9, 2000
-
-
- Phone: (716) 442-4832
- EMail: kirk.ocke@usa.xerox.com
-
- Peter Zehler
- Xerox Corp.
- 800 Phillips Rd
- M/S 139-05A
- Webster, NY 14580
- Phone: (716) 265-8755
- EMail: peter.zehler@usa.xerox.com
-
-14 Appendix A: Full Copyright Statement
-
-
-Copyright (C) The Internet Society (1998,1999,2000). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Ocke, Zehler [page 26]
- [Expires: September 9, 2000]
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Roger deBry
+<draft-ietf-ipp-collection-04.txt> Utah Valley State College
+ T. Hastings
+ Xerox Corporation
+ R. Herriot
+ Xerox Corporation
+ K. Ocke
+ Xerox Corporation
+ P. Zehler
+ Xerox Corporation
+ January 24, 2001
+
+
+ Internet Printing Protocol (IPP):
+ The 'collection' attribute syntax
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+
+
+Status of this Memo:
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+Abstract
+ This document specifies an OPTIONAL attribute syntax called
+ 'collection' for use with the Internet Printing Protocol/1.0
+ (IPP) [RFC2565, RFC2566], IPP/1.1 [RFC2911, RFC2910], and
+ subsequent versions. A 'collection' is a container holding one or
+ more named values, which are called "member" attributes. A
+ collection allows data to be grouped like a PostScript dictionary
+ or a Java Map. This document also specifies the conformance
+ requirements for a definition document that defines a collection
+ attribute. Finally, this document gives some illustrative
+ example collection attribute definitions that are not intended as
+ actual attribute specifications.
+
+
+deBry, et al. Expires: July 24, 2001 [page 1]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
+ Mapping between LPD and IPP Protocols [RFC2569]
+
+ The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that
+ are satisfied in IPP/1.0. A few OPTIONAL operator operations have
+ been added to IPP/1.1.
+
+ The "Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol" document describes IPP from a high level
+ view, defines a roadmap for the various documents that form the suite
+ of IPP specification documents, and gives background and rationale
+ for the IETF working group's major decisions.
+
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1 [RFC2616]. It defines the
+ encoding rules for a new Internet MIME media type called
+ "application/ipp". This document also defines the rules for
+ transporting over HTTP a message body whose Content-Type is
+ "application/ipp". This document defines a new scheme named 'ipp'
+ for identifying IPP printers and jobs.
+
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 2]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+Table of Contents
+
+
+
+ 1 Introduction....................................................5
+ 1.1 Problem Statement ............................................5
+ 1.2 Solution .....................................................5
+
+ 2 Terminology.....................................................6
+ 2.1 Conformance Terminology ......................................6
+ 2.2 Other terminology ............................................7
+
+ 3 Definition of a Collection Attribute............................7
+ 3.1 Information to Include .......................................7
+ 3.2 Nested Collections ..........................................11
+
+ 4 Collection Attributes as Attributes in Operations..............11
+ 4.1 General Rules ...............................................11
+ 4.2 Unsupported Values ..........................................11
+
+ 5 Example definition of a collection attribute...................12
+ 5.1 media-col (collection) ......................................12
+ 5.1.1media-color (type3 keyword | name(MAX) ......................13
+ 5.1.2media-size (collection) .....................................13
+ 5.2 media-col-default (collection) ..............................14
+ 5.3 media-col-ready (1setOf collection) .........................14
+ 5.4 media-col-supported (1setOf type2 keyword) ..................14
+
+ 6 A Second Example Definition Of A Collection Attribute..........15
+
+ 7 Encoding.......................................................15
+ 7.1 Additional tags defined for representing a collection attribute
+ value16
+ 7.2 Example encoding: "media-col" (collection) ..................17
+
+ 8 Legacy issues..................................................23
+
+ 9 IANA Considerations............................................23
+ 9.1 Attribute Syntax Registration ...............................23
+
+ 10 Internationalization Considerations............................23
+
+ 11 Security Considerations........................................24
+
+ 12 References.....................................................24
+
+ 13 Author's Addresses.............................................25
+
+ 14 Appendix A: Encoding Example of a Simple Collection............26
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 3]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ 15 Appendix B: Encoding Example of 1setOf Collection..............29
+
+ 16 Appendix C: Encoding Example of Collection containing 1setOf XXX
+ attribute.........................................................34
+
+ 17 Appendix D: Full Copyright Statement...........................38
+
+
+Table of Tables
+
+ Table 1 - "media-col" member attributes...........................13
+ Table 2 - "media-size" collection member attributes...............13
+ Table 3 - Tags defined for encoding the 'collection' attribute syntax
+ ..............................................................16
+ Table 4 - Overview Encoding of "media-col" collection.............18
+ Table 5 - Example Encoding of "media-col" collection..............18
+ Table 6 - Overview Encoding of simple collection..................26
+ Table 7 - Example Encoding of simple collection...................26
+ Table 8 - Overview Encoding of 1setOf collection..................29
+ Table 9 - Example Encoding of 1setOf collection...................30
+ Table 10 - Overview Encoding of collection with 1setOf value......34
+ Table 11 - Example Encoding of collection with 1setOf value.......35
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 4]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+
+
+1 Introduction
+
+
+1.1 Problem Statement
+
+ The IPP Model and Semantics [RFC2911] supports most of the common
+ data structures that are available in programming languages. It lacks
+ a mechanism for grouping several attributes of different types. The
+ Java language uses the Map to solve this problem and PostScript has a
+ dictionary. The new mechanism for grouping attributes together
+ (called 'collection' mechanism) must allow for optional members and
+ subsequent addition of new members.
+
+ The 'collection' mechanism must be encoded in a manner consistent
+ with existing 1.0 and 1.1 parsing rules (see [RFC2910]). Current 1.0
+ and 1.1 parsers that don't support the 'collection' mechanism must
+ not confuse collections or parts of collection they receive with
+ other attributes.
+
+
+1.2 Solution
+
+ The new mechanism is a new IPP attribute syntax called a
+ 'collection'. As such, each collection value is a value of an
+ attribute whose attribute syntax type is defined to be a
+ 'collection'. Such an attribute is called a collection attribute.
+ The name of the collection attribute serves to identify the
+ collection value in an operation request or response, as with any
+ attribute value.
+
+ The 'collection' attribute syntax is a container holding one or more
+ named values (i.e., attributes), which are called member attributes.
+ Each collection attribute definition document lists the mandatory and
+ optional member attributes of each collection value. A collection
+ value is similar to an IPP attribute group in a request or a
+ response, such as the operation attributes group. They both consist
+ of a set of attributes.
+
+ As with any attribute syntax, the document that defines a collection
+ attribute specifies whether the attribute is single-value
+ (collection) or multi-valued (1setOf collection). If the attribute is
+ multi-valued (1setOf collection) each collection value MUST be a
+ separate instance of a single definition of a collection, i.e. it
+ MUST have the same member attributes except for OPTIONAL member
+ attributes. If we view each collection definition as a separate
+ syntax type, this rule continues the IPP/1.1 notion that each
+
+
+deBry, et al. Expires: July 24, 2001 [page 5]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ attribute has a single type or pattern (e.g. "keyword | name" is a
+ pattern). Without this rule, the supported values would be more
+ difficult to describe and the mechanism defined in item 4 of section
+ 3.1 would not be sufficient.
+
+ The name of each member attribute MUST be unique for a collection
+ attribute, but MAY be the same as the name of a member attribute in
+ another collection attribute and/or MAY be the same as the name of an
+ attribute that is not a member of a collection. The rules for naming
+ member attributes are given in section 3.1.
+
+ Each member attribute can have any attribute syntax type, including
+ 'collection', and can be either single-valued or multi-valued. The
+ length of a collection value is not limited. However, the length of
+ each member attribute MUST NOT exceed the limit of its attribute
+ syntax.
+
+ The member attributes in a collection MAY be in any order in a
+ request or response. When a client sends a collection attribute to
+ the Printer, the order that the Printer stores the member attributes
+ of the collection value and the order returned in a response MAY be
+ different from the order sent by the client.
+
+ A collection value MUST NOT contains two or more member attributes
+ with the same attribute name. Such a collection is mal-formed.
+ Clients MUST NOT submit such malformed requests and Printers MUST NOT
+ return such malformed responses. If such a malformed request is
+ submitted to a Printer, the Printer MUST (depending on
+ implementation) either (1) reject the request with the 'client-error-
+ bad-request' status code (see section 13.1.4.1), or (2) accept the
+ request and use only one of each duplicate member attribute.
+
+
+
+2 Terminology
+
+ This section defines terminology used throughout this document.
+
+
+2.1 Conformance Terminology
+
+ Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+ NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+ conformance. These terms are defined in [RFC2911] section 12.1 on
+ conformance terminology, most of which is taken from RFC 2119
+ [RFC2119].
+
+ The following specialization of these terms apply to this document:
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 6]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ REQUIRED: if an implementation supports the extensions described in
+ this document, it MUST support a REQUIRED feature.
+
+ OPTIONAL: if an implementation supports the extensions described in
+ this document, it MAY support an OPTIONAL feature.
+
+
+2.2 Other terminology
+
+ This document uses terms such as Job object (or Job), IPP Printer
+ object (or Printer), "operation", "request", response", "attributes",
+ "keywords", and "support". These terms have special meaning and are
+ defined in the model terminology [RFC2911] section 12.2. The
+ following additional terms are introduced in this document:
+
+ collection: an attribute syntax in which each attribute value is a
+ set of attributes, called member attributes.
+
+ member attribute: an attribute that is defined to be used as one
+ of the attributes in a collection.
+
+ collection attribute: an attribute whose definition specifies the
+ 'collection' attribute syntax and each of the member attributes
+ that MAY occur in a collection attribute value.
+
+
+
+3 Definition of a Collection Attribute
+
+ This section describes the requirements for any collection attribute
+ definition.
+
+
+3.1 Information to Include
+
+ When a specification document defines an "xxx" collection attribute,
+ i.e., an attribute whose attribute syntax type is 'collection' or
+ '1setOf collection'; the definition document MUST include the
+ following aspects of the attribute semantics. Suppose the "xxx"
+ collection attribute contains N member attributes named "aaa1",
+ "aaa2", _, "aaaN" ("aaaI" represents any one of these N member
+ attributes).
+
+ 1. The name of the collection attribute MUST be specified (e.g.
+ "xxx"). The selection of the name "xxx" MUST follow the same rules
+ for uniqueness as for attributes of any other syntax type (as
+ defined by IPP/1.1) unless "xxx" is a member attribute of another
+ collection. Then the selection of the name "xxx" MUST follow the
+ rules for uniqueness defined in item 5a) of this list.
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 7]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ 2. The collection attribute syntax MUST be of type 'collection' or
+ '1setOf collection'.
+
+ 3. The context of the collection attribute MUST be specified, i.e.,
+ whether the attribute is an operation attribute, a Job Template
+ attribute, a Job Description attribute, a Printer Description
+ attribute, a member attribute of a particular collection attribute,
+ etc.
+
+ 4. An "xxx-supported" attribute MUST be specified and it has one of
+ the following two forms:
+
+ a)"xxx-supported" is a "1setOf collection" which enumerates all of
+ the supported collection values of "xxx". If a collection of
+ this form contains a nested collection, it MUST be of the same
+ form.
+
+ For example, "media-size-supported" might have the values {{x-
+ dimension:210, y-dimension:297},{x-dimension:297, y-
+ dimension:420}} to show that it supports two values of "media
+ size": A4 (210x297) and A3 (297x420). It does not support other
+ combinations of "x-dimension" and "y-dimension" member
+ attributes, such as 210x420 or 297x297 and it does not supported
+ non-enumerated values, such as 420x595.
+
+ b)"xxx-supported" is a "1setOf type2 keyword" which enumerates
+ the names of all of the member attributes of "xxx": "aaa1",
+ "aaa2", _, "aaaN". If a collection of this form contains a
+ nested collection, it MAY be of either form. See item 5f) below
+ for details on supported values of member attributes.
+
+ For example, "media-col-supported" might have the keyword
+ values: "media-size" and "media-color".
+
+ 5. The member attributes MUST be defined. For each member attribute
+ the definition document MUST provide the following information:
+
+
+ a)The member attribute's name (e.g., "aaa") MUST be unique within
+ the collection being defined and MUST either
+
+
+ i) reuse the attribute name of another attribute (that is unique
+ across the entire IPP attribute name space) and have the same
+ syntax and semantics as the reused attribute (if the condition
+ of item 4b) above is met). For example, a member attribute
+ definition could reuse the IPP/1.1 "media" attribute.
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 8]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ ii) potentially occur elsewhere in the entire IPP attribute
+ name space. (if the condition of item 4a) above is met). For
+ example, a member attribute could be "x-dimension" which could
+ potentially occur in another collection or as an attribute
+ outside of a collection.
+
+
+ iii) be unique across the entire IPP attribute name space (if
+ the condition of item 4b) above is met). For example, a member
+ attribute could be "media-color" which must unique be across
+ the entire IPP attribute name space.
+
+
+ b)Whether the member attribute is REQUIRED or OPTIONAL for the
+ Printer to support
+
+
+ c)Whether the member attribute is REQUIRED or OPTIONAL for the
+ client to supply in a request
+
+
+ d)The member attribute's syntax type, which can be any attribute
+ syntax, including '1setOf X', 'collection', and '1setOf
+ collection'. If this attribute name reuses the name of another
+ attribute (case of item a1 above), it MUST have the same
+ attribute syntax, including cardinality (whether or not 1setOf).
+
+
+ e)The semantics of the "aaa" member attribute. The semantic
+ definition MUST include a description of any constraint or
+ boundary conditions the member attribute places on the
+ associated attribute, especially if the attribute reuses the
+ name of another attribute (case of item a1 above)
+
+ f)The supported values for the each "aaaI" member attribute (of
+ the member attributes "aaa1", "aaa2", _, "aaaN") is specified
+ by one of two mechanisms.
+
+ i) If "xxx-supported" is a "1setOf collection" (see item 4a)
+ above), the value for each "aaaI" is specified in each
+ collection value of "xxx-supported" in the context of other
+ member attributes. That is, "xxx-supported" enumerates all
+ supported values of "xxx".
+
+
+ ii) If the value of "xxx-supported" is a "1setOf type2
+ keyword" (see item 4b) above), the supported values of "aaaI"
+ are the values specified by either i) the "aaaI-supported"
+ attribute or ii) the definition of the member attribute "aaaI"
+ within the document defining the "xxx" attribute. The values
+
+
+deBry, et al. Expires: July 24, 2001 [page 9]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ of each member attribute "aaaI" are specified independently of
+ other member attributes though a Printer is not required to
+ support all combinations of supported values.
+
+ For example, "media-col-supported" might have the keyword
+ values: "media-size" and "media-color". Using the first method
+ for defining supported values (an "aaaI-supported" attribute),
+ the collection values of "media-col" are combinations of
+ values of "media-size-supported" and "media-color-
+ supported".If "media-size-supported" has the values of
+ '210x297' and '297x420' and "media-color-supported" has the
+ values of 'white' and 'pink', the Printer might support only
+ the combinations 'white-210x297', 'pink-210x297'and 'white-
+ 297x420', and not 'pink-297x420'.
+
+ If a collection contains a member "aaaI" whose syntax type is
+ "text", the supported values would probably be defined by the
+ definition of "xxx" rather than by the attribute "aaaI-
+ supported".
+
+ g)the default value of each "aaaI" member attribute if it is
+ OPTIONAL for a client to supply the "aaa" member attribute in a
+ request. The default value is specified by in the attribute's
+ definition within a document and MUST be one of the following:
+
+ i) a fixed default
+
+ ii) a mechanism by which the Printer determines default
+
+ iii) an indefinite default that is left to the implementation.
+
+ iv) an attribute that the Printer uses to determine the default
+
+ 6. The default value of "xxx" if a client does not supply it. The
+ default value is specified by in the attribute's definition within
+ a document and MUST be one of the following:
+
+
+ a)a fixed default
+
+
+ b)a mechanism by which the Printer determines default
+
+
+ c)an indefinite default that is left to the implementation
+
+ d)a Printer attribute "xxx-default" which is a collection with the
+ same member attributes as "xxx". Though optional member
+ attributes may be absent in which case the Printer uses the
+ defaulting rules of item 5g) above.
+
+
+deBry, et al. Expires: July 24, 2001 [page 10]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ 7. The "xxx-ready (1setOf collection)" attribute if human intervention
+ is required to make many of the supported values available. For
+ example, "media-col" is an attribute which has a "ready" attribute.
+ Most attributes do not have a "ready" attribute.
+
+
+3.2 Nested Collections
+
+ A member attribute may have a syntax type of 'collection' or '1setOf
+ collection', in which case it is called a nested collection
+ attribute. The rules for a nested collection attribute are the same
+ as for a collection attribute as specified in section 3.1.
+
+
+
+4 Collection Attributes as Attributes in Operations
+
+
+4.1 General Rules
+
+ A collection value is like any other IPP/1.1 value, except that it is
+ structured. The rules for attributes with collection values are the
+ same as for attributes of any other syntax type (see IPP/1.1), be
+ they in any group of a request of a response.
+
+
+4.2 Unsupported Values
+
+ The rules for returning an unsupported collection attribute are an
+ extension to the current rules:
+
+ 1. If the entire collection attribute is unsupported, then the
+ Printer returns just the collection attribute name with the
+ 'unsupported' out-of-band value (see the beginning of [RFC2911]
+ section 4.1) in the Unsupported Attributes Group.
+
+ 2. If a collection contains unrecognized, unsupported member
+ attributes and/or conflicting values, the attribute returned in
+ the Unsupported Group is a collection containing the
+ unrecognized, unsupported member attributes, and/or conflicting
+ values. The unrecognized member attributes have an out-of-band
+ value of 'unsupported' (see the beginning of [RFC2911] section
+ 4.1). The unsupported member attributes and conflicting values
+ have their unsupported or conflicting values.
+
+
+
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 11]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+5 Example definition of a collection attribute
+
+ In some printing environments, it is desirable to allow the client to
+ select the media by its properties, e.g., weight, color, size, etc.,
+ instead of by name. In IPP/1.1 (see [RFC2911]), the "media (type3
+ keyword | name) Job Template attribute allows selection by name. It
+ is tempting to extend the "media" attribute syntax to include
+ "collection", but then existing clients could not understand default
+ or supported media values that use the collection value. To preserve
+ interoperability, a new attribute MUST BE added, e.g., "media-col
+ (collection)". The following subsections contain a sample definition
+ of a simplified "media-col" attribute. The definition follows the
+ rules in section 3.
+
+ All of the example attribute definitions in this document are
+ illustrative examples, rather than actual definitions. These
+ examples are intended to illustrate how to define collection
+ attributes. Other documents MUST define collection attributes for
+ use in actual interchange. Such definitions may be very similar to
+ the examples in this document, since we attempted to pick useful
+ examples.
+
+ Note: we picked the name "media-col" because the name "media" is
+ already in use. Ordinarily the collection attribute would have a name
+ like any other attribute and would not end in "col".
+
+ The member attributes of "media-col" attribute ("media-color (type 3
+ keyword)" and "media-size (collection)") both follow the naming rules
+ of item 4a3 of section 3, i.e. the names are unique across the entire
+ IPP attribute name space. The member attributes of the "media-size
+ (collection)" member attribute ("x-dimension (integer(0,MAX))" and
+ "y-dimension (integer(0,MAX))") both follow the naming rules of item
+ 4a2 of section 3, i.e. they potentially occur elsewhere in the IPP
+ attribute name space.
+
+
+5.1 media-col (collection)
+
+ The "media-col" (collection) attribute augments the IPP/1.1 [RFC2911]
+ "media" attribute. This collection attribute enables a client end
+ user to submit a list of media characteristics to the Printer. When
+ the client specifies media using the "media-col" collection
+ attribute, the Printer object MUST match the requested media exactly.
+ The 'collection' consists of the following member attributes:
+
+
+
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 12]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ Table 1 - "media-col" member attributes
+
+
+
+ Attribute name attribute syntax reque Printer
+ st Support
+
+
+ media-color type3 keyword | name (MAX) MAY MUST
+
+ media-size collection MUST MUST
+
+
+ The definitions for the member attributes is given in the following
+ sub-sections:
+
+
+ 5.1.1 media-color (type3 keyword | name(MAX)
+
+ This member attribute identifies the color of the media. Valid
+ values are 'red', 'white' and 'blue'
+
+ The "media-color-supported" (1setOf (type3 keyword | name(MAX)))
+ Printer attribute identifies the values of this "media-color"
+ member attribute that the Printer supports, i.e., the colors
+ supported.
+
+ If the client omits this member attribute, the Printer determines
+ the value in an implementation dependent manner.
+
+
+ 5.1.2 media-size (collection)
+
+ This member attribute identifies the size of the media. The
+ 'collection' consists of the member attributes shown in Table 2:
+
+
+ Table 2 - "media-size" collection member attributes
+
+
+
+ Attribute attribute syntax request Printer
+ name Support
+
+
+ x-dimension integer (0:MAX) MUST MUST
+
+ y-dimension integer (0:MAX) MUST MUST
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 13]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ The definitions for the member attributes is given in the
+ following sub-sections:
+
+
+ 5.1.2.1 x-dimension (integer(0:MAX))
+ This attribute identifies the width of the media in inch units
+ along the X axis.
+
+
+ 5.1.2.2 y-dimension (integer(0:MAX))
+ This attribute identifies the height of the media in inch
+ units along the Y axis.
+
+ The "media-size-supported" (1setOf collection) Printer
+ attribute identifies the values of this "media-size" member
+ attribute that the Printer supports, i.e., the size
+ combinations supported. The names of the member attributes
+ are the same as the member attributes of the "media-size"
+ collection attribute, namely "x-dimension", and "y-dimension",
+ since they have the same attribute syntax and the same
+ semantics.
+
+
+5.2 media-col-default (collection)
+
+ The "media-col-default" Printer attribute specifies the media that
+ the Printer uses, if any, if the client omits the "media-col" and
+ "media". Job Template attribute in the Job Creation operation (and
+ the PDL doesn't include a media specification). The member
+ attributes are defined in Table 1. A Printer MUST support the same
+ member attributes for this default collection attribute as it
+ supports for the corresponding "media-col" Job Template attribute.
+
+
+5.3 media-col-ready (1setOf collection)
+
+ The "media-col-ready" Printer attribute identifies the media that are
+ available for use without human intervention, i.e., the media that
+ are ready to be used without human intervention. The collection
+ value MUST have all of the member attributes that are supported in
+ Table 1.
+
+
+5.4 media-col-supported (1setOf type2 keyword)
+
+ The "media-col-supported" Printer attribute identifies the keyword
+ names of the member attributes supported in the "media-col"
+ collection Job Template attribute, i.e., the keyword names of the
+ member attributes in Table 1 that the Printer supports.
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 14]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+6 A Second Example Definition Of A Collection Attribute
+
+ All of the example attribute definitions in this document are
+ illustrative examples, rather than actual definitions. These
+ examples are intended to illustrate how to define collection
+ attributes. Other documents MUST define collection attributes for
+ use in actual interchange. Such definitions may be very similar to
+ the examples in this document, since we attempted to pick useful
+ examples.
+
+ In some printing environments, it is desirable to allow the client to
+ select the media for the job start sheet. The reason for not adding
+ the 'collection' attribute syntax to the existing "job-sheets" Job
+ Template attribute is the same as for "media". Instead, a new Job
+ Template attribute is introduced, e.g. "job-sheet-col (collection)".
+
+ The member attributes of "job-sheet-col" attribute ("job-sheets
+ (type 3 keyword)" and "media (type3 keyword | name)") both follow
+ the naming rules of item 4a1 of section 3, i.e they reuse existing
+ IPP attributes. According to the rules, their supported values come
+ from the existing IPP attributes: "job-sheets-supported" and "media-
+ supported". However, their default values do not come from "job-
+ sheets-default" and "media-default", respectively. Rather the
+ definition of "job-sheet-col" says that "job-sheets (type 3 keyword)"
+ is required and if "media (type3 keyword | name)" is absent, the
+ Printer uses the same media as the rest of the job uses.
+
+ If "job-sheet-col" attribute were defined to contain the member
+ attribute "job-sheet-media (type3 keyword | name)" instead of "media
+ (type3 keyword | name)", then the definition would also have to
+ specify a "job-sheet-media-supported (1setOf (type3 keyword |
+ name))" whose values would be independent of "media-supported
+ (1setOf (type3 keyword | name))" and would be set separately by a
+ System Administrator.
+
+ The actual text for the definition of the attribute is left as an
+ exercise for the reader.
+
+
+
+7 Encoding
+
+ This section defines the additional encoding tags used according to
+ [RFC2910] and gives an example of their use. The encoding tags
+ define in this document MUST be used by all collection attributes
+ defined in other documents. However, the example of their use is
+ illustrative only.
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 15]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+7.1 Additional tags defined for representing a collection attribute
+ value
+
+ The 'collection' attribute syntax uses the tags defined in Table 3.
+
+
+ Table 3 - Tags defined for encoding the 'collection' attribute syntax
+
+
+
+ Tag name Tag Meaning
+ value
+
+
+ begCollection 0x34 Begin the collection attribute value.
+
+ endCollection 0x37 End the collection attribute value.
+
+ memberAttrName 0x4A The value is the name of the
+ collection member attribute
+
+
+ When encoding a collection attribute "xxx" that contains an attribute
+ "aaa" and is not inside another collection, the encoding follows
+ these rules:
+
+ 1. The beginning of the collection is indicated with a value tag
+ that MUST be syntax type 'begCollection' (0x34) with a name
+ length and Name field that represent the name of the collection
+ attribute ("xxx") as with any attribute, followed by a value. The
+ Printer MAY ignore the value and its length of MAY be 0. In the
+ future, however, this field MAY contain useful information, such
+ as the collection name (cf. the name of a C struct).
+
+ 2. Each member attribute is encoded as a sequence of two or more
+ values that appear to be part of a single multi-valued attribute,
+ i.e. 1setOf. The first value after the 'begCollection' value has
+ the attribute syntax 'memberAttrName' (0x4A) and its value holds
+ the name of the first member attribute (e.g. "aaa"). The second
+ value holds the first member's attribute value, which can be of
+ any attribute syntax, except 'memberAttrName' or 'endCollection'.
+ If the first member's attribute value is multi-valued, the third
+ value holds the second value of the first member's value.
+ Otherwise, the third value holds the name of second member
+ attribute (e.g. "bbb") and its attribute syntax is
+ 'memberAttrName'. In this case, the fourth member's value is the
+ value of "bbb".
+
+ Note that the technique of encoding a 'collection' as a '1setOf'
+ makes it easy for a Printer that doesn't support a particular
+
+
+deBry, et al. Expires: July 24, 2001 [page 16]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ collection attribute (or the collection attribute syntax at all)
+ to simply skip over the entire collection value.
+
+ 3. The end of the collection is indicated with a value tag that MUST
+ be syntax type 'endCollection' (e.g. 0x37) and MAY have a zero
+ name length and a zero value length. In the future, this field
+ MAY contain useful information,such as the collection name that
+ matches the one in the 'begCollection' .
+
+ 4. It is valid to have a member attribute that is, itself, a
+ collection attribute, i.e., collections can be nested within
+ collections. This is represented by the occurrence of a member
+ attribute that is of attribute syntax type 'begCollection'. Such
+ a collection is terminated by a matching 'endCollection'. The
+ name of such a member attribute is in the immediately preceding
+ value whose syntax type is 'memberAttrName'.
+
+ 5. It is valid for a collection attribute to be multi-valued, i.e.,
+ have more than one collection value. If the next attribute
+ immediately following the 'endCollection' has a zero name length
+ and a tag of 'begCollection', then the collection attribute is a
+ multi-valued collection, as with any attribute. This statement
+ applies to collections within collections and collections that
+ are not in collections.
+
+
+7.2 Example encoding: "media-col" (collection)
+
+ The collection specified in section 5 is used for the encoding
+ example shown in Table 5. The example also shows nested collections,
+ since the "media-size" member attribute is a 'collection. The
+ encoding example represents a blue 4x6-index cards and takes 216
+ octets. The Appendices contains more complex examples.
+
+ Additional examples have been included in the appendices.
+
+ The overall structure of the two collection values can be pictorially
+ represented as:
+
+ "media-col" =
+ { "media-color" = 'blue';
+ "media-size" =
+ { "x-dimension" = 6;
+ "y-dimension" = 4
+ }
+ },
+
+ The full encoding is in table 4. A simplified view of the encoding
+ looks like this:
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 17]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ Table 4 - Overview Encoding of "media-col" collection
+
+
+
+ Tag Value Name Value
+
+
+ begCollection media-col ""
+
+ memberAttrName "" media-color
+
+ keyword "" blue
+
+ memberAttrName "" media-size
+
+ begCollection "" ""
+
+ memberAttrName "" x-dimension
+
+ integer "" 6
+
+ memberAttrName "" y-dimension
+
+ integer "" 4
+
+ endCollection "" ""
+
+ endCollection "" ""
+
+
+
+
+
+
+ Table 5 - Example Encoding of "media-col" collection
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x34 begCollection value-tag beginning of the "media-
+ col" collection attribute
+
+ 0x0009 name- length of (collection)
+ length attribute name
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 18]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ media-col media-col name name of (collection)
+ attribute
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+ 0x4A memberAttrName value-tag starts a new member
+ attribute: "media-color"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of "media-color"
+ length keyword
+
+ media-color media-color value value is name of 1st
+ member attribute
+
+
+ 0x44 keyword type value-tag keyword type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value-
+ length
+
+ blue blue value value of 1st member
+ attribute
+
+
+ 0x4A memberAttrName value-tag starts a new member
+ attribute: "media-size"
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 19]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000A value- length of "media-size"
+ length keyword
+
+ media-size media-size value Name of 2nd member
+ attribute
+
+
+ 0x34 begCollection value-tag Beginning of the "media-
+ size" collection attribute
+ which is a sub-collection
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0000 value- collection attribute names
+ length have no value
+
+ no value (since value-
+ length was 0)
+
+ 0x4A memberAttrName value-tag starts a new member
+ attribute: "x-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of "x-dimension"
+ length keyword
+
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 20]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ x-dimension x-dimension value name of 1st sub-
+ collection member
+ attribute
+
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0006 value value of 1st sub-
+ collection member
+ attribute
+
+
+ 0x4A memberAttrName value-tag starts a new member
+ attribute: "y-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of the "y-
+ length dimension" keyword
+
+ y-dimension y-dimension value name of 2nd sub-
+ collection member
+ attribute
+
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 21]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0004 value value of 2nd sub-
+ collection member
+ attribute
+
+
+ 0x37 endCollection value-tag end of the sub-collection
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+ 0x37 endCollection value-tag end of the 1st collection
+ value in 1setOf
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 22]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+8 Legacy issues
+
+ IPP 1.x Printers and Clients will gracefully ignore collections and
+ its member attributes if it does not understand the collection. The
+ begCollection and endCollection elements each look like an attribute
+ with an attribute syntax that the recipient doesn't support and so
+ should ignore the entire attribute. The individual member attributes
+ and their values will look like a 1setOf values of the collection
+ attribute, so that the Printer simply ignores the entire attribute
+ and all of its values. Returning unsupported attributes is also
+ simple, since only the name of the collection attribute is returned
+ with the 'unsupported' out-of-band value (see section 4.2).
+
+
+
+9 IANA Considerations
+
+ This section contains the exact information for IANA to add to the
+ IPP Registries according to the procedures defined in "IPP/1.1 Model
+ and Semantics" document [RFC2911] section 6.
+
+ Note to RFC Editors: Replace RFC NNNN below with the RFC number for
+ this document, so that it accurately reflects the content of the
+ information for the IANA Registry.
+
+
+9.1 Attribute Syntax Registration
+
+ The attribute syntax defined in this document will be published by
+ IANA according to the procedures in RFC 2911 [RFC2911] section 6.3
+ with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/
+
+ The registry entry will contain the following information:
+
+ Reference:
+ RFC NNNN [this document]
+
+ Attribute Syntaxes: Ref. Section:
+ collection RFC NNNN 3
+
+
+
+
+10 Internationalization Considerations
+
+ This attribute syntax by itself has no impact on
+ internationalization. However, the member attributes that are
+ subsequently defined for use in a collection may have
+
+
+deBry, et al. Expires: July 24, 2001 [page 23]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ internationalization considerations, as may any attribute, according
+ to [RFC2911].
+
+
+
+11 Security Considerations
+
+ This attribute syntax causes no more security concerns than any other
+ attribute syntax. It is only the attributes that are subsequently
+ defined to use this or any other attribute syntax that may have
+ security concerns, depending on the semantics of the attribute,
+ according to [RFC2911].
+
+
+
+12 References
+
+ [ipp-ntfy]
+ Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
+ Bergman, R. " Internet Printing Protocol/1.0 & 1.1: IPP Event
+ Notification Specification" draft-ietf-ipp-not-spec-02.txt, work in
+ progress, February 2, 2000.
+
+ [RFC2565]
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
+
+ [RFC2566]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
+ April 1999.
+
+ [RFC2567]
+ Wright, D., "Design Goals for an Internet Printing Protocol", RFC
+ 2567, April 1999.
+
+ [RFC2568]
+ Zilles, S., "Rationale for the Structure and Model and Protocol for
+ the Internet Printing Protocol", RFC 2568, April 1999.
+
+ [RFC2569]
+ Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
+ LPD and IPP Protocols", RFC 2569, April 1999.
+
+ [RFC2616]
+ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
+ Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+ RFC 2616, June 1999.
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 24]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ [RFC2910]
+ Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
+ 05.txt, March 1, 2000.
+
+ [RFC2911]
+ Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P.,
+ "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911,
+ September 2000.
+
+
+
+13 Author's Addresses
+
+ Roger deBry
+ Utah Valley State College
+ Orem, UT 84058
+ Phone: (801) 222-8000
+ EMail: debryro@uvsc.edu
+
+ Tom Hastings
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+ Robert Herriot
+ Xerox Corp.
+ 3400 Hill View Ave, Building 1
+ Palo Alto, CA 94304
+ Phone: 650-813-7696
+ Fax: 650-813-6860
+ e-mail: robert.herriot@pahv.xerox.com
+
+ Kirk Ocke
+ Xerox Corp.
+ 800 Phillips Rd
+ M/S 139-05A
+ Webster, NY 14580
+ Phone: (716) 442-4832
+ EMail: kirk.ocke@usa.xerox.com
+
+ Peter Zehler
+ Xerox Corp.
+ 800 Phillips Rd
+ M/S 139-05A
+ Webster, NY 14580
+ Phone: (716) 265-8755
+
+
+deBry, et al. Expires: July 24, 2001 [page 25]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ EMail: peter.zehler@usa.xerox.com
+
+
+14 Appendix A: Encoding Example of a Simple Collection
+
+ The overall structure of the collection value can be pictorially
+ represented as:
+
+ " media-size " =
+ { "x-dimension" = 6;
+ "y-dimension" = 4
+ }
+
+ A simplified view of the encoding would look like this:
+
+
+ Table 6 - Overview Encoding of simple collection
+
+
+
+ Tag Value Name Value
+
+
+ begCollection media-size ""
+
+ memberAttrName "" x-dimension
+
+ integer "" 6
+
+ memberAttrName "" y-dimension
+
+ integer "" 4
+
+ endCollection "" ""
+
+
+ Note: "" represents a name or value whose length is 0.
+
+
+ Table 7 - Example Encoding of simple collection
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x34 begCollection value-tag beginning of the "media-
+ size" collection attribute
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 26]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x000A name- length of (collection)
+ length attribute name
+
+ media-size media-size name name of (collection)
+ attribute
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+ 0x4A memberAttrName value-tag starts member attribute:
+ "x-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of "x-dimension"
+ length keyword
+
+ x-dimension x-dimension value name of 1st collection
+ member attribute
+
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0006 value value of 1st collection
+ member attribute
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 27]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x4A memberAttrName value-tag starts a new member
+ attribute: "y-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of the "y-
+ length dimension" keyword
+
+ y-dimension y-dimension value name of 2nd collection
+ member attribute
+
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf for
+ length media-size
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0004 value value of 2nd collection
+ member attribute
+
+
+ 0x37 endCollection value-tag end of the collection
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 28]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ no value (since value-
+ length was 0)
+
+
+
+
+
+15 Appendix B: Encoding Example of 1setOf Collection
+
+ The overall structure of the collection value can be pictorially
+ represented as:
+
+ "media-size-supported" =
+ { "x-dimension" = 6;
+ "y-dimension" = 4
+ },
+ { "x-dimension" = 3;
+ "y-dimension" = 5
+ };
+
+ A simplified view of the encoding would look like this:
+
+
+ Table 8 - Overview Encoding of 1setOf collection
+
+
+
+ Tag Value Name Value
+
+
+ begCollection media-size- ""
+ supported
+
+ memberAttrName "" x-dimension
+
+ integer "" 6
+
+ memberAttrName "" y-dimension
+
+ integer "" 4
+
+ endCollection "" ""
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 29]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+ begCollection "" ""
+
+ memberAttrName "" x-dimension
+
+ integer "" 3
+
+ memberAttrName "" y-dimension
+
+ integer "" 5
+
+ endCollection "" ""
+
+
+
+
+ Table 9 - Example Encoding of 1setOf collection
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x34 begCollection value-tag beginning of the "media-
+ size-supported (1setOf
+ collection" attribute
+
+ 0x00014 name- length of (collection)
+ length attribute name
+
+ media-size- media-size- name name of (collection)
+ supported supported attribute
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+ 0x4A memberAttrName value-tag starts member attribute:
+ "x-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 30]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x000B value- length of "x-dimension"
+ length keyword
+
+ x-dimension x-dimension value name of 1st collection
+ member attribute
+
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0006 value value of 1st collection
+ member attribute
+
+ 0x4A memberAttrName value-tag starts member attribute:
+ "y-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of the "y-
+ length dimension" keyword
+
+ y-dimension y-dimension value name of 2nd collection
+ member attribute
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 31]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0004 value value of 2nd collection
+ member attribute
+
+ 0x37 endCollection value-tag end of the collection
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+ 0x34 begCollection value-tag beginning of the 2nd
+ member of the 1SetOf
+ "sizes-avail " collection
+ attribute
+
+ 0x0000 name- Zero length name indicates
+ length this is member of previous
+ attribute
+
+ name no name (since name-length
+ was 0)
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+ 0x4A memberAttrName value-tag starts member attribute:
+ "x-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 32]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of "x-dimension"
+ length keyword
+
+ x-dimension x-dimension value name of 1st collection
+ member attribute
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0003 value value of 1st collection
+ member attribute
+
+ 0x4A memberAttrName value-tag starts member attribute:
+ "y-dimension"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x000B value- length of the "y-
+ length dimension" keyword
+
+ y-dimension y-dimension value name of 2nd collection
+ member attribute
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 33]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0005 value value of 2nd collection
+ member attribute
+
+ 0x37 endCollection value-tag end of the 1setOf
+ collection value
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+
+
+
+
+16 Appendix C: Encoding Example of Collection containing 1setOf XXX
+ attribute
+
+ The overall structure of the collection value can be pictorially
+ represented as:
+
+ "wagons" =
+ { "colors" = red, blue;
+ "sizes" = 4, 6, 8
+ }
+
+ A simplified view of the encoding would look like this:
+
+ Table 10 - Overview Encoding of collection with 1setOf value
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 34]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Tag Value Name Value
+
+
+ begCollection wagons ""
+
+ memberAttrName "" colors
+
+ keyword "" red
+
+ keyword "" blue
+
+ memberAttrName "" sizes
+
+ integer "" 4
+
+ integer "" 6
+
+ integer "" 8
+
+ endCollection "" ""
+
+
+
+
+ Table 11 - Example Encoding of collection with 1setOf value
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x34 begCollection value-tag beginning of the "wagons"
+ collection attribute
+
+ 0x0005 name- length of (collection)
+ length attribute name
+
+ wagons wagons name name of (collection)
+ attribute
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 35]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x4A memberAttrName value-tag starts a new member
+ attribute: "colors"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0006 value- length of "colors" keyword
+ length
+
+ colors colosr value value is name of 1st
+ member attribute
+
+ 0x44 keyword type value-tag keyword type
+
+ 0x0000 name- 0 indicates 1setOf wagons
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value-
+ length
+
+ blue blue value value of 1st member
+ attribute
+
+ 0x44 keyword type value-tag keyword type
+
+ 0x0000 name- 0 indicates 1setOf wagons
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0003 value-
+ length
+
+ red red value value of 1st member
+ attribute
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 36]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x4A memberAttrName value-tag starts a new member
+ attribute: "sizes"
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0005 value- length of "length-avail"
+ length keyword
+
+ sizes sizes value Name of 2nd member
+ attribute
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf wagons
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0004 value 1st value for 1SetOf
+ integer attribute
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0006 value 2nd value for 1SetOf
+ integer attribute
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 37]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+
+
+ Octets Symbolic Value Protocol comments
+ field
+
+
+ 0x21 integer type value-tag attribute type
+
+ 0x0000 name- 0 indicates 1setOf
+ length
+
+ no name (since name-length
+ was 0)
+
+ 0x0004 value- length of an integer = 4
+ length
+
+ 0x0008 value 3rd value for 1SetOf
+ integer attribute
+
+ 0x37 endCollection value-tag end of the collection
+
+ 0x0000 name- defined to be 0 for this
+ length type, so part of 1setOf
+
+ no name (since name-length
+ was 0)
+
+ 0x0000 value- defined to be 0 for this
+ length type
+
+ no value (since value-
+ length was 0)
+
+
+
+
+
+17 Appendix D: Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998,1999,2000,2001). 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
+
+
+deBry, et al. Expires: July 24, 2001 [page 38]
+\f
+
+INTERNET-DRAFT IPP: The 'collection' attribute syntax Jan 24, 2001
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, et al. Expires: July 24, 2001 [page 39]
+++ /dev/null
-INTERNET-DRAFT
-draft-ietf-ipp-implementers-guide-v11-01.txt
- T. Hastings
- Xerox Corporation
- C. Manros
- Xerox Corporation
- C. Kugler
- IBM Printing Systems Co
- H. Holst
- i-data Printing Systems
- P. Zehler
- Xerox Corporation
- May 30, 2000
-
-
- Internet Printing Protocol/1.1: Implementer's Guide
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-
-
-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 [IPP-MOD] and
-the IPP Transport and Encoding [IPP-PRO] documents. It is intended to
-
-Hastings, Manros, Kugler, Holst, Zehler [page 1]
-
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-help implementers understand IPP/1.1, as well as 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 2]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.1: Model and Semantics [IPP-MOD]
- Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
- 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 goal document calls out a subset of end user
-requirements that are satisfied in IPP/1.1. Operator and administrator
-requirements are out of scope for version 1.1.
-
-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.1: 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.1: 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.
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 3]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- TABLE OF CONTENTS
-
-1 INTRODUCTION.......................................................8
-
- 1.1 Conformance language.............................................8
- 1.2 Other terminology................................................9
- 1.3 Issues Raised from Interoperability Bake Offs....................9
-
-2 IPP OBJECTS........................................................9
-
-3 IPP OPERATIONS....................................................10
-
- 3.1 Common Semantics................................................10
- 3.1.1 Summary of Operation Attributes.............................10
- 3.1.2 Suggested Operation Processing Steps for IPP Objects........16
- 3.1.2.1 Suggested Operation Processing Steps for all Operations.17
- 3.1.2.1.1 Validate version number............................17
- 3.1.2.1.2 Validate operation identifier......................19
- 3.1.2.1.3 Validate the request identifier....................19
- 3.1.2.1.4 Validate attribute group and attribute presence and
- order 19
- 3.1.2.1.4.1 Validate the presence and order of attribute
- groups 19
- 3.1.2.1.4.2 Ignore unknown attribute groups in the expected
- position 20
- 3.1.2.1.4.3 Validate the presence of a single occurrence of
- required Operation attributes................................20
- 3.1.2.1.5 Validate the values of the REQUIRED Operation
- attributes 27
- 3.1.2.1.6 Validate the values of the OPTIONAL Operation
- attributes 31
- 3.1.2.2 Suggested Additional Processing Steps for Operations that
- Create/Validate Jobs and Add Documents..........................35
- 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...35
- 3.1.2.2.2 Check that the Printer object is accepting jobs....35
- 3.1.2.2.3 Validate the values of the Job Template attributes.36
- 3.1.2.3 Algorithm for job validation............................37
- 3.1.2.3.1 Check for conflicting Job Template attributes values42
- 3.1.2.3.2 Decide whether to REJECT the request...............43
- 3.1.2.3.3 For the Validate-Job operation, RETURN one of the
- success status codes...........................................44
- 3.1.2.3.4 Create the Job object with attributes to support...45
- 3.1.2.3.5 Return one of the success status codes.............46
- 3.1.2.3.6 Accept appended Document Content...................47
- 3.1.2.3.7 Scheduling and Starting to Process the Job.........47
- 3.1.2.3.8 Completing the Job.................................47
- 3.1.2.3.9 Destroying the Job after completion................47
- 3.1.2.3.10 Interaction with "ipp-attribute-fidelity"..........48
- 3.1.2.3.11 Character set code conversion support..............48
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 4]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 3.1.2.3.12 What charset to return when an unsupported charset is
- requested (Issue 1.19)?........................................49
- 3.1.2.3.13 Natural Language Override (NLO)....................50
- 3.1.3 Status codes returned by operation..........................52
- 3.1.3.1 Printer Operations......................................52
- 3.1.3.1.1 Print-Job..........................................52
- 3.1.3.1.2 Print-URI..........................................54
- 3.1.3.1.3 Validate-Job.......................................54
- 3.1.3.1.4 Create-Job.........................................55
- 3.1.3.1.5 Get-Printer-Attributes.............................55
- 3.1.3.1.6 Get-Jobs...........................................56
- 3.1.3.1.7 Pause-Printer......................................57
- 3.1.3.1.8 Resume-Printer.....................................57
- 3.1.3.1.8.1 What about Printers unable to change state due to
- an error condition?..........................................58
- 3.1.3.1.8.2 How is 'printer-state' handled on Resume-Printer?58
- 3.1.3.1.9 Purge-Printer......................................59
- 3.1.3.2 Job Operations..........................................59
- 3.1.3.2.1 Send-Document......................................59
- 3.1.3.2.2 Send-URI...........................................60
- 3.1.3.2.3 Cancel-Job.........................................60
- 3.1.3.2.4 Get-Job-Attributes.................................61
- 3.1.3.2.5 Hold-Job...........................................62
- 3.1.3.2.6 Release-Job........................................63
- 3.1.3.2.7 Restart-Job........................................63
- 3.1.3.2.7.1 Can documents be added to a restarted job?.......63
- 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
- 1.18) 63
- 3.1.5 Sending empty attribute groups..............................64
- 3.2 Printer Operations..............................................64
- 3.2.1 Print-Job operation.........................................64
- 3.2.1.1 Flow controlling the data portion of a Print-Job request
- (Issue 1.22)....................................................64
- 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)..65
- 3.2.2 Get-Printer-Attributes operation............................66
- 3.2.3 Get-Jobs operation..........................................66
- 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
- (Issue 1.39)?...................................................66
- 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
- operation?......................................................66
- 3.2.4 Create-Job operation........................................67
- 3.3 Job Operations..................................................67
- 3.3.1 Validate-Job................................................67
- 3.3.2 Restart-Job.................................................67
-
-4 OBJECT ATTRIBUTES.................................................68
-
- 4.1 Attribute Syntax's..............................................68
- 4.1.1 The 'none' value for empty sets (Issue 1.37)................68
-
-Hastings, Manros, Kugler, Holst, Zehler [page 5]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 4.1.2 Multi-valued attributes (Issue 1.31)........................68
- 4.1.3 Case Sensitivity in URIs (issue 1.6)........................69
- 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage...69
- 4.2 Job Template Attributes.........................................70
- 4.2.1 multiple-document-handling(type2 keyword)...................70
- 4.2.1.1 Support of multiple document jobs.......................70
- 4.3 Job Description Attributes......................................70
- 4.4 Printer Description Attributes..................................71
- 4.4.1 queued-job-count............................................71
- 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?.....71
- 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer
- is (Issue 1.15)?................................................71
- 4.4.2 printer-current-time (dateTime).............................71
- 4.4.3 'Printer-uri................................................72
- 4.5 Empty Jobs......................................................72
-
-5 DIRECTORY CONSIDERATIONS..........................................73
-
- 5.1 General Directory Schema Considerations.........................73
- 5.2 IPP Printer with a DNS name.....................................73
-
-6 SECURITY CONSIDERATIONS...........................................73
-
- 6.1 Querying jobs with IPP that were submitted using other job
- submission protocols (Issue 1.32)...................................73
-
-7 ENCODING AND TRANSPORT............................................74
-
- 7.1 General Headers.................................................76
- 7.2 Request Headers................................................77
- 7.3 Response Headers................................................78
- 7.4 Entity Headers.................................................79
- 7.5 Optional support for HTTP/1.0...................................80
- 7.6 HTTP/1.1 Chunking...............................................80
- 7.6.1 Disabling IPP Server Response Chunking......................80
- 7.6.2 Warning About the Support of Chunked Requests...............80
-
-8 REFERENCES........................................................81
-
-9 AUTHORS' ADDRESS..................................................82
-
-10 NOTICES..........................................................83
-
-
- TABLES
-
-
-Table 1 - Summary of Printer operation attributes that sender MUST
- supply............................................................10
-
-Table 2 - Summary of Printer operation attributes that sender MAY supply
- .................................................................11
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 6]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-Table 3 - Summary of Job operation attributes that sender MUST supply13
-
-Table 4 - Summary of Job operation attributes that sender MAY supply.14
-
-Table 5 - Printer operation response attributes......................15
-
-Table 6 - Examples of validating IPP version.........................18
-
-Table 7 - Rules for validating single values X against Z.............37
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 7]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-
-
-
-
-1 Introduction
-
-The IPP Implementer's Guide (IIG) (this document) contains information
-that supplements the IPP Model and Semantics [IPP-MOD] and the IPP
-Transport and Encoding [IPP-PRO] 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 [IPP-MOD] or [IPP-PRO], those documents take precedence over this
-document.
-
-Platform-specific implementation considerations will be included in this
-guide as they become known.
-
-In order to help the reader of the IIG and the IPP Model and Semantics
-document, the sections in this document parallel the corresponding
-sections in the Model document and are numbered the same for ease of
-cross reference. The sections that correspond to the IPP Transport and
-Encoding are correspondingly offset.
-
-
-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 [IPP-MOD] and [IPP-PRO] documents require and allow, rather
-than specifying additional conformance requirements. These terms are
-defined in section 13 on conformance terminology in [IPP-MOD], most of
-which is taken from RFC 2119 [RFC2119].
-
-Implementers should read section 13 (APPENDIX A) in [IPP-MOD] 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 [IPP-MOD] and [IPP-
-PRO]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed as an
-implementer option. The verbs SHOULD and SHOULD NOT indicate suggested
-behavior, but which is not required or disallowed, respectively, in
-order to conform to the specification.
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 8]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-1.3 Issues Raised from Interoperability Bake Offs
-
-
-The IPP WG has conducted two open interoperability "Bake Offs". The
-first bake off was held in September 1998 and Bake Off2 was held in
-March 1999. See the summary reports in:
-
-ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
-
-The issues raised from the first bake off are numbered 1.n in this
-document and are described in:
-
-ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/ipp-agreed-fixes-
-981030.pdf
-
-These issue resolutions have been incorporated into the November 16,
-"IPP/1.0 Model and Semantics" [ipp-mod] and the "IPP/1.0 Encoding and
-Transport" [IPP-PRO] documents. However, some of the discussion is left
-here in the Implementer's Guide to help understanding.
-
-The issues raised from Bake Off2 are numbered 2.n in this document and
-are described in:
-
-ftp://ftp.pwg.org/pub/pwg/ipp/issues/issues-raised-at-bake-off2.pdf
-
-
-2 IPP Objects
-
-The term "client" in IPP is intended to mean any client that issues IPP
-operation requests and accepts IPP operation responses, whether it be a
-desktop or a server. In other words, the term "client" does not just
-mean end-user clients, such as those associated with desktops.
-
-The term "IPP Printer" in IPP is intended to mean an object that accepts
-IPP operation requests and returns IPP operation responses, whether
-implemented in a server or a device. An IPP Printer object MAY, if
-implemented in a server, turn around and forward received jobs (and
-other requests) to other devices and print servers/services, either
-using IPP or some other protocol.
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 9]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-3 IPP Operations
-
-This section corresponds to Section 3 "IPP Operations" in the IPP/1.1
-Model and Semantics document [IPP-MOD].
-
-
-3.1 Common Semantics
-
-
-This section discusses semantics common to all operations.
-
-
-3.1.1 Summary of Operation Attributes
-
-Legend for the following table:
-
-R indicates a REQUIRED operation that MUST be supported by the IPP
-object (Printer or Job). For attributes, R indicates that the attribute
-MUST be supported by the IPP object supports the associated operation.
-
-O indicates an OPTIONAL operation or attribute that MAY be supported by
-the IPP object (Printer or Job).
-
-+ indicates that this is not an IPP/1.0 feature, but is only a part of
-IPP/1.1 and future versions of IPP.
-
- Table 1 - Summary of Printer operation attributes that sender MUST
- supply
-
- Printer Operations
- Requests Respo
- nses
- Operation Print- Pri Crea Get- Get Pause- All
- Attributes Job, nt- te- Printer- - Printer Opera
- Validate URI Job Attribut Job , tions
- -Job (R) (O) (O) es (R) s Resume-
- (R) Printer
- ,
- Purge-
- Printer
- (O+)
- Operation parameters--REQUIRED to be supplied by the sender:
- operation-id R R R R R R
- status-code R
- request-id R R R R R R R
- version-number R R R R R R R
- Operation attributes--REQUIRED to be supplied by the sender:
- attributes-charset R R R R R R R
- attributes- R R R R R R R
- natural-language
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 10]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- Printer Operations
- Requests Respo
- nses
- Operation Print- Pri Crea Get- Get Pause- All
- Attributes Job, nt- te- Printer- - Printer Opera
- Validate URI Job Attribut Job , tions
- -Job (R) (O) (O) es (R) s Resume-
- (R) Printer
- ,
- Purge-
- Printer
- (O+)
- document-uri R
- job-id*
- job-uri*
- last-document
- printer-uri R 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 R
- name
-
-
-
-Table 2 - Summary of Printer operation attributes that sender MAY supply
-
- Printer Operations
- Requests Respo
- nses
-Operation Attributes Print- Prin Crea Get- Get Pause- All
- Job, t- te- Printer - Printer Opera
- Valida URI Job - Job , tions
- te-Job (O) (O) Attribu s Resume-
- (R) tes (R) (R) Printer
- ,
- Purge-
- Printer
- (O+)
-Operation attributes--OPTIONAL to be supplied by the sender:
-status-message O
-detailed-status- O
-message
-document-access- O**
-error
-compression O O
-document-format R R R
-document-name O O
-document-natural- O O
-language
-
-Hastings, Manros, Kugler, Holst, Zehler [page 11]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- Printer Operations
- Requests Respo
- nses
-Operation Attributes Print- Prin Crea Get- Get Pause- All
- Job, t- te- Printer - Printer Opera
- Valida URI Job - Job , tions
- te-Job (O) (O) Attribu s Resume-
- (R) tes (R) (R) Printer
- ,
- Purge-
- Printer
- (O+)
-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-attributes R R
-which-jobs R
-
-* "job-id" is REQUIRED only if used together with "printer-uri" to
-identify the target job; otherwise, "job-uri" is REQUIRED.
-** "document-access-error" applies to the Print-URI response only.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 12]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-
-
- Table 3 - Summary of Job operation attributes that sender MUST supply
-
- Job Operations
- Requests Respons
- es
-Operation Attributes Send- Send Cance Get- Hold- All
- Docume -URI l-Job Job- Job, Operati
- nt (O) (R) Attrib Release ons
- (O) utes -Job,
- (R) Restart
- -Job
- (O+)
-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-natural- R R R R R R
-language
-document-uri R
-job-id* R R R R R
-job-uri* R R R R R
-last-document R R
-printer-uri R R R R R
-Operation attributes--RECOMMENDED to be supplied by the sender:
-job-name
-requesting-user-name R R R R R
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 13]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-
- Table 4 - Summary of Job operation attributes that sender MAY supply
-
- Job Operations
- Requests Respo
- nses
-Operation Attributes Send- Sen Cance Get- Hold- Relea All
- Documen d- l-Job Job- Job, se- Opera
- t URI (R) Attrib Restar Job tions
- (O) (O) utes t-Job (O+)
- (R) (O+)
-Operation attributes--OPTIONAL to be supplied by the sender:
-status-message O
-detailed-status- O
-message
-document-access-error 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 O O
-job-hold-until R
-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.
-** "document-access-error" applies to the Send-URI operation only.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 14]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-
-
- Table 5 - Printer operation response attributes
-
- Printer Operations
- Response
- Operation Print- Validat Prin Create Get- Get- Pause-
- Attributes Job e-Job t- -Job Printe Jobs Printer
- (R),Send (R) URI (O) r- (R) ,
- - (O), Attrib Resume-
- Document Send utes Printer
- (O) -URI (R) ,
- (O) Purge-
- Printer
- (O+)
- job-uri R R R
- job-id R R R
- job-state R R R
- job-state- R+ R+ R+
- reasons
- number-of- O O O
- intervening-
- jobs
- document- O
- access-error+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 15]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-
-
-3.1.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.
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 16]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-3.1.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.
-
-IIG Sect # Flow IPP error status codes
----------- ---- ----------------------
- |
- v err
-3.1.2.1.1 <Validate version> --> server-error-version-not-supported
- ok|
- v err
-3.1.2.1.2 <Validate operation> --> server-error-operation-not-supported
- ok|
- v err
-3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
-3.1.2.1.4.2 <of attributes>
- ok|
- v err
-3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
- <of operation attr>
- ok|
- v err
-3.1.2.1.5 <Valied values of> --> client-error-bad-request
- <operation attrs> client-error-request-value-too-long
- <(length, tag, range,>
- <multi-value)>
- ok|
- v err
-3.1.2.1.5 <Validate values> --> client-error-bad-request
- <with supported values> client-error-charset-not-supported
- ok| client-error-attributes-or-values-
- | not-supported
- v err
-3.1.2.1.6 <Validate optionally> --> client-error-bad-request
- <operation attr> client-error-natural-language-not-
- ok| supported
- | client-error-request-value-too-long
- | client-error-attributes-or-values-
- v not-supported
-
-
-3.1.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
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 17]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 major version number matches, but the minor version number does
-not, the Printer SHOULD accept and attempt to process the request, or
-MAY reject the request and return the 'server-error-version-not-
-supported' status code. In all cases, the Printer MUST return the
-nearest version number that it supports. For example, suppose that an
-IPP/1.2 Printer supports versions '1.1' and '1.2'. The following
-responses are conforming:
-
-
-Table 6 - Examples of validating IPP version
-
- Client Printer Accept Request? Printer returns
- supplies
-
- 1.0 yes (SHOULD) 1.1
-
- no (SHOULD NOT) 1.1
-
- 1.1 yes (MUST) 1.1
-
- 1.2 yes (MUST) 1.2
-
- 1.3 yes (SHOULD) 1.2
-
- no (SHOULD NOT) 1.2
-
-
-
-It is advantageous for Printers to support both IPP/1.1 and IPP/1.0, so
-that they can interoperate with either client implementations. Some
-implementations may allow an Administrator to explicitly disable support
-for one or the other by setting the "ipp-versions-supported" Printer
-description attribute.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 18]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-Likewise, it is advantageous for clients to support both versions to
-allow interoperability with new and legacy Printers.
-
-
-3.1.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.
-
-
-3.1.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.1 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.
-
-
-3.1.2.1.4 Validate attribute group and attribute presence and order
-
-The order of the following validation steps depends on implementation.
-
-
-3.1.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.
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 19]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-3.1.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.
-
-
-3.1.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 [IPP-MOD] 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:
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 20]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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
-[IPP-MOD] 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 or operation that an IPP object MUST
- support
- O indicates an OPTIONAL attribute or operation 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.
- + indicates that this is not a IPP/1.0 operation, but is only a part
- of IPP/1.1 and future versions of IPP.
-
- Operation Requests
-
-Hastings, Manros, Kugler, Holst, Zehler [page 21]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 (R):
- 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 [IPP-MOD] Section 4.2)
- Group 3: Document Content (R)
- <document content>
-
-Validate-Job Request (R):
- 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 [IPP-MOD] Section 4.2)
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 22]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-Print-URI Request (O):
- 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 [IPP-MOD] Section 4.2)
-
-Create-Job Request (O):
- 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 [IPP-MOD] Section 4.2)
-
-Get-Printer-Attributes Request (R):
- 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-Jobs Request (R):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
-
-Hastings, Manros, Kugler, Holst, Zehler [page 23]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- printer-uri (R)
- requesting-user-name (R*)
- limit (R*)
- requested-attributes (R*)
- which-jobs (R*)
- my-jobs (R*)
-
-Send-Document Request (O):
- 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 (O):
- 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 (R):
-Release-Job Request (O+):
- 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-Job-Attributes Request (R):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- (printer-uri & job-id) | job-uri (R)
-
-Hastings, Manros, Kugler, Holst, Zehler [page 24]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- requesting-user-name (R*)
- requested-attributes (R*)
-
-Pause-Printer Request (O+):
-Resume-Printer Request (O+):
-Purge-Printer Request (O+):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- printer-uri (R)
- requesting-user-name (R*)
-
-Hold-Job Request (O+):
-Restart-Job Request (O+):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- (printer-uri & job-id) | job-uri (R)
- requesting-user-name (R*)
- job-hold-until (R*)
- message (O*)
-
-
- 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 (R):
-Create-Job Response (O):
-Send-Document Response (O):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- status-message (O*)
- detailed-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* | R+)
- job-state-message (O*)
- number-of-intervening-jobs (O*)
-
-Hastings, Manros, Kugler, Holst, Zehler [page 25]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-
-Validate-Job Response (R):
-Cancel-Job Response (R):
-Hold-Job Response (O+):
-Release-Job Response (O+):
-Restart-Job Response (O+):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- status-message (O*)
- detailed-status-message (O*)
- Group 2: Unsupported Attributes (R*) (see Note 3)
- <unsupported attributes> (R*)
-
-Print-URI Response (O):
-Send-URI Response (O):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- status-message (O*)
- detailed-status-message (O*)
- document-access-error (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* | R+)
- job-state-message (O*)
- number-of-intervening-jobs (O*)
-
-Get-Printer-Attributes Response (R):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- status-message (O*)
- detailed-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*)
-
-Get-Jobs Response (R):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- status-message (O*)
-
-Hastings, Manros, Kugler, Holst, Zehler [page 26]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- detailed-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*)
-
-Get-Job-Attributes Response (R):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- status-message (O*)
- detailed-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*)
-
-Pause-Printer Response (O+):
-Resume-Printer Response (O+):
-Purge-Printer Response (O+):
- Group 1: Operation Attributes (R)
- attributes-charset (R)
- attributes-natural-language (R)
- status-message (O*)
- detailed-status-message (O*)
- Group 2: Unsupported Attributes (R*) (see Note 4)
- <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.
-
-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.
-
-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.
-
-
-3.1.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
-
-Hastings, Manros, Kugler, Holst, Zehler [page 27]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 [IPP-
- MOD] Section 4.1,
-
-b) that the attribute syntax tag is correct for that Operation
-attribute according to [IPP-MOD] Section 3,
-
-c) that the value is in the range specified for that Operation
-attribute according to [IPP-MOD] 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 [IPP-MOD] 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'.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 28]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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'.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 29]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-
-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 the client-supplied URI scheme is not supported, i.e. the value
- is not in the Printer object's referenced-uri-scheme-
- supported" attribute, the Printer object MUST reject the
- request and return the 'client-error-uri-scheme-not-supported'
- status code. 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'.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 30]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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.
-
-
------------------------------------------------
-
-
-
-3.1.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
-
-Hastings, Manros, Kugler, Holst, Zehler [page 31]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-syntactic validation checks for each OPTIONAL attribute value as in
-Section 3.1.2.1.5. As in Section 3.1.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'.
- Note to IPP/1.0 implementers: Support for the "compression"
- attribute was optional in IPP/1.0 and was changed to REQUIRED
- in IPP/1.1. However, an IPP/1.0 object SHOULD at least check
- for the "compression" attribute being present and reject the
- create request, if they don't support "compression". Not
- checking is a bug, since the data will be unintelligible.
-
-job-k-octets (integer(0:MAX))
- IF NOT a single 'integer' value equal to 4 octets,
-
-Hastings, Manros, Kugler, Holst, Zehler [page 32]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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
-
-Hastings, Manros, Kugler, Holst, Zehler [page 33]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 34]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-3.1.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.
-
-IIG Sect # Flow IPP error status codes
----------- ---- ----------------------
- |
- v No
-3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
- <supplied?> |
- Yes| |
- | ipp-attribute-fidelity = no |
- |<------------------------------+
- v No
-3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
- <accepting jobs?>
- Yes|
- v err
-3.1.2.3 <Validate values of> --> client-error-bad-request
- <Job template attributes> client-error-request-value-too-long
- <(length, tag, range,>
- <multi-value)>
- ok|
- v err
-3.1.2.3 <Validate values with> --> client-error-bad-request
- <supported values> client-error-attributes-or-values-
- ok| not-supported
- v err
-3.1.2.3.1 <Any conflicting> --> client-error-conflicting-attributes
- <Job Template attr values> client-error-attributes-or-values-
- ok| not-supported
- v
-
-3.1.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'.
-
-
-3.1.2.2.2 Check that the Printer object is accepting jobs
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 35]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-If the value of the Printer objects "printer-is-accepting-jobs" is
-'false', the Printer object REJECTS the request and RETURNS the 'server-
-error-not-accepting-jobs' status code.
-
-
-3.1.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 3.1.2.1.5.):
-
-
- a) that the length of each value is correct for the attribute
- syntax tag supplied by the client according to [IPP-MOD] Section 4.1.
-
- b) that the attribute syntax tag is correct for that attribute
- according to [IPP-MOD] 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 [IPP-MOD] Sections
- 4.2 to 4.4.
-
-As in Section 3.1.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-request'
- 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
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 36]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-depending on implementation. Therefore, clients MUST NOT supply
-multiple occurrences of the same Job Template attribute in the Job
-Attributes group in the request.
-
-
-3.1.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 [ipp-mod]).
-
-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 7 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 7 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 7.
-
-Table 7 - 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.
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 37]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 [IPP-MOD] 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 [IPP-MOD] Section 4.2.1.
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 38]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 39]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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'.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 40]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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
-
-Hastings, Manros, Kugler, Holst, Zehler [page 41]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
------------ --------------------------------------------
-'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'
-
-
-Note: It's possible for a Printer to receive a zero length keyword in a
-request. Since this is a keyword, its value needs to be compared with
-the supported values. Assuming that the printer doesn't have any values
-in its corresponding "xxx-supported" attribute that are keywords of zero
-length, the comparison will fail. Then the request will be accepted or
-rejected depending on the value of "ipp-attributes-fidelity" being
-'false' or 'true', respectively. No special handling is required for
-
-
-3.1.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
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 42]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-3.1.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.
-
-In general, the final results of Job processing are unknown at Job
-submission time. The client has to rely on notifications or polling to
-find out what happens at Job processing time. However, there are cases
-in which some Printers can determine at Job submission time that Job
-processing is going to fail. As an optimization, we'd like to have the
-Printer reject the Job in these cases.
-
-There are three types of "processing" errors that might be detectable at
-Job submission time:
-
-1. 'client-error-document-format-not-supported' : For the Print-Job,
-Send-Document, Print-URI, and Send-URI operations, if all these
-conditions are true:
-
- - the Printer supports auto-sensing,
- - the request "document-format" operation attribute is
- 'application/octet-stream',
- - the Printer receives document data before responding,
- - the Printer auto-senses the document format before responding,
- - the sensed document format is not supported by the Printer
-then the Printer should respond with 'client-error-document-format-not-
-supported' status.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 43]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-2. 'client-error-compression-error': For the Print-Job, Send-Document,
-Print-URI, and Send-URI operations, if all these conditions are true:
-
- - the client supplies a supported value for the "compression"
- operation attribute in the request
- - the Printer receives document data before responding,
- - the Printer attempts to decompress the document data before
- responding,
- - the document data cannot be decompressed using the algorithm
- specified by the "compression" operation attribute
-then the Printer should respond with 'client-error-compression-error'
-status.
-
-3. 'client-error-document-access-error': For the Print-URI, and Send-
-URI operations, if the Printer attempts and fails to pull the referenced
-document data before responding, it should respond with 'client-error-
-document-access-error' status.
-
-Some Printers are not able to detect these errors until Job processing
-time. In that case, the errors are recorded in the corresponding job-
-state and job-state reason attributes. (There is no standard way for a
-client to determine whether a Printer can detect these errors at Job
-submission time.) For example, if auto-sensing happens AFTER the job is
-accepted (as opposed to auto-sensing at submit time before returning the
-response), the implementation aborts the job, puts the job in the
-'aborted' state and sets the 'unsupported-document-format' value in the
-job's "job-state-reasons".
-
-A client should always provide a valid "document-format" operation
-attribute whenever practical. In the absence of other information, a
-client itself may sniff the document data to determine document format.
-
-Auto sensing at Job submission time may be more difficult for the
-Printer when combined with compression. For auto-sensed Jobs, a client
-may be better off deferring compression to the transfer protocol layer,
-e.g.; by using the HTTP Content-Encoding header.
-
-
-3.1.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.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 44]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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.
-
-
-3.1.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-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 45]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-3.1.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.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 46]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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, [IPP-MOD] section 3.2.1.2.
-
-
-3.1.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.
-
-
-3.1.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.
-
-
-3.1.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.
-
-
-3.1.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
-
-Hastings, Manros, Kugler, Holst, Zehler [page 47]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-3.1.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". Character Sets, natural languages,
-and internationalization
-
-This section discusses character set support, natural language support
-and internationalization.
-
-
-3.1.2.3.11 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?
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 48]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 IPP-Mod 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.
-
-
-3.1.2.3.12 What charset to return when an unsupported charset is
- requested (Issue 1.19)?
-
-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
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 49]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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, [ipp-mod] 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).
-
-
-3.1.2.3.13 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 'textWithLanguage' 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.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 50]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 [IPP-MOD] 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.
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 51]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-3.1.3 Status codes returned by operation
-
-This section corresponds to [IPP-MOD] section 3.1.6 "Operation Response
-Status Codes and Status Messages". 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.
-
-
-3.1.3.1 Printer Operations
-
-
-3.1.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 13 in [IPP-MOD] 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 syntax's, 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.
-
-
-[ipp-mod] 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 13 in [IPP-MOD]):
-'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.
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 52]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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
- syntax's, exceed the maximum length specified in [IPP-MOD] 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 syntax's, 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,
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 53]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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
- 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.
-
-3.1.3.1.2 Print-URI
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 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.
-
- client-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.
- server-error-operation-not-supported: the Print-URI operation is not
- supported.
-
-
-3.1.3.1.3 Validate-Job
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 54]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to Validate-Job. See Section 13 in [IPP-
-MOD] for a more complete description of each status code.
-
-
-3.1.3.1.4 Create-Job
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to Create-Job with the following
-specializations and differences. See Section 13 in [IPP-MOD] for a more
-complete description of each status code.
-
- server-error-operation-not-supported: the Create-Job operation is
- not supported.
- client-error-multiple-document-jobs-not-supported: while the Create-
- Job and Send-Document operations are supported, this implementation
- doesn't support more than one document with data.
-
-3.1.3.1.5 Get-Printer-Attributes
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to the Get-Printer-Attributes operation with
-the following specialization's and differences. See Section 13 in
-[IPP-MOD] 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).
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 55]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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..
-
-3.1.3.1.6 Get-Jobs
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to the Get-Jobs operation with the following
-specialization's and differences. See Section 13 in [IPP-MOD] 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.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 56]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- server-error-job-canceled: not applicable.
-
-3.1.3.1.7 Pause-Printer
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to Pause-Printer with the following
-specializations and differences. See Section 13 in [IPP-MOD] for a more
-complete description of each status code.
-
-For the following success status codes, the Printer object is being
-stopped from scheduling jobs on all its devices.
-
- 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 Printer object has not been
-stopped from scheduling jobs on all its devices.
-
- client-error-not-possible: not applicable.
- client-error-not-found: the target Printer object does not exist.
- client-error-gone: the target Printer 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-conflicting-attributes: same as Print-Job, except that
- the Printer's "printer-is-accepting-jobs" attribute is not
- involved.
- server-error-operation-not-supported: the Pause-Printer operation is
- not supported.
- server-error-device-error: not applicable.
- 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.
-
-3.1.3.1.8 Resume-Printer
-
-
-All of the Print-Job status code descriptions in Section 3.1.3.1.1
-Print-Job Response with the specialization's described for Pause-Printer
-are applicable to Resume-Printer. See Section 13 in [IPP-MOD] for a
-more complete description of each status code.
-
-For the following success status codes, the Printer object resumes
-scheduling jobs on all its devices.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 57]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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 Printer object does not resume
-scheduling jobs.
-
- server-error-operation-not-supported: the Resume-Printer operation is
- not supported.
-
-
-3.1.3.1.8.1 What about Printers unable to change state due to an error
- condition?
-
-If, in case, the IPP printer is unable to change its state due to some
-problem with the actual printer device (say, it is shut down or there is
-a media-jam as indicated in [ipp-mod]), what should be the result of the
-"Resume-printer" operation? Should it still change the 'printer-state-
-reasons' and return success or should it fail ?
-
-The 'resume-printer' operation must clear the 'paused' or 'moving-to-
-paused' 'printer-state-message'. The operation must return a
-'successful-ok' status code.
-
-
-3.1.3.1.8.2 How is 'printer-state' handled on Resume-Printer?
-
-
-
-If "Resume-Printer" succeeds, what should be the value of 'Printer-
-state' and who should take care of the 'Printer-state' later on ?
-
-The "Resume-Printer" operation may change the "printer-state-reasons"
-value.
-
-The "printer-state" will change to one of three states:
-
- 1. 'idle' - no additional jobs and no error conditions present
-
- 2. 'processing' - job available and no error conditions present
-
- 3. current state (i.e. no change) an error condition is present (e.g.
- media jam)
-
- In the third case the 'printer-state-reason' will be cleared by
-automata when it detects the error condition no longer exists. The
-'printer-state' will move to 'idle' or 'processing' when conditions
-permit. (i.e. no more error conditions)
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 58]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-3.1.3.1.9 Purge-Printer
-
-
-All of the Print-Job status code descriptions in Section 3.1.3.1.1
-Print-Job Response with the specialization's described for Pause-Printer
-are applicable to Purge-Printer. See Section 13 in [IPP-MOD] for a more
-complete description of each status code.
-
-For the following success status codes, the Printer object purges all
-it's jobs.
-
- 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 Printer object does not purge any
-jobs.
-
- server-error-operation-not-supported: the Purge-Printer operation is
- not supported.
-
-3.1.3.2 Job Operations
-
-
-3.1.3.2.1 Send-Document
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to the Get-Printer-Attributes operation with
-the following specialization's and differences. See Section 13 in
-[IPP-MOD] 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 job that was created
- with a Create-Job operation 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
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 59]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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.
-
-3.1.3.2.2 Send-URI
-
-
-All of the Print-Job status code descriptions in Section 3.1.3.1.1
-Print-Job Response with the specialization's described for Send-Document
-are applicable to Send-URI. See Section 13 in [IPP-MOD] for a more
-complete description of each status code.
-
- client-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.
- server-error-operation-not-supported: the Send-URI operation is not
- supported.
-
-
-3.1.3.2.3 Cancel-Job
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to Cancel-Job with the following
-specializations and differences. See Section 13 in [IPP-MOD] 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.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 60]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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.
-
-3.1.3.2.4 Get-Job-Attributes
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to Get-Job-Attributes with the following
-specializations and differences. See Section 13 in [IPP-MOD] 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.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 61]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 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.
-
-3.1.3.2.5 Hold-Job
-
-
-All of the Print-Job status codes described in Section 3.1.3.1.1 Print-
-Job Response are applicable to Hold-Job with the following
-specializations and differences. See Section 13 in [IPP-MOD] for a more
-complete description of each status code.
-
-For the following success status codes, the Job object is being held or
-has been held:
-
- 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 held or
-was previously held.
-
- 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-conflicting-attributes: same as Print-Job, except that
- the Printer's "printer-is-accepting-jobs" attribute is not
- involved.
- server-error-operation-not-supported: the Hold-Job operation is not
- supported.
- server-error-device-error: not applicable.
- 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.
-
-Hastings, Manros, Kugler, Holst, Zehler [page 62]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-3.1.3.2.6 Release-Job
-
-
-All of the Print-Job status code descriptions in Section 3.1.3.1.1
-Print-Job Response with the specialization's described for Hold-Job are
-applicable to Release-Job. See Section 13 in [IPP-MOD] for a more
-complete description of each status code.
-
- server-error-operation-not-supported: the Release-Job operation is
- not supported.
-
-3.1.3.2.7 Restart-Job
-
-
-All of the Print-Job status code descriptions in Section 3.1.3.1.1
-Print-Job Response with the specialization's described for Hold-Job are
-applicable to Restart-Job. See Section 13 in [IPP-MOD] for a more
-complete description of each status code.
-
- server-error-operation-not-supported: the Restart-Job operation is
- not supported.
-
-
-3.1.3.2.7.1 Can documents be added to a restarted job?
-
-Assume I give a Create-Job request along with a set of 5 documents . All
-the documents get printed and the job state is moved to completed . I
-issue a Restart-Job request on the job. Now the issue is that, if I try
-to add new documents to the restarted job, will the IPP Server permit
-me to do so or return "client-error-not-possible " and again print
-those 5 jobs?
-
-A job can not move to the 'completed' state until all the documents have
-been processed. The 'last-document' flag indicates when the last
-document for a job is being sent from the client. This is the semantic
-equivalent of closing a job. No documents may be added once a job is
-closed. Section 3.3.7 of the IPP/1.1 model states "The job is moved to
-the 'pending' job state and restarts the beginning on the same IPP
-Printer object with the same attribute values." 'number-of-documents' is
-a job attribute.
-
-
-
-
-3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
- 1.18)
-
-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,
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 63]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-3.1.5 Sending empty attribute groups
-
-The [IPP-MOD] and [IPP-PRO] 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 [IPP-PRO] 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. [IPP-PRO] 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.
-
-
-3.2 Printer Operations
-
-
-3.2.1 Print-Job operation
-
-
-3.2.1.1 Flow controlling the data portion of a Print-Job request
- (Issue 1.22)
-
-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
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 64]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
-
-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 jobs "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
-
-Hastings, Manros, Kugler, Holst, Zehler [page 65]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-
-3.2.2 Get-Printer-Attributes operation
-
-If a Printer supports the "printer-make-and-model" attribute and returns
-the .INF file model name of the printer in that attribute, the Microsoft
-client will automatically install the correct driver (if available).
-
-Clients which poll periodically for printer status or queued-job-count
-should use the "requested-attributes" operation attribute to limit the
-scope of the query in order to save Printer and network resources.
-
-
-3.2.3 Get-Jobs operation
-
-
-3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
- 1.39)?
-
-In [IPP-MOD] 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 too, and if it's not present what should the IPP
-printer do?
-
-[IPP-MOD] 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".
-
-
-3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
-
-When using the Get-Jobs operation a client implementer might choose to
-limit the number of jobs that the client shows on the first screenful.
-For example, if its UI can only display 50 jobs, it can defend itself
-against a printer that would otherwise return 500 jobs, perhaps taking a
-long time on a slow dial-up line. The client can then go and ask for a
-larger number of jobs in the background, while showing the user the
-first 50 jobs. Since the job history is returned in reverse order,
-namely the most recently completed jobs are returned first, the user is
-most likely interested in the first jobs that are returned. Limiting the
-number of jobs may be especially useful for a client that is requesting
-'completed' jobs from a printer that keeps a long job history. Clients
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 66]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-that don't mind sometimes getting very large responses, can omit the
-"limit" attribute in their Get-Jobs requests.
-
-
-3.2.4 Create-Job operation
-
-A Printer may respond to a Create-Job operation with "job-state"
-'pending' or 'pending-held' and " job-state-reason" 'job-data-
-insufficient' to indicate that operation has been accepted by the
-Printer, but the Printer is expecting additional document data before it
-can move the job into the 'processing' state. Alternatively, it may
-respond with "job-state" 'processing' and "job-state-reason" 'job-
-incoming' to indicate that the Create-Job operation has been accepted
-by the Printer, but the Printer is expecting additional Send-Document
-and/or Send-URI operations and/or is accessing/accepting document data.
-The second alternative is for non-spooling Printers that don't implement
-the 'pending' state.
-
-
-Should the server wait for the "last-document" operation attribute set
-to 'true' before starting to "process" the job?
-
-It depends on implementation. Some servers spool the entire job,
-including all document data, before starting to process, so such an
-implementation would wait for the "last-document" before starting to
-process the job. If the time-out occurs without the "last-document",
-then the server takes one of the indicated actions in section 3.3.1 in
-the [IPP-MOD] document. Other servers will start to process document
-data as soon as they have some. These are the so-called "non-spooling"
-printers. Currently, there isn't a way for a client to determine whether
-the Printer will spool all the data or will start to process (and print)
-as soon as it has some data.
-
-
-3.3 Job Operations
-
-
-3.3.1 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.
-
-
-3.3.2 Restart-Job
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 67]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-The Restart-Job operation allows the reprocessing of a completed job.
-Some jobs store the document data on the printer. Jobs created using
-the Print-Job operation are an example. It is required that the printer
-retains the job data after the job has moved to a 'completed state' in
-order for the Restart-Job operation to succeed.
-
-Some jobs contain only a reference to the job data. A job created using
-the Print-URI is an example of such a job. When the Restart-Job
-operation is issued the job is reprocessed. The job data MUST be
-retrieved again to print the job.
-
-It is possible that a job fails while attempting to access the print
-data. When such a job is the target of a Restart-Job the Printer SHALL
-attempt to retrieve the job data again.
-
-
-4 Object Attributes
-
-
-4.1 Attribute Syntax's
-
-
-4.1.1 The 'none' value for empty sets (Issue 1.37)
-
-[IPP-MOD] 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.
-
-
-4.1.2 Multi-valued attributes (Issue 1.31)
-
-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.
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 68]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-4.1.3 Case Sensitivity in URIs (issue 1.6)
-
-IPP client and server implementations must be aware of the diverse
-uppercase/lowercase nature of URIs. RFC 2396 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 RFC 2396 and the
-HTTP/1.1 specifications [RFC2616]. 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.
-
-Example of equivalent URI's
-
- http://abc.com:80/~smith/home.html
-
- http://ABC.com/%7Esmith/home.html
-
- http:/ABC.com:/%7esmith/home.html
-
-Example of equivalent URI's using the IPP scheme
-
- ipp://abc.com:631/~smith/home.html
-
- ipp://ABC.com/%7Esmith/home.html
-
- http:/ABC.com:631/%7esmith/home.html
-
-The HTTP/1.1 specification [RFC2616] contains more details on comparing
-URLs.
-
-
-4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage
-
-The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes that
-have two components. The first component is the 'language' component
-that can contain up to 63 octets. The second component is the 'text' or
-'name' component. The maximum length of these are 1023 octets and 255
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 69]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-octets respectively. The definition of attributes with either syntax
-may further restrict the length. (e.g. printer-name (name(127)))
-
-The length of the 'language' component has no effect on the allowable
-length of 'text' in 'textWithLanguage' or the length of 'name' in
-'nameWithLanguage'
-
-
-4.2 Job Template Attributes
-
-
-4.2.1 multiple-document-handling(type2 keyword)
-
-
-4.2.1.1 Support of multiple document jobs
-
-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" or multiple documents per job. IPP/1.1 was changed
-so that a Printer could support Create-Job without having to support
-multiple document jobs. The "multiple-document-jobs-supported"
-(boolean) Printer description attribute was added to IPP/1.1 along with
-the 'server-error-multiple-document-jobs-not-supported' status code for
-a Printer to indicate whether or not it supports multiple document jobs,
-when it supports the Create-Job operation. Also IPP/1.1 was clarified
-that the Printer MUST support the "multiple-document-handling" (type2
-keyword) Job Template attribute with at least one value if the Printer
-supports multiple documents per job.
-
-
-4.3 Job Description Attributes
-
-The time-at-creation, time-at-processing, and time-at-completed
-attributes may be returned in integer time ticks or absolute dateTime
-syntax. There are various ways for a Printer to get the time of day.
-Some suggestions:
-
- 1. A Printer can get time from an NTP timeserver if there's one
- reachable on the network . See RFC 1305. Also DHCP option 32 in
- RFC 2132 returns the IP address of the NTP server.
-
- 2. Get the date and time at startup from a human operator
-
- 3. Have an operator set the date and time using a web
- administrative interface
-
- 4. Get the date and time from incoming HTTP requests, though the
- problems of spoofing need to be considered. Perhaps comparing
- several HTTP requests could reduce the chances of spoofing.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 70]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 5. Internal date time clock battery driven.
-
- 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
-
-
-4.4 Printer Description Attributes
-
-
-4.4.1 queued-job-count
-
-
-4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?
-
-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.
-
-
-4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is
- (Issue 1.15)?
-
-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.
-
-
-4.4.2 printer-current-time (dateTime)
-
-A Printer implementation MAY support this attribute by obtaining the
-date and time by any number of implementation-dependent means at startup
-or subsequently. Examples include:
-
- 1. an internal date time clock,
-
- 2. from the operator at startup using the console,
-
- 3. from an operator using an administrative web page,
-
- 4. from HTTP headers supplied in client requests,
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 71]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
-
- 6. from the network, using NTP [RFC1305] or DHCP option 32 [RFC2132]
- that returns the IP address of the NTP server.
-
-If an implementation supports this attribute by obtaining the current
-time from the network (at startup or later), but the time is not
-available, then the implementation MUST return the value of this
-attribute using the out-of-band 'no-value' meaning not configured. See
-the beginning of section 4.1.
-
-Since the new "date-and-time-at-xxx" Job Description attributes refer to
-the "printer-current-time", they will be covered also.
-
-
-4.4.3 'Printer-uri
-
-Must the operational attribute for printer-uri match one of the values
-in printer-uri-supported?
-
-A forgiving printer implementation would not reject the operation. But
-the implementation has its rights to reject a printer or job operation
-if the operational attribute printer-uri is not a value of the printer-
-uri-supported. The printer may not be improperly configured. The request
-obviously reached the printer. The printer could treat the printer-uri
-as the logical equivalent of a value in the printer-uri-supported. It
-would be implementation dependent for which value, and associated
-security policy, would apply. This does also apply to a job object
-specified with a printer-uri and job-id, or with a job-uri. See section
-4.1.3 for how to compare URI's.
-
-
-4.5 Empty Jobs
-
-
-The IPP object model does not prohibit a job that contains no documents.
-Such a job may be created in a number of ways including a 'create-job'
-followed by an 'add-document' that contains no data and has the 'last-
-document' flag set.
-
-An empty job is processed just as any other job. The operation that
-"closes" an empty job is not rejected because the job is empty. If no
-other conditions exist, other than the job is empty, the response to the
-operation will indicate success. After the job is scheduled and
-processed, the job state SHALL be 'completed'
-
-There will be some variation in the value(s) of the 'job-state-reasons'
-attribute. It is required that if no conditions, other than the job
-being empty, exist the 'job-state-reasons' SHALL include the 'completed-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 72]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-successfully'. If other conditions existed, the 'completed-with-
-warnings' or 'completed-with-errors' values may be used."
-
-
-5 Directory Considerations
-
-
-5.1 General Directory Schema Considerations
-
-
-The [ipp-mod] document lists RECOMMENDED and OPTIONAL Printer object
-attributes for directory schemas. See [ipp-mod] APPENDIX E: Generic
-Directory Schema.
-
-The SLP printer template is defined in the "Definition of the Printer
-Abstract Service Type v2.0" document [svrloc-printer]. The LDAP printer
-template is defined in the "Internet Printing Protocol (IPP): LDAP
-Schema for Printer Services" document [ldap-printer]. Both documents
-systematically add "printer-" to any attribute that doesn't already
-start with "printer-" in order to keep the printer directory attributes
-distinct from other directory attributes. Also, instead of using
-"printer-uri-supported", "uri-authentication-supported", and "uri-
-security-supported", they use a "printer-xri-supported" attribute with
-special syntax to contain all of the same information in a single
-attribute.
-
-
-5.2 IPP Printer with a DNS name
-
-
-If the IPP printer has a DNS name should there be at least two values
-for the printer-uri-supported attribute. One URL with the fully
-qualified DNS name the other with the IP address in the URL?
-
-The printer may contain one or the other or both. It's up to the
-administrator to configure this attribute.
-
-
-6 Security Considerations
-
-This section corresponds to the IPP-MOD Section 8 "Security
-Considerations.
-
-
-6.1 Querying jobs with IPP that were submitted using other job
- submission protocols (Issue 1.32)
-
-
-The following clarification was added to [IPP-MOD] section 8.5:
-
- 8.5 Queries on jobs submitted using non-IPP protocols
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 73]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 were 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.
-
-
-7 Encoding and Transport
-
-This section discusses various aspects of IPP/1.1 Encoding and Transport
-[IPP-PRO].
-
-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.
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 74]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to
-throttle clients when Printers are busy. Therefore, it is perfectly
-normal for an IPP client transmitting a Job to be blocked for a really
-long time. Accordingly, socket timeouts must be avoided. Some socket
-implementations have a timeout option, which specifies how long a write
-operation on a socket can be blocked before it times out and the
-blocking ends. A client should set this option for infinite timeout
-when transmitting Job submissions.
-
-Some IPP client applications might be able to perform other useful work
-while a Job transmission is blocked. For example, the client may have
-other jobs that it could transmit to other Printers simultaneously. A
-client may have a GUI, which must remain responsive to the user while
-the Job transmission is blocked. These clients should be designed to
-spawn a thread to handle the Job transmission at its own pace, leaving
-the main application free to do other work. Alternatively, single-
-threaded applications could use non-blocking I/O.
-
-Some Printer conditions, such as jam or lack of paper, could cause a
-client to be blocked indefinitely. Clients may open additional
-connections to the Printer to Get-Printer-Attributes, determine the
-state of the device, alert a user if the printer is stopped, and let a
-user decide whether to abort the job transmission or not.
-
-In the following sections, there are 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,
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 75]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- - 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.
-
-7.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 RFC 1123 [RFC1123]
- from RFC 2616
- [RFC2616]
-
-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
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 76]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-General- Request Response V alues and Conditions
-Header
-
- Client Server Server Client
-
-Via not not not not
-
-
-7.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
- client omits it
-
-Accept-Charset not not Charset information is within
- the application/ipp entity
-
-Accept-Encoding may must empty and per RFC 2616 [RFC2616]
- and IANA registry for content-
- codings
-
-Accept-Language not not language information is within
- the application/ipp entity
-
-Authorization must-if must per RFC 2616. 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 RFC 2616. Because RFC
- recommends sending this header
- only with the user's approval, it
- is not very useful
-
-Host must must per RFC 2616
-
-If-Match not not
-
-If-Modified- not not
-Since
-
-If-None-Match not not
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 77]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-Request-Header Client Server Request Values and Conditions
-
-If-Range not not
-
-If-Unmodified- not not
-Since
-
-Max-Forwards not not
-
-Proxy- must-if not per RFC 2616. A client MUST send
-Authorization this header when it receives a
- 401 "Unauthorized" response and a
- "Proxy-Authenticate" header.
-
-Range not not
-
-Referrer not not
-
-User-Agent not not
-
-
-7.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 RFC 2616. When URI needs
- redirection.
-
-Proxy- not must per RFC 2616
-Authenticate
-
-Public may may per RFC 2616
-
-Retry-After may may per RFC 2616
-
-Server not not
-
-Vary not not
-
-Warning may may per RFC 2616
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 78]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-Response- Server Client Response Values and Conditions
-Header
-
-WWW- must-if must per RFC 2616. When a server needs to
-Authenticate authenticate a client.
-
-
-7.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 RFC 2616 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
- 2616. Header MUST be
- present if Transfer-
- Encoding is absent..
-
-Content- not not not not
-Location
-
-Content-MD5 may may may may per RFC 2616
-
-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
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 79]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-7.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 [IPP-PRO] 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.
-
-
-7.6 HTTP/1.1 Chunking
-
-
-7.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.
-
-
-7.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 [RFC2616] 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]
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 80]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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 [IPP-PRO] 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.
-
-
-8 References
-
-[CGI]
- CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11-
- 00.txt).
-
-[IPP-MOD]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", draft-ietf-
- ipp-model-v11-06.txt, March 1, 2000.
-
-[IPP-PRO]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.0: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 05.txt, March 1, 2000.
-
-[ldap-printer]
- Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing
- Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp-
- ldap-printer-schema-01.txt>, work in progress, April 27, 2000.
-
-[RFC793]
- J. Postel, "Transmission Control Protocol", RFC 793.
-
-[RFC1123]
- Braden, S., "Requirements for Internet Hosts - Application and
- Support", RFC 1123, October, 1989.
-
-[RFC2026]
- S. Bradner, "The Internet Standards Process -- Revision 3", RFC
- 2026, October 1996.
-
-[RFC2119]
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 81]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
- S. Bradner, "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119 , March 1997.
-
-[RFC2396]
- Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
-[RFC2565]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April 1999.
-
-[RFC2566]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
-
-[RFC2567]
- Wright, D., "Design Goals for an Internet Printing Protocol",
- draft-ietf-ipp-req-03.txt, November, 1998.
-
-[RFC2568
- Zilles, S., "Rationale for the Structure and Model and Protocol for
- the Internet Printing Protocol", RFC 2568, April 1999.
-
-[RFC2569]
- Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
- LPD and IPP Protocols", RFC 2569, April 1999.
-
-[RFC2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-[Servlet]
- Servlet Specification Version 2.1
- (http://java.sun.com/products/servlet/2.1/index.html).
-
-[svrloc-printer]
- St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the
- Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer-
- scheme-06.txt>, work in progress, March 8, 2000.
-
-[SSL]
- Netscape, The SSL Protocol, Version 3, (Text version 3.02),
- November 1996.
-
-
-9 Authors' Address
-
-Hastings, Manros, Kugler, Holst, Zehler [page 82]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-Thomas N. Hastings
-Xerox Corporation
-701 Aviation Blvd.
-El Segundo, CA 90245
-hastings@cp10.es.xerox.com
-
-Carl-Uno Manros
-Xerox Corporation
-701 Aviation Blvd.
-El Segundo, CA 90245
-manros@cp10.es.xerox.com
-
-Carl Kugler
-Mail Stop 003G
-IBM Printing Systems Co
-6300 Diagonal Hwy
-Boulder CO 80301
-Kugler@us.ibm.com
-
-Henrik Holst
-i-data Printing Systems
-Vadstrupvej 35-43
-2880 Bagsvaerd, Denmark
-hh@I-data.com
-
-Peter Zehler
-Xerox Corporation
-800 Philips Road
-Webster, NY 14580
-
-Phone: 716 265-8755
-peter.zehler@usa.xerox.com
-
-10 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.
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 83]
- Expires November 30, 2000
-\f
-
-
-INTERNET-DRAFT IPP/1.1: Implementer's Guide May 30, 2000
-
-
-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.
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Manros, Kugler, Holst, Zehler [page 84]
- Expires November 30, 2000
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT
+draft-ietf-ipp-implementers-guide-v11-02.txt
+[Obsoletes RFC 2639] T. Hastings
+ Xerox Corporation
+ C. Manros
+ Xerox Corporation
+ C. Kugler
+ IBM Printing Systems Co
+ H. Holst
+ i-data Printing Systems
+ P. Zehler
+ Xerox Corporation
+ January 25, 2001
+
+ Internet Printing Protocol/1.1: Implementer's Guide
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+Abstract
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 1]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 [RFC2911]
+ and the IPP Transport and Encoding [RFC2910] documents. It is
+ intended to help implementers understand IPP/1.1, as well as 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.
+
+ This document obsoletes RFC 2639 which was the Implementer's Guide
+ for IPP/1.0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 2]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ 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 goal document calls out a subset of end
+ user requirements that are satisfied in IPP/1.1. Operator and
+ administrator requirements are out of scope for version 1.1.
+
+ 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.1: 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.1: 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 3]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+TABLE OF CONTENTS
+
+ 1 Introduction....................................................7
+ 1.1 Conformance language.........................................7
+ 1.2 Other terminology............................................8
+ 1.3 Issues Raised from Interoperability Testing Events...........8
+
+ 2 IPP Objects.....................................................8
+
+ 3 IPP Operations.................................................10
+ 3.1 Common Semantics............................................10
+ 3.1.1 Summary of Operation Attributes............................10
+ 3.1.2 Suggested Operation Processing Steps for IPP Objects.......16
+ 3.1.2.1 Suggested Operation Processing Steps for all Operations ..17
+ 3.1.2.1.1 Validate version number...............................18
+ 3.1.2.1.2 Validate operation identifier.........................19
+ 3.1.2.1.3 Validate the request identifier.......................19
+ 3.1.2.1.4 Validate attribute group and attribute presence and order
+ 19
+ 3.1.2.1.4.1 Validate the presence and order of attribute groups .19
+ 3.1.2.1.4.2 Ignore unknown attribute groups in the expected
+ position 20
+ 3.1.2.1.4.3 Validate the presence of a single occurrence of
+ required Operation attributes.....................................21
+ 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes
+ 28
+ 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
+ 32
+ 3.1.2.2 Suggested Additional Processing Steps for Operations that
+ Create/Validate Jobs and Add Documents............................35
+ 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied......35
+ 3.1.2.2.2 Check that the Printer object is accepting jobs.......36
+ 3.1.2.2.3 Validate the values of the Job Template attributes....36
+ 3.1.2.3 Algorithm for job validation .............................37
+ 3.1.2.3.1 Check for conflicting Job Template attributes values..43
+ 3.1.2.3.2 Decide whether to REJECT the request..................43
+ 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success
+ status codes......................................................45
+ 3.1.2.3.4 Create the Job object with attributes to support......45
+ 3.1.2.3.5 Return one of the success status codes................47
+ 3.1.2.3.6 Accept appended Document Content......................48
+ 3.1.2.3.7 Scheduling and Starting to Process the Job............48
+ 3.1.2.3.8 Completing the Job....................................48
+ 3.1.2.3.9 Destroying the Job after completion...................48
+ 3.1.2.3.10 Interaction with "ipp-attribute-fidelity".............49
+ 3.1.2.3.11 Character set code conversion support.................49
+ 3.1.2.3.12 What charset to return when an unsupported charset is
+ requested (Issue 1.19)?...........................................50
+ 3.1.2.3.13 Natural Language Override (NLO).......................51
+ 3.1.3 Status codes returned by operation.........................53
+
+
+Hastings, et al. Expires July 25, 2001 [page 4]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 3.1.3.1 Printer Operations .......................................53
+ 3.1.3.1.1 Print-Job.............................................53
+ 3.1.3.1.2 Print-URI.............................................55
+ 3.1.3.1.3 Validate-Job..........................................56
+ 3.1.3.1.4 Create-Job............................................56
+ 3.1.3.1.5 Get-Printer-Attributes................................56
+ 3.1.3.1.6 Get-Jobs..............................................57
+ 3.1.3.1.7 Pause-Printer.........................................58
+ 3.1.3.1.8 Resume-Printer........................................59
+ 3.1.3.1.8.1 What about Printers unable to change state due to an
+ error condition?..................................................59
+ 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? ...59
+ 3.1.3.1.9 Purge-Printer.........................................60
+ 3.1.3.2 Job Operations ...........................................60
+ 3.1.3.2.1 Send-Document.........................................60
+ 3.1.3.2.2 Send-URI..............................................61
+ 3.1.3.2.3 Cancel-Job............................................62
+ 3.1.3.2.4 Get-Job-Attributes....................................62
+ 3.1.3.2.5 Hold-Job..............................................63
+ 3.1.3.2.6 Release-Job...........................................64
+ 3.1.3.2.7 Restart-Job...........................................64
+ 3.1.3.2.7.1 Can documents be added to a restarted job? ..........65
+ 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
+ 1.18) 65
+ 3.1.5 Sending empty attribute groups.............................65
+ 3.2 Printer Operations..........................................66
+ 3.2.1 Print-Job operation........................................66
+ 3.2.1.1 Flow controlling the data portion of a Print-Job request
+ (Issue 1.22)......................................................66
+ 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) ...66
+ 3.2.2 Get-Printer-Attributes operation...........................67
+ 3.2.3 Get-Jobs operation.........................................67
+ 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
+ 1.39)? 67
+ 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
+ 68
+ 3.2.4 Create-Job operation.......................................68
+ 3.3 Job Operations..............................................69
+ 3.3.1 Validate-Job...............................................69
+ 3.3.2 Restart-Job................................................69
+
+ 4 Object Attributes..............................................70
+ 4.1 Attribute Syntax's..........................................70
+ 4.1.1 The 'none' value for empty sets (Issue 1.37)...............70
+ 4.1.2 Multi-valued attributes (Issue 1.31).......................70
+ 4.1.3 Case Sensitivity in URIs (issue 1.6).......................70
+ 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage..71
+ 4.2 Job Template Attributes.....................................72
+ 4.2.1 multiple-document-handling(type2 keyword)..................72
+ 4.2.1.1 Support of multiple document jobs ........................72
+
+
+Hastings, et al. Expires July 25, 2001 [page 5]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 4.3 Job Description Attributes..................................72
+ 4.3.1 Getting the date and time of day...........................72
+ 4.4 Printer Description Attributes..............................73
+ 4.4.1 queued-job-count (integer(0:MAX))..........................73
+ 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? ......73
+ 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer
+ is (Issue 1.15)?..................................................73
+ 4.4.2 printer-current-time (dateTime)............................73
+ 4.4.3 Printer-uri................................................74
+ 4.5 Empty Jobs..................................................74
+
+ 5 Directory Considerations.......................................75
+ 5.1 General Directory Schema Considerations.....................75
+ 5.2 IPP Printer with a DNS name.................................75
+
+ 6 Security Considerations........................................75
+ 6.1 Querying jobs with IPP that were submitted using other job
+ submission protocols (Issue 1.32).................................75
+
+ 7 Encoding and Transport.........................................76
+ 7.1 General Headers.............................................78
+ 7.2 Request Headers............................................79
+ 7.3 Response Headers............................................81
+ 7.4 Entity Headers.............................................81
+ 7.5 Optional support for HTTP/1.0...............................82
+ 7.6 HTTP/1.1 Chunking...........................................83
+ 7.6.1 Disabling IPP Server Response Chunking.....................83
+ 7.6.2 Warning About the Support of Chunked Requests..............83
+
+ 8 References.....................................................84
+
+ 9 Authors' Address...............................................85
+
+ 10 Full Copyright Statement.......................................86
+
+TABLES
+
+ Table 1 - Summary of Printer operation attributes that sender MUST
+ supply ........................................................11
+ Table 2 - Summary of Printer operation attributes that sender MAY
+ supply ........................................................12
+ Table 3 - Summary of Job operation attributes that sender MUST supply
+ ..............................................................13
+ Table 4 - Summary of Job operation attributes that sender MAY supply
+ ..............................................................14
+ Table 5 - Printer operation response attributes...................15
+ Table 6 - Examples of validating IPP version......................18
+ Table 7 - Rules for validating single values X against Z..........38
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 6]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+
+
+
+1 Introduction
+
+ The IPP Implementer's Guide (IIG) (this document) contains
+ information that supplements the IPP Model and Semantics [RFC2911]
+ and the IPP Transport and Encoding [RFC2910] 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 [RFC2911] or [RFC2910],
+ those documents take precedence over this document.
+
+ Platform-specific implementation considerations will be included in
+ this guide as they become known.
+
+ In order to help the reader of the IIG and the IPP Model and
+ Semantics document, the sections in this document parallel the
+ corresponding sections in the Model document and are numbered the
+ same for ease of cross reference. The sections that correspond to
+ the IPP Transport and Encoding are correspondingly offset.
+
+
+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 [RFC2911] and [RFC2910] documents require and
+ allow, rather than specifying additional conformance requirements.
+ These terms are defined in section 12 on conformance terminology in
+ [RFC2911], most of which is taken from RFC 2119 [RFC2119].
+
+ Implementers should read section 12 (APPENDIX A) in [RFC2911] 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
+ [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is
+ merely allowed as an implementer option. The verbs SHOULD and SHOULD
+ NOT indicate suggested behavior, but which is not required or
+ disallowed, respectively, in order to conform to the specification.
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 7]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+1.2 Other terminology
+
+ This document uses other terms, such as "attributes", "operation",
+ and "Printer" as defined in [RFC2911] section 12. In addition, 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.
+
+
+1.3 Issues Raised from Interoperability Testing Events
+
+ The IPP WG has conducted three open Interoperability Testing Events.
+ The first one was held in September 1998, the second one was held in
+ March 1999, and the third one was held in October 2000. See the
+ summary reports in:
+
+ ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
+
+ The issues raised from the first Interoperability Testing Event are
+ numbered 1.n in this document and have been incorporated into
+ "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and
+ Transport" [RFC2565] documents. However, some of the discussion is
+ left here in the Implementer's Guide to help understanding.
+
+ The issues raised from the second Interoperability Testing Event are
+ numbered 2.n in this document have been incorporated into "IPP/1.1
+ Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
+ Transport" [RFC2910] documents. However, some of the discussion is
+ left here in the Implementer's Guide to help understanding.
+
+ The issues raised from the third Interoperability Testing Event are
+ numbered 3.n in this document and are described in:
+
+ ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdf
+ ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc
+ ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt
+
+
+2 IPP Objects
+
+ The term "client" in IPP is intended to mean any client that issues
+ IPP operation requests and accepts IPP operation responses, whether
+ it be a desktop or a server. In other words, the term "client" does
+ not just mean end-user clients, such as those associated with
+ desktops.
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 8]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ The term "IPP Printer" in IPP is intended to mean an object that
+ accepts IPP operation requests and returns IPP operation responses,
+ whether implemented in a server or a device. An IPP Printer object
+ MAY, if implemented in a server, turn around and forward received
+ jobs (and other requests) to other devices and print
+ servers/services, either using IPP or some other protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 9]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3 IPP Operations
+
+ This section corresponds to Section 3 "IPP Operations" in the
+ IPP/1.1 Model and Semantics document [RFC2911].
+
+
+3.1 Common Semantics
+
+ This section discusses semantics common to all operations.
+
+
+3.1.1 Summary of Operation Attributes
+
+ Legend for the following table:
+
+ R indicates a REQUIRED operation that MUST be supported by the IPP
+ object (Printer or Job). For attributes, R indicates that the
+ attribute MUST be supported by the IPP object supports the
+ associated operation.
+
+ O indicates an OPTIONAL operation or attribute that MAY be
+ supported by the IPP object (Printer or Job).
+
+ + indicates that this is not an IPP/1.0 feature, but is only a part
+ of IPP/1.1 and future versions of IPP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 10]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Table 1 - Summary of Printer operation attributes that sender MUST
+ supply
+
+ Printer Operations
+ Requests Response
+ s
+
+ Operation Print- Pri Crea Get- Get Pause- All
+ Attributes Job, te- Printer- - Printer Operatio
+ Validate URI Job Attribut Job , ns
+ -Job (R) (O) (O) es (R) s Resume-
+ (R) Printer
+ ,
+ Purge-
+ nt- Printer
+ (O+)
+
+ Operation parameters--REQUIRED to be supplied by the sender:
+ operation-id R R R R R R
+ status-code R
+ request-id R R R R R R R
+ version- R R R R R R R
+ number
+ Operation attributes--REQUIRED to be supplied by the sender:
+ attributes- R R R R R R R
+ charset
+ attributes- R R R R R R R
+ natural-
+ language
+ document-uri R
+ job-id*
+ job-uri*
+ last-
+ document
+ printer-uri R R R R R R
+ Operation attributes--RECOMMENDED to be supplied by the sender:
+ job-name R R R
+ requesting- R R R R R R
+ user-name
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 11]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Table 2 - Summary of Printer operation attributes that sender MAY
+ supply
+
+ Printer Operations
+ Requests Respo
+ nses
+
+ Operation Print- Prin Crea Get- Get Pause- All
+ Attributes Job, t- te- Printer - Printer Opera
+ Valida URI Job - Job , tions
+ te-Job (O) (O) Attribu s Resume-
+ (R) tes (R) (R) Printer
+ ,
+ Purge-
+ Printer
+ (O+)
+
+ Operation attributes--OPTIONAL to be supplied by the sender:
+ status-message O
+ detailed-status- O
+ message
+ document-access- O**
+ error
+ compression O O
+ document-format R R R
+ 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.
+ ** "document-access-error" applies to the Print-URI response
+ only.
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 12]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+
+ Table 3 - Summary of Job operation attributes that sender MUST supply
+
+ Job Operations
+ Requests Respons
+ es
+
+ Operation Send- Send Cance Get- All
+ Attributes Docume -URI l-Job Job- Job, Operatio
+ nt (O) (R) Attrib Release ns
+ (O) utes -Job,
+ (R) Restart
+ -Job
+ (O+)
+
+ 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-natural- R R R R R R
+ language
+ document-uri R
+ job-id* R R R R R
+ job-uri* R R R R R
+ last-document R R
+ printer-uri R R R R R
+ Operation attributes--RECOMMENDED to be supplied by the sender:
+ job-name
+ requesting-user- R R R R R
+ name
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 13]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+ Table 4 - Summary of Job operation attributes that sender MAY supply
+
+ Job Operations
+ Requests Respo
+ nses
+
+ Operation Send- Sen Cance Hold- Relea All
+ Attributes Documen d- l-Job Get- Job, se- Opera
+ t URI (R) Attrib Restar Job tions
+ (O) (O) utes t-Job (O+)
+ (R) (O+)
+
+ Operation attributes--OPTIONAL to be supplied by the sender:
+ status-message O
+ detailed-status- O
+ message
+ document-access- O**
+ error
+ 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 O O
+ job-hold-until R
+ my-jobs
+ requested- R
+ attributes
+ which-jobs
+ * "job-id" is REQUIRED only if used together with "printer-uri" to
+ identify the target job; otherwise, "job-uri" is REQUIRED.
+ ** "document-access-error" applies to the Send-URI operation only.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 14]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+
+ Table 5 - Printer operation response attributes
+
+ Printer Operations
+ Response
+
+ Operation Print- Validat Prin Create Get- Get- Pause-
+ Attributes Job e-Job t- -Job Printe Jobs Printer
+ (R),Send (R) URI (O) r- (R) ,
+ - (O), Attrib Resume-
+ Document Send utes Printer
+ (O) -URI (R) ,
+ (O) Purge-
+ Printer
+ (O+)
+
+ job-uri R R R
+ job-id R R R
+ job-state R R R
+ job-state- R+ R+ R+
+ reasons
+ number-of- O O O
+ intervening-
+ jobs
+ document- O
+ access-error+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 15]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+
+
+3.1.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.
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 16]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.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.
+
+ IIG Sect # Flow IPP error status codes
+ ---------- ---- ----------------------
+ |
+ v err
+ 3.1.2.1.1 <Validate version> --> server-error-version-not-
+ supported
+ ok|
+ v err
+ 3.1.2.1.2 <Validate operation> --> server-error-operation-not-
+ supported
+ ok|
+ v err
+ 3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
+ 3.1.2.1.4.2 <of attributes>
+ ok|
+ v err
+ 3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
+ <of operation attr>
+ ok|
+ v err
+ 3.1.2.1.5 <Valied values of> --> client-error-bad-request
+ <operation attrs> client-error-request-value-
+ too-long
+ <(length, tag, range,>
+ <multi-value)>
+ ok|
+ v err
+ 3.1.2.1.5 <Validate values> --> client-error-bad-request
+ <with supported values> client-error-charset-not-
+ supported
+ ok| client-error-attributes-or-
+ values-
+ | not-supported
+ v err
+ 3.1.2.1.6 <Validate optionally> --> client-error-bad-request
+ <operation attr> client-error-natural-language-
+ not-supported
+ | client-error-request-value-
+ too-long
+ | client-error-attributes-or-
+ values-not-supported
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 17]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.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 major version number matches, but the minor version
+ number does not, the Printer SHOULD accept and attempt to process
+ the request, or MAY reject the request and return the 'server-error-
+ version-not-supported' status code. In all cases, the Printer MUST
+ return the nearest version number that it supports. For example,
+ suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
+ The following responses are conforming:
+
+ Table 6 - Examples of validating IPP version
+
+
+
+ Client supplies Printer Accept Request? Printer returns
+
+
+ 1.0 yes (SHOULD) 1.1
+
+ 1.0 no (SHOULD NOT) 1.1
+
+ 1.1 yes (MUST) 1.1
+
+ 1.2 yes (MUST) 1.2
+
+ 1.3 yes (SHOULD) 1.2
+
+ 1.3 no (SHOULD NOT) 1.2
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 18]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
+ so that they can interoperate with either client implementations.
+ Some implementations may allow an Administrator to explicitly disable
+ support for one or the other by setting the "ipp-versions-supported"
+ Printer description attribute.
+
+ Likewise, it is advantageous for clients to support both versions to
+ allow interoperability with new and legacy Printers.
+
+
+3.1.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.
+
+
+3.1.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.1 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.
+
+
+3.1.2.1.4 Validate attribute group and attribute presence and order
+
+ The order of the following validation steps depends on
+ implementation.
+
+
+3.1.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).
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 19]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+
+3.1.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 20]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.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 [RFC2911] 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:
+
+ REJECTS the request and RETURNS the 'client-error-bad-request'
+ status code
+
+ accepts the request and uses the first occurrence of the
+ attribute no matter where it is
+
+ accepts the request and uses the last occurrence of the
+ attribute no matter where it is
+
+ 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.
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 21]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 [RFC2911] 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 or operation that an IPP object
+ MUST support
+ O indicates an OPTIONAL attribute or operation 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.
+ + indicates that this is not a IPP/1.0 operation, but is only a
+ part of IPP/1.1 and future versions of IPP.
+
+ 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 (R):
+ 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 [RFC2911] Section 4.2)
+ Group 3: Document Content (R)
+ <document content>
+
+
+Hastings, et al. Expires July 25, 2001 [page 22]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+ Validate-Job Request (R):
+ 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 [RFC2911] Section 4.2)
+
+ Print-URI Request (O):
+ 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 [RFC2911] Section 4.2)
+
+ Create-Job Request (O):
+ 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*)
+
+
+Hastings, et al. Expires July 25, 2001 [page 23]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ job-media-sheets (O*)
+ Group 2: Job Template Attributes (R*)
+ <Job Template attributes> (O*) (see
+ (see [RFC2911] Section 4.2)
+
+ Get-Printer-Attributes Request (R):
+ 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-Jobs Request (R):
+ 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*)
+
+ Send-Document Request (O):
+ 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 (O):
+ 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*)
+
+
+Hastings, et al. Expires July 25, 2001 [page 24]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ compression (O*)
+
+ Cancel-Job Request (R):
+ Release-Job Request (O+):
+ 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-Job-Attributes Request (R):
+ 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*)
+
+ Pause-Printer Request (O+):
+ Resume-Printer Request (O+):
+ Purge-Printer Request (O+):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ printer-uri (R)
+ requesting-user-name (R*)
+
+ Hold-Job Request (O+):
+ Restart-Job Request (O+):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ (printer-uri & job-id) | job-uri (R)
+ requesting-user-name (R*)
+ job-hold-until (R*)
+ message (O*)
+
+ 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 (R):
+ Create-Job Response (O):
+ Send-Document Response (O):
+
+
+Hastings, et al. Expires July 25, 2001 [page 25]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ status-message (O*)
+ detailed-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* | R+)
+ job-state-message (O*)
+ number-of-intervening-jobs (O*)
+
+ Validate-Job Response (R):
+ Cancel-Job Response (R):
+ Hold-Job Response (O+):
+ Release-Job Response (O+):
+ Restart-Job Response (O+):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ status-message (O*)
+ detailed-status-message (O*)
+ Group 2: Unsupported Attributes (R*) (see Note 3)
+ <unsupported attributes> (R*)
+
+ Print-URI Response (O):
+ Send-URI Response (O):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ status-message (O*)
+ detailed-status-message (O*)
+ document-access-error (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* | R+)
+ job-state-message (O*)
+ number-of-intervening-jobs (O*)
+
+ Get-Printer-Attributes Response (R):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+
+
+Hastings, et al. Expires July 25, 2001 [page 26]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ status-message (O*)
+ detailed-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*)
+
+ Get-Jobs Response (R):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ status-message (O*)
+ detailed-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*)
+
+ Get-Job-Attributes Response (R):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ status-message (O*)
+ detailed-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*)
+
+ Pause-Printer Response (O+):
+ Resume-Printer Response (O+):
+ Purge-Printer Response (O+):
+ Group 1: Operation Attributes (R)
+ attributes-charset (R)
+ attributes-natural-language (R)
+ status-message (O*)
+ detailed-status-message (O*)
+ Group 2: Unsupported Attributes (R*) (see Note 4)
+ <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.
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 27]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+ 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.
+
+
+3.1.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 [RFC2911] Section 4.1,
+
+ b) that the attribute syntax tag is correct for that Operation
+ attribute according to [RFC2911] Section 3,
+
+ c) that the value is in the range specified for that Operation
+ attribute according to [RFC2911] 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 [RFC2911] 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.
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 28]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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'.
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 29]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 the client-supplied URI scheme is not supported, i.e. the
+ value is not in the Printer object's referenced-uri-scheme-
+ supported" attribute, the Printer object MUST reject the
+ request and return the 'client-error-uri-scheme-not-
+ supported' status code. 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)
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 30]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 31]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+ -----------------------------------------------
+
+
+
+3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
+
+ OPTIONAL Operation attributes are those that an IPP object MAY
+ 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 3.1.2.1.5. As in Section 3.1.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'.
+
+
+Hastings, et al. Expires July 25, 2001 [page 32]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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'.
+ Note to IPP/1.0 implementers: Support for the "compression"
+ attribute was optional in IPP/1.0 and was changed to REQUIRED
+ in IPP/1.1. However, an IPP/1.0 object SHOULD at least check
+ for the "compression" attribute being present and reject the
+ create request, if they don't support "compression". Not
+ checking is a bug, since the data will be unintelligible.
+
+ 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'.
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 33]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 34]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.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.
+
+ IIG Sect # Flow IPP error status codes
+ ---------- ---- ----------------------
+ |
+ v No
+ 3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
+ <supplied?> |
+ Yes| |
+ | ipp-attribute-fidelity = no |
+ |<------------------------------+
+ v No
+ 3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
+ <accepting jobs?>
+ Yes|
+ v err
+ 3.1.2.3 <Validate values of> --> client-error-bad-request
+ <Job template attributes> client-error-request-value-too-
+ long
+ <(length, tag, range,>
+ <multi-value)>
+ ok|
+ v err
+ 3.1.2.3 <Validate values with> --> client-error-bad-request
+ <supported values> client-error-attributes-or-
+ | values-not-supported
+ v err
+ 3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
+ attributes
+ <Job Template attr values> client-error-attributes-or-
+ values-not-supported
+ v
+
+3.1.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'.
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 35]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.2.2.2 Check that the Printer object is accepting jobs
+
+ If the value of the Printer objects "printer-is-accepting-jobs" is
+ 'false', the Printer object REJECTS the request and RETURNS the
+ 'server-error-not-accepting-jobs' status code.
+
+
+3.1.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 3.1.2.1.5.):
+
+ a) that the length of each value is correct for the attribute
+ syntax tag supplied by the client according to [RFC2911] Section
+ 4.1.
+
+ b) that the attribute syntax tag is correct for that attribute
+ according to [RFC2911] 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 [RFC2911]
+ Sections 4.2 to 4.4.
+
+ As in Section 3.1.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-request'
+ 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
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 36]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ depending on implementation. Therefore, clients MUST NOT supply
+ multiple occurrences of the same Job Template attribute in the Job
+ Attributes group in the request.
+
+
+3.1.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 [RFC2911]).
+
+ 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 7 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 7 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 7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 37]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Table 7 - Rules for validating single values X against Z
+
+
+
+ Attribute syntax attribute syntax validated if:
+ of X 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
+ [RFC2911] 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.
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 38]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ -----------------------------------------------
+
+ 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 [RFC2911] 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))
+
+
+Hastings, et al. Expires July 25, 2001 [page 39]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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'.
+
+
+Hastings, et al. Expires July 25, 2001 [page 40]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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).
+ -----------------------------------------------
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 41]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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'
+
+ Note: It's possible for a Printer to receive a zero length keyword
+ in a request. Since this is a keyword, its value needs to be
+ compared with the supported values. Assuming that the printer
+ doesn't have any values in its corresponding "xxx-supported"
+ attribute that are keywords of zero length, the comparison will fail.
+ Then the request will be accepted or rejected depending on the value
+ of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
+ No special handling is required for
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 42]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.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.
+
+
+3.1.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.
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 43]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ In general, the final results of Job processing are unknown at Job
+ submission time. The client has to rely on notifications or polling
+ to find out what happens at Job processing time. However, there are
+ cases in which some Printers can determine at Job submission time
+ that Job processing is going to fail. As an optimization, we'd like
+ to have the Printer reject the Job in these cases.
+
+ There are three types of "processing" errors that might be detectable
+ at Job submission time:
+
+ 1. 'client-error-document-format-not-supported' : For the Print-
+ Job, Send-Document, Print-URI, and Send-URI operations, if all these
+ conditions are true:
+
+ - the Printer supports auto-sensing,
+ - the request "document-format" operation attribute is
+ 'application/octet-stream',
+ - the Printer receives document data before responding,
+ - the Printer auto-senses the document format before responding,
+ - the sensed document format is not supported by the Printer
+ then the Printer should respond with 'client-error-document-format-
+ not-supported' status.
+
+ 2. 'client-error-compression-error': For the Print-Job, Send-
+ Document, Print-URI, and Send-URI operations, if all these
+ conditions are true:
+
+ - the client supplies a supported value for the "compression"
+ operation attribute in the request
+ - the Printer receives document data before responding,
+ - the Printer attempts to decompress the document data before
+ responding,
+ - the document data cannot be decompressed using the algorithm
+ specified by the "compression" operation attribute
+ then the Printer should respond with 'client-error-compression-error'
+ status.
+
+ 3. 'client-error-document-access-error': For the Print-URI, and
+ Send-URI operations, if the Printer attempts and fails to pull the
+ referenced document data before responding, it should respond with
+ 'client-error-document-access-error' status.
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 44]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Some Printers are not able to detect these errors until Job
+ processing time. In that case, the errors are recorded in the
+ corresponding job-state and job-state reason attributes. (There is
+ no standard way for a client to determine whether a Printer can
+ detect these errors at Job submission time.) For example, if auto-
+ sensing happens AFTER the job is accepted (as opposed to auto-sensing
+ at submit time before returning the response), the implementation
+ aborts the job, puts the job in the 'aborted' state and sets the
+ 'unsupported-document-format' value in the job's "job-state-reasons".
+
+ A client should always provide a valid "document-format" operation
+ attribute whenever practical. In the absence of other information, a
+ client itself may sniff the document data to determine document
+ format.
+
+ Auto sensing at Job submission time may be more difficult for the
+ Printer when combined with compression. For auto-sensed Jobs, a
+ client may be better off deferring compression to the transfer
+ protocol layer, e.g.; by using the HTTP Content-Encoding header.
+
+
+3.1.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.
+
+
+3.1.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:
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 45]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 will 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.
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 46]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+
+3.1.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.
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 47]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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, [RFC2911] section
+ 3.2.1.2.
+
+
+3.1.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.
+
+
+3.1.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.
+
+
+3.1.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.
+
+
+3.1.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.
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 48]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.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". Character Sets, natural languages,
+ and internationalization
+
+ This section discusses character set support, natural language
+ support and internationalization.
+
+
+3.1.2.3.11 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".
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 49]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ According to the RFC2911 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.
+
+
+3.1.2.3.12 What charset to return when an unsupported charset is
+ requested (Issue 1.19)?
+
+ 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.
+
+
+Hastings, et al. Expires July 25, 2001 [page 50]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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, [RFC2911] 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).
+
+
+3.1.2.3.13 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 'textWithLanguage' 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.
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 51]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 [RFC2911] 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.
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 52]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.3 Status codes returned by operation
+
+ This section corresponds to [RFC2911] section 3.1.6 "Operation
+ Response Status Codes and Status Messages". 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.
+
+
+3.1.3.1 Printer Operations
+
+
+3.1.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 13 in [RFC2911] 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 syntax's, 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.
+
+ [RFC2911] 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 13
+ in [RFC2911]): '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:
+
+
+Hastings, et al. Expires July 25, 2001 [page 53]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 syntax's, exceed the maximum length specified in
+ [RFC2911] 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 syntax's, 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.
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 54]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 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.
+
+3.1.3.1.2 Print-URI
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ 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.
+
+ client-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.
+ server-error-operation-not-supported: the Print-URI operation is
+ not supported.
+
+
+Hastings, et al. Expires July 25, 2001 [page 55]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+
+3.1.3.1.3 Validate-Job
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to Validate-Job. See Section 13 in
+ [RFC2911] for a more complete description of each status code.
+
+
+3.1.3.1.4 Create-Job
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to Create-Job with the following
+ specializations and differences. See Section 13 in [RFC2911] for a
+ more complete description of each status code.
+
+ server-error-operation-not-supported: the Create-Job operation is
+ not supported.
+ client-error-multiple-document-jobs-not-supported: while the
+ Create-Job and Send-Document operations are supported, this
+ implementation doesn't support more than one document with data.
+
+3.1.3.1.5 Get-Printer-Attributes
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to the Get-Printer-Attributes
+ operation with the following specialization's and differences. See
+ Section 13 in [RFC2911] 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 operation attributes or values were substituted
+ or ignored (same as Print-Job) and no requested attributes were
+ unsupported.
+ successful-ok-ignored-or-substituted-attributes: 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.
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 56]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ client-error-attributes-or-values-not-supported: not applicable,
+ since unsupported operation attributes and/or values MUST be
+ ignored and an appropriate success code returned (see above).
+ 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.
+
+3.1.3.1.6 Get-Jobs
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to the Get-Jobs operation with the
+ following specialization's and differences. See Section 13 in
+ [RFC2911] 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: same as Get-Printer-Attributes (see section
+ 3.1.3.1.5).
+ successful-ok-ignored-or-substituted-attributes: same as Get-
+ Printer-Attributes (see section 3.1.3.1.5).
+ successful-ok-conflicting-attributes: same as Get-Printer-
+ Attributes (see section 3.1.3.1.5).
+
+ 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 and/or
+ values MUST be ignored and an appropriate success code
+ returned (see above).
+ client-error-conflicting-attributes: same as Print-Job, except
+ that "ipp-attribute-fidelity" is not involved.
+
+
+Hastings, et al. Expires July 25, 2001 [page 57]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+3.1.3.1.7 Pause-Printer
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to Pause-Printer with the following
+ specializations and differences. See Section 13 in [RFC2911] for a
+ more complete description of each status code.
+
+ For the following success status codes, the Printer object is being
+ stopped from scheduling jobs on all its devices.
+
+ 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 Printer object has not been
+ stopped from scheduling jobs on all its devices.
+
+ client-error-not-possible: not applicable.
+ client-error-not-found: the target Printer object does not
+ exist.
+ client-error-gone: the target Printer 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-conflicting-attributes: same as Print-Job, except
+ that the Printer's "printer-is-accepting-jobs" attribute is
+ not involved.
+ server-error-operation-not-supported: the Pause-Printer
+ operation is not supported.
+ server-error-device-error: not applicable.
+ 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.
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 58]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.3.1.8 Resume-Printer
+
+ All of the Print-Job status code descriptions in Section 3.1.3.1.1
+ Print-Job Response with the specialization's described for Pause-
+ Printer are applicable to Resume-Printer. See Section 13 in
+ [RFC2911] for a more complete description of each status code.
+
+ For the following success status codes, the Printer object resumes
+ scheduling jobs on all its devices.
+
+ 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 Printer object does not resume
+ scheduling jobs.
+
+ server-error-operation-not-supported: the Resume-Printer
+ operation is not supported.
+
+
+3.1.3.1.8.1 What about Printers unable to change state due to an error
+ condition?
+ If, in case, the IPP printer is unable to change its state due to
+ some problem with the actual printer device (say, it is shut down or
+ there is a media-jam as indicated in [RFC2911]), what should be the
+ result of the "Resume-Printer" operation? Should it still change the
+ 'printer-state-reasons' and return success or should it fail ?
+
+ The Resume-Printer operation must clear the 'paused' or 'moving-to-
+ paused' 'printer-state-message'. The operation must return a
+ 'successful-ok' status code.
+
+
+3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?
+
+
+ If the Resume-Printer operation succeeds, what should be the value of
+ "printer-state" and who should take care of the "printer-state"
+ attribute value later on ?
+
+ The Resume-Printer operation may change the "printer-state-reasons"
+ value.
+
+ The "printer-state" will change to one of three states:
+
+ 1. 'idle' - no additional jobs and no error conditions present
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 59]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 2. 'processing' - job available and no error conditions present
+
+ 3. current state (i.e. no change) an error condition is present
+ (e.g. media jam)
+
+ In the third case the "printer-state-reason" will be cleared by
+ automata when it detects the error condition no longer exists. The
+ "printer-state" will move to 'idle' or 'processing' when conditions
+ permit. (i.e. no more error conditions)
+
+
+3.1.3.1.9 Purge-Printer
+
+ All of the Print-Job status code descriptions in Section 3.1.3.1.1
+ Print-Job Response with the specialization's described for Pause-
+ Printer are applicable to Purge-Printer. See Section 13 in [RFC2911]
+ for a more complete description of each status code.
+
+ For the following success status codes, the Printer object purges all
+ it's jobs.
+
+ 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 Printer object does not purge
+ any jobs.
+
+ server-error-operation-not-supported: the Purge-Printer
+ operation is not supported.
+
+3.1.3.2 Job Operations
+
+
+3.1.3.2.1 Send-Document
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to the Get-Printer-Attributes
+ operation with the following specialization's and differences. See
+ Section 13 in [RFC2911] 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).
+
+
+Hastings, et al. Expires July 25, 2001 [page 60]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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
+ job that was created with a Create-Job operation 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.
+
+3.1.3.2.2 Send-URI
+
+ All of the Print-Job status code descriptions in Section 3.1.3.1.1
+ Print-Job Response with the specialization's described for Send-
+ Document are applicable to Send-URI. See Section 13 in [RFC2911] for
+ a more complete description of each status code.
+
+ client-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.
+ server-error-operation-not-supported: the Send-URI operation is
+ not supported.
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 61]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.3.2.3 Cancel-Job
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to Cancel-Job with the following
+ specializations and differences. See Section 13 in [RFC2911] 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.
+
+3.1.3.2.4 Get-Job-Attributes
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to Get-Job-Attributes with the
+ following specializations and differences. See Section 13 in
+ [RFC2911] for a more complete description of each status code.
+
+
+Hastings, et al. Expires July 25, 2001 [page 62]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ For the following success status codes, the requested attributes are
+ returned in Group 3 in the response:
+
+ successful-ok: same as Get-Printer-Attributes (see section
+ 3.1.3.1.5).
+ successful-ok-ignored-or-substituted-attributes: same as Get-
+ Printer-Attributes (see section 3.1.3.1.5).
+ successful-ok-conflicting-attributes: same as Get-Printer-
+ Attributes (see section 3.1.3.1.5).
+
+ 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-attributes-or-values-not-supported: not
+ applicable, since unsupported operation attributes and/or
+ values MUST be ignored and an appropriate success code
+ returned (see above).
+ 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.
+
+3.1.3.2.5 Hold-Job
+
+ All of the Print-Job status codes described in Section 3.1.3.1.1
+ Print-Job Response are applicable to Hold-Job with the following
+ specializations and differences. See Section 13 in [RFC2911] for a
+ more complete description of each status code.
+
+ For the following success status codes, the Job object is being held
+ or has been held:
+
+ 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.
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 63]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ For any of the error status codes, the Job object has not been held
+ or was previously held.
+
+ 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-conflicting-attributes: same as Print-Job, except
+ that the Printer's "printer-is-accepting-jobs" attribute is
+ not involved.
+ server-error-operation-not-supported: the Hold-Job operation is
+ not supported.
+ server-error-device-error: not applicable.
+ 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.
+
+3.1.3.2.6 Release-Job
+
+ All of the Print-Job status code descriptions in Section 3.1.3.1.1
+ Print-Job Response with the specialization's described for Hold-Job
+ are applicable to Release-Job. See Section 13 in [RFC2911] for a
+ more complete description of each status code.
+
+ server-error-operation-not-supported: the Release-Job operation
+ is not supported.
+
+3.1.3.2.7 Restart-Job
+
+ All of the Print-Job status code descriptions in Section 3.1.3.1.1
+ Print-Job Response with the specialization's described for Hold-Job
+ are applicable to Restart-Job. See Section 13 in [RFC2911] for a
+ more complete description of each status code.
+
+ server-error-operation-not-supported: the Restart-Job operation
+ is not supported.
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 64]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+3.1.3.2.7.1 Can documents be added to a restarted job?
+ Assume I give a Create-Job request along with a set of 5 documents .
+ All the documents get printed and the job state is moved to completed
+ . I issue a Restart-Job request on the job. Now the issue is that, if
+ I try to add new documents to the restarted job, will the IPP Server
+ permit me to do so or return "client-error-not-possible " and again
+ print those 5 jobs?
+
+ A job can not move to the 'completed' state until all the documents
+ have been processed. The 'last-document' flag indicates when the
+ last document for a job is being sent from the client. This is the
+ semantic equivalent of closing a job. No documents may be added once
+ a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
+ is moved to the 'pending' job state and restarts the beginning on the
+ same IPP Printer object with the same attribute values." 'number-of-
+ documents' is a job attribute.
+
+
+3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
+ 1.18)
+
+ 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.
+
+
+3.1.5 Sending empty attribute groups
+
+ The [RFC2911] and [RFC2910] 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 [RFC2910] 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.
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 65]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ There is an exception to the rule for Get-Jobs when there are no
+ attributes to be returned. [RFC2910] 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.
+
+
+3.2 Printer Operations
+
+
+3.2.1 Print-Job operation
+
+
+3.2.1.1 Flow controlling the data portion of a Print-Job request
+ (Issue 1.22)
+
+ 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.
+
+
+3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
+
+ 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".
+
+
+Hastings, et al. Expires July 25, 2001 [page 66]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 jobs "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.
+
+
+3.2.2 Get-Printer-Attributes operation
+
+ If a Printer supports the "printer-make-and-model" attribute and
+ returns the .INF file model name of the printer in that attribute,
+ the Microsoft client will automatically install the correct driver
+ (if available).
+
+ Clients which poll periodically for printer status or queued-job-
+ count should use the "requested-attributes" operation attribute to
+ limit the scope of the query in order to save Printer and network
+ resources.
+
+
+3.2.3 Get-Jobs operation
+
+
+3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
+ 1.39)?
+
+
+Hastings, et al. Expires July 25, 2001 [page 67]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ In [RFC2911] 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 too, and if it's not present what should the IPP
+ printer do?
+
+ [RFC2911] 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".
+
+
+3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
+
+ When using the Get-Jobs operation a client implementer might choose
+ to limit the number of jobs that the client shows on the first
+ screenful. For example, if its UI can only display 50 jobs, it can
+ defend itself against a printer that would otherwise return 500 jobs,
+ perhaps taking a long time on a slow dial-up line. The client can
+ then go and ask for a larger number of jobs in the background, while
+ showing the user the first 50 jobs. Since the job history is returned
+ in reverse order, namely the most recently completed jobs are
+ returned first, the user is most likely interested in the first jobs
+ that are returned. Limiting the number of jobs may be especially
+ useful for a client that is requesting 'completed' jobs from a
+ printer that keeps a long job history. Clients that don't mind
+ sometimes getting very large responses, can omit the "limit"
+ attribute in their Get-Jobs requests.
+
+
+3.2.4 Create-Job operation
+
+ A Printer may respond to a Create-Job operation with "job-state"
+ 'pending' or 'pending-held' and " job-state-reason" 'job-data-
+ insufficient' to indicate that operation has been accepted by the
+ Printer, but the Printer is expecting additional document data before
+ it can move the job into the 'processing' state. Alternatively, it
+ may respond with "job-state" 'processing' and "job-state-reason"
+ 'job-incoming' to indicate that the Create-Job operation has been
+ accepted by the Printer, but the Printer is expecting additional
+ Send-Document and/or Send-URI operations and/or is
+ accessing/accepting document data. The second alternative is for
+ non-spooling Printers that don't implement the 'pending' state.
+
+ Should the server wait for the "last-document" operation attribute
+ set to 'true' before starting to "process" the job?
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 68]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ It depends on implementation. Some servers spool the entire job,
+ including all document data, before starting to process, so such an
+ implementation would wait for the "last-document" before starting to
+ process the job. If the time-out occurs without the "last-document",
+ then the server takes one of the indicated actions in section 3.3.1
+ in the [RFC2911] document. Other servers will start to process
+ document data as soon as they have some. These are the so-called
+ "non-spooling" printers. Currently, there isn't a way for a client to
+ determine whether the Printer will spool all the data or will start
+ to process (and print) as soon as it has some data.
+
+
+3.3 Job Operations
+
+
+3.3.1 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.
+
+
+3.3.2 Restart-Job
+
+ The Restart-Job operation allows the reprocessing of a completed job.
+ Some jobs store the document data on the printer. Jobs created using
+ the Print-Job operation are an example. It is required that the
+ printer retains the job data after the job has moved to a 'completed
+ state' in order for the Restart-Job operation to succeed.
+
+ Some jobs contain only a reference to the job data. A job created
+ using the Print-URI is an example of such a job. When the Restart-
+ Job operation is issued the job is reprocessed. The job data MUST be
+ retrieved again to print the job.
+
+ It is possible that a job fails while attempting to access the print
+ data. When such a job is the target of a Restart-Job the Printer
+ SHALL attempt to retrieve the job data again.
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 69]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+4 Object Attributes
+
+
+4.1 Attribute Syntax's
+
+
+4.1.1 The 'none' value for empty sets (Issue 1.37)
+
+ [RFC2911] 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.
+
+
+4.1.2 Multi-valued attributes (Issue 1.31)
+
+ 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.
+
+
+4.1.3 Case Sensitivity in URIs (issue 1.6)
+
+ IPP client and server implementations must be aware of the diverse
+ uppercase/lowercase nature of URIs. RFC 2396 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.
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 70]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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
+ RFC 2396 and the HTTP/1.1 specifications [RFC2616]. 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.
+
+ Example of equivalent URI's
+
+ http://abc.com:80/~smith/home.html
+
+ http://ABC.com/%7Esmith/home.html
+
+ http:/ABC.com:/%7esmith/home.html
+
+ Example of equivalent URI's using the IPP scheme
+
+ ipp://abc.com:631/~smith/home.html
+
+ ipp://ABC.com/%7Esmith/home.html
+
+ http:/ABC.com:631/%7esmith/home.html
+
+ The HTTP/1.1 specification [RFC2616] contains more details on
+ comparing URLs.
+
+
+4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage
+
+ The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
+ that have two components. The first component is the 'language'
+ component that can contain up to 63 octets. The second component is
+ the 'text' or 'name' component. The maximum length of these are 1023
+ octets and 255 octets respectively. The definition of attributes
+ with either syntax may further restrict the length. (e.g. printer-
+ name (name(127)))
+
+ The length of the 'language' component has no effect on the allowable
+ length of 'text' in 'textWithLanguage' or the length of 'name' in
+ 'nameWithLanguage'
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 71]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+4.2 Job Template Attributes
+
+
+4.2.1 multiple-document-handling(type2 keyword)
+
+
+4.2.1.1 Support of multiple document jobs
+
+ 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" or multiple documents per job. IPP/1.1
+ was changed so that a Printer could support Create-Job without having
+ to support multiple document jobs. The "multiple-document-jobs-
+ supported" (boolean) Printer description attribute was added to
+ IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
+ supported' status code for a Printer to indicate whether or not it
+ supports multiple document jobs, when it supports the Create-Job
+ operation. Also IPP/1.1 was clarified that the Printer MUST support
+ the "multiple-document-handling" (type2 keyword) Job Template
+ attribute with at least one value if the Printer supports multiple
+ documents per job.
+
+
+4.3 Job Description Attributes
+
+
+4.3.1 Getting the date and time of day
+
+ The "date-time-at-creation", "date-time-at-processing", and "date-
+ time-at-completed" attributes are returned as dateTime syntax.
+ These attributes are OPTIONAL for a Printer to support. However,
+ there are various ways for a Printer to get the date and time of day.
+ Some suggestions:
+
+ 1. A Printer can get time from an NTP timeserver if there's one
+ reachable on the network . See RFC 1305. Also DHCP option 32 in
+ RFC 2132 returns the IP address of the NTP server.
+
+ 2. Get the date and time at startup from a human operator
+
+ 3. Have an operator set the date and time using a web
+ administrative interface
+
+ 4. Get the date and time from incoming HTTP requests, though the
+ problems of spoofing need to be considered. Perhaps comparing
+ several HTTP requests could reduce the chances of spoofing.
+
+ 5. Internal date time clock battery driven.
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 72]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
+
+
+
+4.4 Printer Description Attributes
+
+
+4.4.1 queued-job-count (integer(0:MAX))
+
+
+4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?
+
+ 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.
+
+
+4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is
+ (Issue 1.15)?
+
+ 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.
+
+
+4.4.2 printer-current-time (dateTime)
+
+ A Printer implementation MAY support this attribute by obtaining the
+ date and time by any number of implementation-dependent means at
+ startup or subsequently. Examples include:
+
+ 1. an internal date time clock,
+
+ 2. from the operator at startup using the console,
+
+ 3. from an operator using an administrative web page,
+
+ 4. from HTTP headers supplied in client requests,
+
+ 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 73]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 6. from the network, using NTP [RFC1305] or DHCP option 32
+ [RFC2132] that returns the IP address of the NTP server.
+
+ If an implementation supports this attribute by obtaining the current
+ time from the network (at startup or later), but the time is not
+ available, then the implementation MUST return the value of this
+ attribute using the out-of-band 'no-value' meaning not configured.
+ See the beginning of section 4.1.
+
+ Since the new "date-and-time-at-xxx" Job Description attributes refer
+ to the "printer-current-time", they will be covered also.
+
+
+4.4.3 Printer-uri
+
+ Must the operational attribute for printer-uri match one of the
+ values in "printer-uri-supported"?
+
+ A forgiving printer implementation would not reject the operation.
+ But the implementation has its rights to reject a printer or job
+ operation if the operational attribute printer-uri is not a value of
+ the printer-uri-supported. The printer might not be improperly
+ configured. The request obviously reached the printer. The printer
+ could treat the printer-uri as the logical equivalent of a value in
+ the printer-uri-supported. It would be implementation dependent for
+ which value, and associated security policy, would apply. This does
+ also apply to a job object specified with a printer-uri and job-id,
+ or with a job-uri. See section 4.1.3 for how to compare URI's.
+
+
+4.5 Empty Jobs
+
+ The IPP object model does not prohibit a job that contains no
+ documents. Such a job may be created in a number of ways including a
+ 'create-job' followed by an 'add-document' that contains no data and
+ has the 'last-document' flag set.
+
+ An empty job is processed just as any other job. The operation that
+ "closes" an empty job is not rejected because the job is empty. If
+ no other conditions exist, other than the job is empty, the response
+ to the operation will indicate success. After the job is scheduled
+ and processed, the job state SHALL be 'completed'.
+
+ There will be some variation in the value(s) of the "job-state-
+ reasons" attribute. It is required that if no conditions, other than
+ the job being empty, exist the "job-state-reasons" SHALL include the
+ 'completed-successfully'. If other conditions existed, the
+ 'completed-with-warnings' or 'completed-with-errors' values may be
+ used.
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 74]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+5 Directory Considerations
+
+
+5.1 General Directory Schema Considerations
+
+ The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
+ attributes for directory schemas. See [RFC2911] APPENDIX E: Generic
+ Directory Schema.
+
+ The SLP printer template is defined in the "Definition of the Printer
+ Abstract Service Type v2.0" document [svrloc-printer]. The LDAP
+ printer template is defined in the "Internet Printing Protocol (IPP):
+ LDAP Schema for Printer Services" document [ldap-printer]. Both
+ documents systematically add "printer-" to any attribute that doesn't
+ already start with "printer-" in order to keep the printer directory
+ attributes distinct from other directory attributes. Also, instead
+ of using "printer-uri-supported", "uri-authentication-supported", and
+ "uri-security-supported", they use a "printer-xri-supported"
+ attribute with special syntax to contain all of the same information
+ in a single attribute.
+
+
+5.2 IPP Printer with a DNS name
+
+ If the IPP printer has a DNS name should there be at least two values
+ for the printer-uri-supported attribute. One URL with the fully
+ qualified DNS name the other with the IP address in the URL?
+
+ The printer may contain one or the other or both. It's up to the
+ administrator to configure this attribute.
+
+
+6 Security Considerations
+
+ This section corresponds to the RFC2911 Section 8 "Security
+ Considerations.
+
+
+6.1 Querying jobs with IPP that were submitted using other job
+ submission protocols (Issue 1.32)
+
+ The following clarification was added to [RFC2911] section 8.5:
+
+ 8.5 Queries on jobs submitted using non-IPP protocols
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 75]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 were 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.
+
+
+7 Encoding and Transport
+
+ This section discusses various aspects of IPP/1.1 Encoding and
+ Transport [RFC2910].
+
+ 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.
+
+
+Hastings, et al. Expires July 25, 2001 [page 76]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
+ to throttle clients when Printers are busy. Therefore, it is
+ perfectly normal for an IPP client transmitting a Job to be blocked
+ for a really long time. Accordingly, socket timeouts must be
+ avoided. Some socket implementations have a timeout option, which
+ specifies how long a write operation on a socket can be blocked
+ before it times out and the blocking ends. A client should set this
+ option for infinite timeout when transmitting Job submissions.
+
+ Some IPP client applications might be able to perform other useful
+ work while a Job transmission is blocked. For example, the client
+ may have other jobs that it could transmit to other Printers
+ simultaneously. A client may have a GUI, which must remain
+ responsive to the user while the Job transmission is blocked. These
+ clients should be designed to spawn a thread to handle the Job
+ transmission at its own pace, leaving the main application free to do
+ other work. Alternatively, single-threaded applications could use
+ non-blocking I/O.
+
+ Some Printer conditions, such as jam or lack of paper, could cause a
+ client to be blocked indefinitely. Clients may open additional
+ connections to the Printer to Get-Printer-Attributes, determine the
+ state of the device, alert a user if the printer is stopped, and let
+ a user decide whether to abort the job transmission or not.
+
+ In the following sections, there are 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,
+
+
+Hastings, et al. Expires July 25, 2001 [page 77]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ - 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.
+
+7.1 General Headers
+
+ The following is a table for the general headers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 78]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+
+ General- Request Response Values and Conditions
+ Header
+
+
+
+ Client Server Server Client
+
+
+ Cache- must not must not "no-cache" only
+ Control
+
+ Connection must- must must- must "close" only. Both
+ if 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 RFC 1123 [RFC1123]
+ from RFC 2616 [RFC2616]
+
+ Pragma must not must not "no-cache" only
+
+ Transfer- must- must must- must "chunked" only . Header
+ Encoding if if MUST be present if
+ Content-Length is
+ absent.
+
+ Upgrade not not not not
+
+ Via not not not not
+
+
+7.2 Request Headers
+
+The following is a table for the request headers.
+
+
+ Request- Client Server Request Values and Conditions
+ Header
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 79]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+ Request- Client Server Request Values and Conditions
+ Header
+
+ Accept may must "application/ipp" only. This
+ value is the default if the client
+ omits it
+
+ Accept- not not Charset information is within the
+ Charset application/ipp entity
+
+ Accept- may must empty and per RFC 2616 [RFC2616]
+ Encoding and IANA registry for content-
+ codings
+
+ Accept- not not language information is within the
+ Language application/ipp entity
+
+ Authorization must- must per RFC 2616. A client MUST send
+ if this header when it receives a 401
+ "Unauthorized" response and does
+ not receive a "Proxy-
+ Authenticate" header.
+
+ From not not per RFC 2616. Because RFC
+ recommends sending this header
+ only with the user's approval, it
+ is not very useful
+
+ Host must must per RFC 2616
+
+ If-Match not not
+
+ If-Modified- not not
+ Since
+
+ If-None-Match not not
+
+ If-Range not not
+
+ If- not not
+ Unmodified-
+ Since
+
+ Max-Forwards not not
+
+ Proxy- must- not per RFC 2616. A client MUST send
+ Authorization if this header when it receives a 401
+ "Unauthorized" response and a
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 80]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+ Request- Client Server Request Values and Conditions
+ Header
+
+ "Proxy-Authenticate" header.
+
+ Range not not
+
+ Referrer not not
+
+ User-Agent not not
+
+
+7.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- may per RFC 2616. When URI needs
+ if redirection.
+
+ Proxy- not must per RFC 2616
+ Authenticate
+
+ Public may may per RFC 2616
+
+ Retry-After may may per RFC 2616
+
+ Server not not
+
+ Vary not not
+
+ Warning may may per RFC 2616
+
+ WWW- must- must per RFC 2616. When a server needs
+ Authenticate if to authenticate a client.
+
+
+7.4 Entity Headers
+
+The following is a table for the entity headers.
+
+
+Hastings, et al. Expires July 25, 2001 [page 81]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+
+ 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 RFC 2616 and
+ Encoding IANA registry for
+ content codings.
+
+ Content- not not not not Application/ipp
+ Language handles language
+
+ Content- must- must must- must the length of the
+ Length if if message-body per
+ RFC 2616. Header
+ MUST be present if
+ Transfer-Encoding
+ is absent..
+
+ Content- not not not not
+ Location
+
+ Content-MD5 may may may may per RFC 2616
+
+ 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
+
+
+7.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 [RFC2910] 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.
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 82]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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.
+
+
+7.6 HTTP/1.1 Chunking
+
+
+7.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.
+
+
+7.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 [RFC2616] 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.
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 83]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Because of this lack of conformance of HTTP servers to the HTTP/1.1
+ standard, the IPP standard [RFC2910] 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.
+
+
+8 References
+
+ [CGI]
+ CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11-
+ 00.txt).
+
+ [ldap-printer]
+ Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing
+ Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp-
+ ldap-printer-schema-01.txt>, work in progress, April 27, 2000.
+
+ [RFC793]
+ J. Postel, "Transmission Control Protocol", RFC 793.
+
+ [RFC1123]
+ Braden, S., "Requirements for Internet Hosts - Application and
+ Support", RFC 1123, October, 1989.
+
+ [RFC2026]
+ S. Bradner, "The Internet Standards Process -- Revision 3", RFC
+ 2026, October 1996.
+
+ [RFC2119]
+ S. Bradner, "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119 , March 1997.
+
+ [RFC2396]
+ Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+ [RFC2565]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
+ April 1999.
+
+ [RFC2566]
+ Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
+ Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
+
+ [RFC2567]
+
+
+Hastings, et al. Expires July 25, 2001 [page 84]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Wright, D., "Design Goals for an Internet Printing Protocol",
+ draft-ietf-ipp-req-03.txt, November, 1998.
+
+ [RFC2568
+ Zilles, S., "Rationale for the Structure and Model and Protocol for
+ the Internet Printing Protocol", RFC 2568, April 1999.
+
+ [RFC2569]
+ Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
+ LPD and IPP Protocols", RFC 2569, April 1999.
+
+ [RFC2616]
+ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
+ Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2910]
+ Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
+ Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000.
+
+ [RFC2911]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911,
+ September, 2000.
+
+ [Servlet]
+ Servlet Specification Version 2.1
+ (http://java.sun.com/products/servlet/2.1/index.html).
+
+
+ [svrloc-printer]
+ St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the
+ Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer-
+ scheme-06.txt>, work in progress, March 8, 2000.
+
+ [SSL]
+ Netscape, The SSL Protocol, Version 3, (Text version 3.02),
+ November 1996.
+
+
+9 Authors' Address
+
+
+ Thomas N. Hastings
+ Xerox Corporation
+ 701 Aviation Blvd.
+ El Segundo, CA 90245
+ hastings@cp10.es.xerox.com
+
+ Carl-Uno Manros
+
+
+Hastings, et al. Expires July 25, 2001 [page 85]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ Xerox Corporation
+ 701 Aviation Blvd.
+ El Segundo, CA 90245
+ manros@cp10.es.xerox.com
+
+ Carl Kugler
+ Mail Stop 003G
+ IBM Printing Systems Co
+ 6300 Diagonal Hwy
+ Boulder CO 80301
+ Kugler@us.ibm.com
+
+ Henrik Holst
+ i-data Printing Systems
+ Vadstrupvej 35-43
+ 2880 Bagsvaerd, Denmark
+ hh@I-data.com
+
+
+ Peter Zehler
+ Xerox Corporation
+ 800 Philips Road
+ Webster, NY 14580
+ peter.zehler@usa.xerox.com
+
+10 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.
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 86]
+\f
+
+INTERNET-DRAFT IPP/1.1: Implementer's Guide January 25, 2001
+
+
+ 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 RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires July 25, 2001 [page 87]
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT
-<draft-ietf-ipp-indp-00.txt>
- Hugo Parra
- Novell, Inc.
- Tom Hastings
- Xerox Corporation
- March 9, 2000
-
- Internet Printing Protocol (IPP):
-
- IPP Notification Delivery Protocol (INDP)
-
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [rfc2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-
-The IPP event notification specification [ipp-ntfy] is an OPTIONAL
-extension to IPP/1.0, IPP/1.1, and future versions. [ipp-ntfy] which
-enables IPP clients to request notification of printer and job events.
-The IPP notification extension gives IPP Printers the flexibility to
-choose how many Subscriptions objects (individual requests for
-notification), what delivery methods, and what natural languages to
-support, among others. In practice, it's the working environment where
-an IPP Printer is deployed what ultimately dictates the notification
-requirements for that printer. Notification Delivery Services exist to
-help event producers, such as IPP Printers, meet the varying
-notification needs of disparate environments. Specifically, an IPP
-Notification Delivery Service may extend the notification capabilities
-of IPP Printers and help customize the type of notification required in
-
-Parra, Hastings [page 1]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-a highly specialized environment. This documents defines the IPP
-Notification Delivery Protocol (INDP), a protocol for IPP Printers to
-communicate with Notification Delivery Services using "application/ipp"
-as the encoding mechanism and HTTP as the transport. The definition of
-INDP lends itself nicely for use by IPP Printers and Notification
-Delivery Services for dispatching IPP Notifications to Notification
-Recipients as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 2]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
- Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting a message body over
-HTTP whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 3]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-
-
-
- Table of Contents
-
-
-1 Introduction ......................................................6
-
-2 Terminology .......................................................6
-
-3 Model and Operation ...............................................7
- 3.1 NOTIFICATION DELIVERY SERVICE MODEL..............................7
- 3.1.1 Server Object ...............................................7
- 3.1.2 Subscription Object .........................................8
- 3.2 NOTIFICATION DELIVERY SERVICE OPERATION..........................8
- 3.2.1 Notification without Notification Delivery Services .........9
- 3.2.2 Delivery method support extension (INDPa) ..................11
- 3.2.3 Natural language support extension (INDPb) .................12
- 3.2.4 Subscription object management outsource (INDPc) ...........12
-
-4 Notification Operations ..........................................15
- 4.1 GET-NOTIFY-SERVICE-ATTRIBUTES...................................15
- 4.1.1 Get-Notify-Service-Attributes Request ......................16
- 4.1.2 Get-Notify-Service-Attributes Response .....................16
- 4.2 VALIDATE-NOTIFY-TARGET-URI OPERATION............................17
- 4.2.1 Validate-Notify-Target-Uri Request .........................17
- 4.2.2 Validate-Notify-Target-Uri Response ........................17
- 4.3 SEND-NOTIFICATIONS OPERATION....................................18
- 4.3.1 Send-Notifications Request .................................18
- 4.3.2 Send-Notifications Response ................................20
- 4.4 REGISTER-NOTIFICATION-SOURCE OPERATION..........................20
- 4.4.1 Register-Notification-Source Request .......................21
- 4.4.2 Register-Notification-Source Response ......................21
- 4.5 CANCEL-NOTIFICATION-SOURCE-REGISTRATION OPERATION...............22
- 4.5.1 Cancel-Notification-Source-Registration Request ............22
- 4.5.2 Cancel-Notification-Source-Registration Response ...........23
- 4.6 RENEW-NOTIFICATION-SOURCE-REGISTRATION OPERATION................23
- 4.6.1 Renew-Notification-Source-Registration Request .............23
- 4.6.2 Renew-Notification-Source-Registration Response ............24
- 4.7 CREATE-SUBSCRIPTION OPERATION...................................24
- 4.7.1 Create-Subscription Request ................................24
- 4.7.2 Create-Subscription Response ...............................25
- 4.8 VALIDATE-SUBSCRIPTION OPERATION.................................25
- 4.8.1 Validate-Subscription Request ..............................25
- 4.8.2 Validate-Subscription Response .............................26
- 4.9 CANCEL-SUBSCRIPTION OPERATION...................................26
- 4.9.1 Cancel-Subscription Request ................................26
- 4.9.2 Cancel-Subscription Response ...............................26
- 4.10 RENEW-SUBSCRIPTION OPERATION ..................................27
- 4.10.1 Renew-Subscription Request ................................27
- 4.10.2 Renew-Subscription Response ...............................28
- 4.11 GET-SUBSCRIPTIONS OPERATION ...................................28
-
-Parra, Hastings [page 4]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- 4.11.1 Get-Subscriptions Request .................................28
- 4.11.2 Get Subscriptions Response ................................28
-
-5 Encoding of the Operation Layer ..................................28
- 5.1 NEW ATTRIBUTE TAG...............................................29
- 5.2 NEW STATUS CODES................................................29
- 5.2.1 unknown-notification-recipient. (0xXXX) ....................29
- 5.2.2 unable-to-delivery-notification-report (0xXXX) .............29
- 5.2.3 successful-ok-but-cancel-subscription (0xXXXX) .............29
- 5.2.4 unknown-registration-id (0xXXX) ............................30
- 5.2.5 successful-ok-but-error-accessing-persistent-storage () ....30
- 5.3 ENCODING........................................................30
-
-6 Encoding of Transport Layer ......................................31
-
-7 IANA Considerations ..............................................32
-
-8 Internationalization Considerations ..............................33
-
-9 Security Considerations ..........................................33
- 9.1 SECURITY CONFORMANCE............................................33
-
-10 References .......................................................34
-
-11 Author's Addresses ...............................................34
-
-12 Full Copyright Statement .........................................35
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 5]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-
-
-
-1 Introduction
-
-An IPP Printer that supports the OPTIONAL IPP event notification
-extension [ipp-ntfy] is called a Notification Source which sends event
-Notifications to Notification Recipients. As such, a Printer either a)
-accepts, stores, and uses notification Subscription objects to generate
-event Notifications and implements one or more delivery methods for
-notifying interested parties, or b) supports a subset of these tasks and
-farms out the remaining tasks to a Notification Delivery Service. The
-IPP Notification Delivery Protocol (INDP) specified in this document is
-a request/response protocol that may be used in a variety of
-notification scenarios. Its primary intended use is for IPP Printers to
-engage the assistance of Notification Delivery Services for storing
-notification Subscriptions, generating human-readable notifications in
-various languages, and implementing additional delivery methods.
-Moreover, IPP Printers and Notification Delivery Services in their role
-as Notification Sources may use INDP to send (push) event notifications
-to Notification Recipients.
-
-
-2 Terminology
-
-This document uses terms such as "attributes", "keywords", and
-"support". These terms have special meaning and are defined in the
-model terminology [ipp-mod] section 12.2.
-
-
-Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
-MAY, NEED NOT, and OPTIONAL, have special meaning relating to
-conformance. These terms are defined in [ipp-mod] section 12.1 on
-conformance terminology, most of which is taken from RFC 2119 [RFC2119].
-
-
-This section defines the following additional terms that are used
-throughout this document:
-
- REQUIRED: if an implementation supports the extensions described in
- this document, it MUST support a REQUIRED feature.
- OPTIONAL: if an implementation supports the extensions described in
- this document, it MAY support an OPTIONAL feature.
- Event Notification (Notification for short) - See [ip-ntfy]
- Notification Source - See [ipp-ntfy]
- Notification Recipient - See [ipp-ntfy]
- Subscription object - See [ipp-ntfy]
- Ultimate Notification Recipient - See [ipp-ntfy]
-
-
-
-
-
-Parra, Hastings [page 6]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-3 Model and Operation
-
-In the IPP Notification Model [ipp-ntfy], print clients request an IPP
-Printer for event notification by causing a Subscription object to be
-created at the printer. [ipp-ntfy] specifies a number of ways in which
-Subscription objects can be created. Each Subscription object lists the
-events of interest, the delivery method to be employed, and the address
-to which notifications should be dispatched, among others. When an
-event occurs, the printer is responsible for notifying each Notification
-Recipient that has registered interest in that event, using delivery
-method requested by that Notification Recipient. IPP Printers may
-employ the assistance of Notification Delivery Services to accomplish
-some or all of these tasks.
-
-
-IPP Printers with support for Notification Delivery Services must
-support a new printer description attribute, "notification-delivery-
-services-uri-supported" (1SetOf uri). This attribute needs to be
-populated with the uri's of the Notification Delivery Services the
-printer is configured to use. Whether IPP Printers dynamically discover
-Notification Delivery Services on the network or need to be configured
-by a system administrator it implementation dependant.
-
-
-3.1 Notification Delivery Service Model
-
-
-The INDP 1.0 model defines objects of type Server and Subscription.
-Each object definition includes a set of attributes that describe the
-state and workings of a Notification Delivery Service. An IPP Printer
-interact with instances of these object types by issuing INDP
-operations. This section describes the attributes that compose the
-Server and Subscription objects with their corresponding attribute
-syntaxes and values that are part of the Notification Delivery Service
-Model. Each attribute is uniquely identified in this document using a
-"keyword" as defined in the IPP/1.1: Model and Semantics document [ipp-
-mod]. INDP 1.0 defines The Notification Delivery Service
-
-
-3.1.1Server Object
-
-The Server object represents the state and capabilities of a
-Notification Delivery Service. It implements the server-side of INDP.
-In version 1.0 of INDP, the Server object contains information about the
-capabilities of a Notification Delivery Service that are of interest to
-an IPP Printer.
-
-The following attributes comprise the Server object. Their description
-and intended use follow.
-
- - notify-natural-languages-supported
- - notify-uri-schemes-supported
-
-Parra, Hastings [page 7]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-3.1.1.1 notify-natural-languages-supported (1setOf naturalLanguage)
-
-This REQUIRED Server object attribute describes the natural languages
-supported by the Notification Delivery Service for the generation of
-human-consumable Notifications.
-
-
-3.1.1.2 notify-uri-schemes-supported (1setOf uriScheme)
-
-This REQUIRED Server object attribute describes the notification
-delivery methods supported by the Notification Delivery Service.
-Standard values are defined in [ipp-ntfy] Section 5.1.
-
-
-3.1.2Subscription Object
-
-The Subscription object represents a request for notification.
-Subscription Objects are contained by a Server object and are created as
-a result of an IPP Printer issuing a Create-Subscription operation. The
-syntax and semantics of a Subscription object exactly mirror those of
-the Subscription object defined in the IPP Notification spec [ipp-ntfy].
-
-
-3.2 Notification Delivery Service Operation
-
-
-The figure below illustrates four different configurations through which
-an IPP Printer may implement support for IPP notification. Each
-configuration is discussed in this section.
-
-
-
-
-Legend:
-
-INDPx represents three different subsets of INDP operations the IPP
- Printer uses to communicate with the Notification Delivery
- Service to realize three different levels of support.
-
-any represents any protocol, including INDP, that the IPP Printer
- or the Notification Delivery Service may support for notifying
- interested Notification Recipients.
-
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 8]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- O +------+ +-----------+
-
- /|\ |client| --IPP--> |IPP Printer|
- / \ +------+ +-----------+
- ^ |
- +-------any-------+
-
- Notification Dlvry. Svc.
- +-----------+
- +------INDPa------> | Extended |
- O +------+ +-----------+ / +--+ Support |
- /|\ |client| --IPP--> |IPP Printer| | for |
- / \ +------+ +-----------+ +---+ Delivery |
- ^ | Methods |
- \ +-------------------+
- \ |
- +-----------------------any-----------------------+
-
- Notification Dlvry. Svc.
- +-----------+
- | Extended |
- O +------+ +-----------+ +--+ Support |
- /|\ |client| --IPP--> |IPP Printer| -----INDPb-----> | for |
- / \ +------+ +-----------+ +---+ Natural |
- ^ | Languages |
- \ +-------------------+
- \ |
- +-----------------------any-----------------------+
-
- Notification Dlvry. Svc.
- +-----------+
- | Extended |
- O +------+ +-----------+ +---+ Support |
- /|\ |client| --IPP--> |IPP Printer| | for |
- / \ +------+ +-----------+ \ +---+ Subscription|
- ^ +--INDPc--> | Objects |
- \ +-------------------+
- \ |
- +-----------------------any-----------------------+
-
-
-3.2.1 Notification without Notification Delivery Services
-
-
-An IPP Printer working without the assistance of a Notification Delivery
-Service must implement on its own at least the minimum set of
-functionality required by the IPP Notification spec. This section gives
-a summary of the process a typical IPP Printer may employ to support IPP
-notifications on its own. The IPP Notification spec [ipp-ntfy] provides
-a detailed description of this process. Subsequent sections will
-describe how an IPP Printer may use INDP to indirectly accomplish some
-of the following tasks.
-
-Parra, Hastings [page 9]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-a)Creating a Subscription object. The IPP notification spec [ipp-ntfy]
- describes a number of mechanisms for IPP clients to request
- notification of an IPP printer. The end result, however, is that a
- Subscription object is instantiated at the IPP printer containing the
- information needed by the printer to know who to notify, how, and of
- what events.
-
-
-b)Validating the Subscription object. At Subscription object
- instantiation time, the IPP printer validates its contents to make
- sure the requested events and delivery methods are supported. The
- IPP printer may also perform some validation on the recipient uri,
- requested natural language, and other information contained in the
- Subscription object.
-
-
-c)Storing the Subscription object. The IPP printer provides persistent
- and non-persistent storage for Subscription objects until de object's
- lease expires (in the case of per-printer subscriptions) or their
- associated print job is removed (in the case of per-job
- subscriptions). The IPP notification spec [ipp-ntfy] outlines the
- minimum number of Subscription objects a printer MUST be able to
- store. In practice, this requirement will vary widely depending on
- the administrative practices and usage patterns of the printer's
- users.
-
-
-d)Event condition. Normal printer operation as well as printer
- exception circumstances will cause event conditions to be raised.
-
-
-e)Matching event with subscriptions. For each raised event condition
- the printer finds all the Subscription objects that request
- notification of that event. Rather than inspecting each Subscription
- object each time an event condition is raised, an IPP Printer may
- keep a list of the events the combined Subscription objects have
- requested to quickly discard event conditions no one is interested
- in.
-
-
-f)Generating human-readable notification data. The IPP Printer
- examines each Subscription object found in step (e) to determine if
- it needs to generate human-readable notification information for it.
- IPP Printers with users of different language preferences may need to
- provide translation for multiple natural languages.
-
-
-g)Dispatching the notification via the specified delivery method. The
- IPP Printer may need to generate slightly different Notification
- payloads for different delivery methods. With Notifications
- generated for each target Recipient, the IPP Printer uses its
- implementation of the delivery method specified in the corresponding
-
-Parra, Hastings [page 10]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- Subscription object to dispatch the notification to its intended
- Recipient.
-
-
-Though in this scenario the IPP Printer does not need to interact with a
-Notification Delivery Service, it may use INDP to dispatch Notifications
-encoded in "application/ipp" and transported over HTTP to interested
-notification Recipients. IPP Printers may use the Send-Notifications
-operation to accomplish this task.
-
-
-3.2.2 Delivery method support extension (INDPa)
-
-
-An IPP Printer may use a Notification Delivery Service simply to extend
-the list of delivery methods it supports. Doing so offloads a printer
-from having to implement all the common delivery methods its potential
-clients might require. It also enables a generic printer to support
-very specialized delivery methods implemented by a site's Notification
-Delivery Service. Moreover, by using existing Notification Delivery
-Methods, an IPP Printer can take advantage of present, widely deployed
-notification infrastructure, standards-based or proprietary.
-
-
-Using a Notification Delivery Service for the sole purpose of extending
-the notification delivering capabilities on and IPP Printer results in
-very small changes to the notification process described in the previous
-section. Specifically, the following changes apply.
-
-
-1)Before accepting requests to create Subscription objects, step (a)
- above, the IPP Printer gets a list of the uri schemes the
- Notification Delivery Service supports and adds the values to its
- "notify-schemes-supported" attribute. To obtain this list, the IPP
- Printer uses the Get-Notify-Service-Attributes operation requesting
- the "notify-schemes-supported" attribute from the Notification
- Delivery Service. To an IPP client reading the printer's "notify-
- schemes-supported" attribute, the entries with internal support and
- those supported via a Notification Delivery Service are
- indistinguishable.
-
-
-2)During Subscription object validation, step (b) above, the IPP
- Printer may communicate with the Notification Delivery Service to
- validate a target uri requesting a delivery method implemented in the
- Notification Delivery Service. This IPP Printer accomplishes through
- the Validate-Notification-Uri operation.
-
-
-3)For dispatching notifications that require a delivery method
- implemented in the Notification Delivery Service, step (g) above, the
- IPP Printer forwards the Notification on to the Notification Delivery
-
-Parra, Hastings [page 11]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- Service through the Send-Notifications operation. The IPP Printer
- must provide the target uri and human-readable data, when the case
- requires it. The Notification Delivery Service is then responsible
- for creating a Notification payload suitable for the requested
- delivery method and for dispatching the notification to the specified
- Recipient.
-
-
-3.2.3 Natural language support extension (INDPb)
-
-
-An IPP Printer may use a Notification Delivery Service to generate
-human-readable notification data in addition to extending its delivery
-methods support. By using a Notification Delivery Service in this
-manner, an IPP Printer can dynamically support notifications in any
-number of natural languages, as long as the Notification Delivery
-Service being used supports them.
-
-
-In addition to the modifications to the notification process listed in
-section 3.2, the following changes result from using a Notification
-Delivery Service to generate human-readable notification data.
-
-
-1)Before accepting requests to create Subscription objects, step (a)
- above, the IPP Printer must communicate with the Notification
- Delivery Service to get a list of the natural languages it supports
- for human-readable message generation and add these values to its own
- "notify-natural-languages-supported" attribute.
-
-
-ISSUE 01: Do we have any use for the printer description attribute
-"notify-natural-languages-supported"?
-
-
-2)The IPP Printer no longer needs to perform steps (f) and (g) above.
- Instead it uses the Send-Notifications operation to send the
- Notification to the Notification Delivery Service along with the
- language specified in the corresponding Subscription object.
-
-
-3.2.4 Subscription object management outsource (INDPc)
-
-
-Through INDP an IPP Printer can employ the full services of a
-Notification Delivery Service, which includes storing and managing
-Subscription objects on behalf of the printer. Outsourcing this type of
-functionality greatly reduces the logic and resources requirements for
-an IPP Printer to support notification. Suitably hosted Notification
-Delivery Services can meet the notification needs of an environment
-without having to increase the capabilities of each printer in that
-
-
-Parra, Hastings [page 12]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-environment. This section describes how an IPP Printer interacts with a
-Notification Delivery Service to accomplish this level of interaction.
-
-
-This notification configuration requires the IPP Printer to establish a
-temporary registration with the Notification Delivery Service. Through
-a lease-based relationship, the Notification Delivery Service can keep
-track of what Subscription objects belong to what IPP Printer and
-generate the appropriate notifications when events are reported. This
-mechanism also enables the Notification Delivery Service to clean up
-orphaned Subscription objects. The IPP Printer uses the Register-Event-
-Producer operation to establish this type of relationship with the
-Notification Delivery Service. The model requires that an IPP Printer
-renew its lease periodically using the Renew-Registration operation.
-
-
-When registering, an IPP Printer can specify a location for a
-Notification Delivery Service to store Subscription objects
-persistently. Subscription objects stored persistently in previous
-registrations are automatically re-instantiated when an IPP Printer
-registers with a Notification Delivery Service. The printer instructs
-the Notification Delivery Service what Subscription objects should be
-stored persistently and which one should be automatically disposed when
-the registration expires.
-
-
-Once registered, the IPP Printer may forward requests to create
-Subscription objects on to the Notification Delivery Service. The IPP
-Printer uses the Create-Subscription operation to accomplish this task.
-
-
-In this notification configuration an IPP Printer only needs to keep
-track of the superset of events requested by all the Subscription
-objects combined. The Notification Delivery Service assists the IPP
-Printer accomplish this task. First, in the response of a successful
-registration request, the Notification Delivery Service returns to the
-printer the list of events that it must generate to satisfy any
-Subscription objects that might have been reinstated from persistent
-storage. Then, in the response to every successful request to add or
-delete Subscription objects, the Notification Delivery Service returns
-to the printer a list of the new events needed and those to be
-discontinued as a result of the operation.
-
-
-The following summarizes an IPP Printer's process for handling
-notification when making full use of a Notification Delivery Service's
-capabilities. For simplification, the description assumes that the IPP
-Printer supports these capabilities only via a Notification Delivery
-Service and not directly. However, for printers that implement some
-delivery methods internally and support others through a Notification
-Delivery Service, the notification process is a combination of the
-process outlined below and the one summarized in section 3.1.1.
-
-Parra, Hastings [page 13]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-a)Register with Notification Delivery Service. Early in its
- initialization process the IPP Printer should use the Register-Event-
- Producer operation to register with a Notification Delivery Service
- if configured to do so. It must indicate to the Notification
- Delivery Service the location of its persistent Subscription object
- storage, if applicable. The IPP Printer must store away the
- registration Id returned by the operation and remember any events
- listed in the response so it can start generating them.
-
-
-b)Get Notification Delivery Service information. Right after
- registering with a Notification Delivery Service, the IPP Printer
- should query the Notification Delivery Service's "notify-uri-schemes-
- supported" and "notify-natural-languages-supported" attributes. The
- printer must populate its "notify-uri-schemes-supported" and "notify-
- natural-languages-supported" attributes with the information
- obtained.
-
-
-c)Create Subscription objects. When the IPP Printer receives a client
- request to create a new Subscription object, it must forward the
- request to the Notification Delivery Service using the Create-
- Subscription operation. This results in the Notification Delivery
- Service instantiating and validating a Subscription object. If the
- operation to create a new Subscription object succeeds, its response
- portion will tell the IPP Printer what, if any, new events it must
- generate to satisfy the new request. As with print jobs Subscription
- objects do not become active while the job is in "job-pending" state,
- the IPP Printer would not send a request to create a new Subscription
- object to the Notification Delivery Service until just before the job
- changes states from "job-pending". For these types of notification
- requests, the IPP Printer may instead issue the Validate-Subscription
- operation to request that the Notification Delivery Service simply
- validate the request, thus allowing the printer to return an accurate
- status code to IPP operations requesting per-job notifications.
-
-
-d)Event condition. The IPP Printer uses the consolidated list of
- events it maintains with the help of the Notification Delivery
- Service to know what events are of interest.
-
-
-e)Send event report. When the IPP Printer raises an event condition,
- it reports the event to the Notification Delivery Service using the
- Send-Notification operation. At that point the IPP Printer is
- finished processing the event condition. The Notification Delivery
- Service is responsible for matching the event with the Subscription
- objects that requested it, generating any human-consumable data in
- the natural language specified in the Subscription object, and
- dispatching the appropriately formatted Notification using the
- requested delivery method.
-
-
-Parra, Hastings [page 14]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-4 Notification Operations
-
-INDP makes extensive use of the operations model defined by IPP
-[rfc2566]. This includes, the use of a URI as the identifier for the
-target of each operation, the inclusion of a version number, operation-
-id, and request-id in each request, and the definition of attribute
-groups. INDP operations use the Operation Attributes group, but
-currently have no need for the Unsupported Attributes, Printer Object
-Attributes, and Job-Object Attributes groups. However, it uses a new
-attribute group, the Notification Attributes group.
-
-
-The following operations form version 1.0 of INDP. All operations are
-targeted at the Server object. This section formally defines each INDP
-1.0 operation.
-
- - Get-Notify-Service-Attributes
- - Validate-Notify-Target-Uri,
- - Send-Notifications
- - Register-Notification-Source
- - Cancel-Notification-Source-Registration
- - Renew-Notification-Source-Registration
- - Create-Subscription
- - Validate-Subscription
- - Cancel-Subscription
- - Renew-Subscription
- - Get-Subscriptions
-
-Every operation request contains the following REQUIRED parameters (see
-[ipp-mod] section 3.1.1):
-
- - a "version-number"
- - an "operation-id"
- - a "request-id"
-
-Every operation response contains the following REQUIRED parameters (see
-[ipp-mod] section 3.1.1}:
-
- - a "version-number"
- - a "status-code"
- - the "request-id" that was supplied in the corresponding request
-
-4.1 Get-Notify-Service-Attributes
-
-
-This REQUIRED operation allows an IPP Printer to request the values of
-attributes of a Server object. In the request, the IPP Printer supplies
-the set of Server attribute names it's interested in. In the response,
-the Service object returns a corresponding attribute set with the
-appropriate attribute values filled in.
-
-
-
-Parra, Hastings [page 15]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-4.1.1 Get-Notify-Service-Attributes Request
-
-The following sets of attributes are part of the Get-Service-Attributes
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- "server-uri":
- The URI of the Notification Delivery Service.
-
- "requested attributes" (1setOf keyword):
- The IPP Printer OPTIONALLY supplies a set of attribute names
- in whose values the requester is interested. The Service
- object MUST support this attribute. If the IPP Printer omits
- this attribute, the Notification Delivery Service MUST respond
- with a list of all the attributes it supports and it
- respective values.
-
-4.1.2 Get-Notify-Service-Attributes Response
-
-
-The Server object returns the following sets of attributes as part of
-the Get-Notify-Service-Attributes Response:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
-Group 2: Unsupported Attributes
-
- A list of the attribute names requested by the IPP Printer but not
- supported by the Service object. See [rfc 2566] section 3.1.7 for
- details on returning Unsupported Attributes. As in version 1.0 of
- INDP all defined Service object attributes are mandatory, this
- group is a forward-looking feature when new OPTIONAL attributes may
- be defined.
-
-Group 3: Server Object Attributes
-
- This is the set of requested attributes and their current values.
- The Server object ignores any requested attribute that is not
- supported. The Service object MAY respond with a subset of the
- supported attribute and valued, depending on the security policy in
- force. However, the Service object MUS respond with the 'unknown'
- value for any supported attribute for which the Service object does
-
-
-Parra, Hastings [page 16]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- not know the value. For a description of "out-of-band" values see
- [rfc 2566] section 4.1.
-
-4.2 Validate-Notify-Target-Uri Operation
-
-
-This REQUIRED operation allows an IPP Printer to request that the
-Notification Delivery Service validate a notification target uri. The
-Service object successfully validates the uri if the Notification
-Delivery Service implements the delivery method implied by the uri
-scheme or the target uri. The Service object is free to perform
-extended analysis on the validity of the recipient's address provided in
-the uri is the semantics of the delivery method so allow.
-
-
-4.2.1 Validate-Notify-Target-Uri Request
-
-The following sets of attributes are part of the Validate-Notify-Target-
-Uri Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- "server-uri":
- The URI of the Notification Delivery Service.
-
- "notify-target-uri" (uri):
- The IPP Printer MUST supply this attribute. The Notification
- Delivery Service MUST support this attribute. It is the uri
- to be validated by the Server object.
-
-4.2.2 Validate-Notify-Target-Uri Response
-
-
-The Server object returns the following set of attributes as part of the
-Validate-Notify-Target-Uri Response:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
-
-
-
-
-
-
-
-Parra, Hastings [page 17]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- "validation-code" (boolean):
- The Server object MUST return this attribute with a value of
- TRUE if the notify-target-uri was validates successfully;
- FALSE otherwise.
-
-4.3 Send-Notifications Operation
-
-
-This REQUIRED operation allows an IPP Printer to send one or more
-Notifications to a Notification Delivery Service. The Send-Notification
-operation can be used to transport Notification data in all four
-notification configurations described in section 3.2. Different
-attributes will be required depending on whether the operation is being
-used a) by an IPP Printer or Notification Delivery Service to send
-Notifications directly to a notification Recipient, b) by an IPP Printer
-to Send a localized Notification to a Notification Delivery Service
-(INDPa), c) by an IPP Printer to Send a Notification to be localized and
-dispatched by the Notification Delivery Service (INDPb), or d) by an IPP
-Printer to send a target-less notification using an established
-registration to a Notification Delivery Service (INDPc).
-
-
-Both Machine-Consumable and Human-Consumable notifications may be
-included in the Send-Notification operation.
-
-
-4.3.1 Send-Notifications Request
-
-
-The following groups of attributes are part of the Send-Notifications
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
- Target:
- The Target can a) The URI of the Notification Delivery Service
- if an IPP Printer is using Send-Notifications to dispatch
- notifications, or b) the URI of the Notification Recipient if
- the IPP Printer or the Notification Delivery Service are using
- the operation to dispatch notifications directly to a
- Notification Recipient.
-
- "ultimate-target-uri":
- This attribute MUST be supplied by the IPP Printer when it
- uses the Send-Notifications operation to send notifications to
- a Notification Delivery Service without having registered as a
- Notification Source, i.e., configurations INDPa and INDPb
- above.
-
-Parra, Hastings [page 18]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-
- "registration-id":
- This attribute MUST be supplied by the IPP Printer when it
- uses the Send-Notifications operation to send notifications to
- a Notification Delivery Service after having registered a as a
- Notification Source, i.e., configuration INDPc above.
-
-
-Group 2 to N: Notification Attributes
-
- "human-readable-report" (text)
- The Notification Source OPTIONALLY supports this attribute.
- This attribute is a text string generated by the IPP printer
- or Notification Delivery Service from the contents of the IPP
- Notification suitable for human consumption. If the
- Notification Source supports this attribute, it MUST supply
- this attribute if the Subscription object contains the
- "notify-text-format" (mimeMediaType) attribute. The text
- value of this attribute MUST be localized in the charset
- identified by the "notify-charset" (charset) attribute and the
- natural language identified by the notify-natural-language"
- (naturalLanguage) attribute supplied in the associated
- Subscription object that generates this event Notification.
- The format of the text value is specified by the value of the
- "notify-text-format" (mimeMediaType) supplied in the
- associated Subscription object.
-
- "human-readable-report-format" (mime)
- This attribute MUST be supplied by the Notification Source
- whenever the "human-readable-report" attribute is present. It
- indicates the format, e.g., text/plain, text/html, etc. of the
- "human-readable-report" attribute.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 19]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- All of the REQUIRED attributes and any of the OPTIONAL attributes
- indicated in [ipp-ntfy] for a Push event Notification, including
- "notify-text-format-type" (mimeMediaType), if the "human-readable-
- report" (text) attribute is included, so that the Notification
- Recipient will know the text format of the "human-readable-report"
- (text) attribute value. These attributes communicate the same
- information as the notification attributes by the same name
- described in sections 7.4, 7.5, and 7.6 of [ipp-ntfy].
-
- The rules that govern when each individual attribute MUST or MAY be
- included in this operation precisely mirror those specified in
- [ipp-ntfy] with the following exception: if the Send-Notifications
- operation is being used by an IPP Printer to communicate events to
- a Notification Delivery Service using a "registration-id", Group 2
- of this operation MUST only include the "trigger-event", "trigger-
- time", and "trigger-date-time" Notification attributes.
-
-4.3.2 Send-Notifications Response
-
-
-The target of the Send-Notifications operation, Notification Delivery
-Method or Notification Recipient, returns a status code for the entire
-operation and one for each Notification Report in the request if the
-operation's status code is other than "success-ok". If the Notification
-Recipient receives a Notification report that it can't pair up with a
-subscription it knows about, it can return an error status-code to
-indicate that events associated with that subscription should no longer
-be sent to it.
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
-Group 2 to N: Notification Attributes
-
- "notification-report-status-code" (type2 enum)
- Indicates whether the intended target, i.e., Notification
- Delivery Service or Notification Recipient was able to consume
- the n-th Notification Report.
-
-4.4 Register-Notification-Source Operation
-
-
-This REQUIRED operation allows an IPP Printer to register itself as a
-Notification Source with a Notification Delivery Service. While
-registered, the Printer can add Subscription objects to the Server
-object. The Printer can then send Notifications to the Server object
-for the Server object to dispatch Notifications to all interested
-Recipients.
-
-
-Parra, Hastings [page 20]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-4.4.1 Register-Notification-Source Request
-
-The following sets of attributes are part of the Register-Notification-
-Source Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- "server-uri":
- The URI of the Notification Delivery Service.
-
- "registration-lease-time-requested" (integer(0:86,400)):
- This REQUIRED attribute specifies the time in the future when
- the IPP Printer would like its registration lease to expire.
- When the Server object accepts a Registration request, it
- keeps track of this information. When the expiration time
- arrives, the Server object purges the registration.
-
- An IPP Printer is able to extend its registration lease using
- the Renew-Notification-Source-Registration operation. The
- maximum value for a registration lease is one day.
-
- "notification-source-name" (name(127)):
- This REQUIRED attribute specifies the name of the IPP Printer.
- The Server object may use this information to organize current
- registrations. This information may also be useful to a
- Notification Delivery Service's manager. Note: Management of
- a Notification Delivery Service is outside the scope of INDP
- v1.0.
-
- "persistent-registration-storage-uri" (uri):
- Through this OPTIONAL attribute an IPP Printer may communicate
- to the Service object where to retrieve persistent
- Subscriptions from previous registrations. The Service object
- also uses this location to store away future persistent
- Subscriptions. It the IPP Printer doesn't provide this
- attribute, it will not be able to add Subscription objects
- that require persistent storage.
-
-4.4.2 Register-Notification-Source Response
-
-
-The Server object returns the following set of attributes as part of the
-Register-Notification-Source Response:
-
-Group 1: Operation Attributes
-
-
-
-
-Parra, Hastings [page 21]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
- "registration-id" (integer(0:MAX)):
- The Server object MUST return the registration ID that the IPP
- Printer can use in subsequent calls such as Renew-
- Notification-Source-Registration, Create-Subscription, etc.
-
- "notify-events" (1setOf type2 keyword):
- If in this operation's request the IPP Printer specifies a
- "persistent-registration-storage-uri" and as a result one or
- more Registrations are instantiated by the Server object
- during registrations, this attribute MUST contain the list of
- events that the printer must notify the Server object of to
- satisfy those Subscriptions.
-
- "registration-lease-expiration-time" (integer(0:86,400)):
- This REQUIRED attribute specifies the time in the future when
- the registration lease will expire. If the Server object is
- not able to grant the lease-time requested by the IPP Printer,
- this attribute may contain a different value that the one
- provided in the request.
-
- An IPP Printer is able to extend its registration lease using
- the Renew-Notification-Source-Registration operation. The
- maximum value for a registration lease is one day.
-
-4.5 Cancel-Notification-Source-Registration Operation
-
-
-This REQUIRED operation allows an IPP Printer to terminate a current
-registration to a Notification Delivery Service. This causes the Server
-object to saves all current persistent Subscriptions into the location
-specified for this purpose at registration time, if one was specified.
-The Server object then cleans up any data and processes associated with
-that registration. Notification Delivery Service implementations should
-consider periodically saving away persistent Subscription objects to
-reduce the risk of failing to save everything at deregistration time.
-
-
-4.5.1 Cancel-Notification-Source-Registration Request
-
-The following set of attributes is part of the Cancel-Notification-
-Source-Registration Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
-
-Parra, Hastings [page 22]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- "server-uri":
- The URI of the Notification Delivery Service.
-
- "registration-id" (integer(0:MAX)):
- The IPP Printer MUST specify this REQUIRED attribute using the
- registration-id it obtained from the Server object via the
- Register-Notification-Source operation.
-
-
-4.5.2 Cancel-Notification-Source-Registration Response
-
-
-The Server object returns the following set of attributes as part of the
-Cancel-Notification-Source-Registration Response:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
- "notify-events" (1setOf type2 keyword):
- The Server object MUST return in this attribute the list of
- events that the printer must discontinue as a result of ending
- its registration to the Notification Delivery Service. This
- feature may be useful to IPP Printers that implement some
- delivery methods internally and others via a Notification
- Delivery Service and those who may use more than one
- Notification Delivery Service simultaneously.
-
-4.6 Renew-Notification-Source-Registration Operation
-
-
-This REQUIRED operation allows an IPP Printer to renew its lease on an
-existing registration to a Notification Delivery Service. It MUST be
-issued before the lease-time specified in the Register-Notification-
-Source operation or the previous Renew-Notification-Source-Registration
-operation expires.
-
-
-4.6.1 Renew-Notification-Source-Registration Request
-
-The following set of attributes is part of the Renew-Notification-
-Source-Registration Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- "server-uri":
-
-Parra, Hastings [page 23]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- The URI of the Notification Delivery Service.
-
- "registration-id" (integer(0:MAX)):
- The IPP Printer MUST specify this REQUIRED attribute using the
- registration-id it obtained from the Server object via the
- Register-Notification-Source operation.
-
- "registration-lease-time-requested" (integer(0:86,400)):
- This REQUIRED attribute specifies the time in the future when
- the IPP Printer would like the registration lease to expire.
-
-
-4.6.2 Renew-Notification-Source-Registration Response
-
-
-The Server object returns the following set of attributes as part of the
-Renew-Notification-Source-Registration Response:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
- "registration-lease-expiration-time" (integer(0:86,400)):
- This REQUIRED attribute specifies the time in the future when
- the registration lease will expire. If the Server object is
- not able to grant the lease-time requested by the IPP Printer,
- this attribute may contain a different value that the one
- provided in the request.
-
-
-4.7 Create-Subscription Operation
-
-
-This REQUIRED operation allows an IPP Printer to cause a Subscription
-object to be instantiated in a Server object to which it is currently
-registered as a Notification Source. The Server object is responsible
-for keeping track of all registrations until their corresponding IPP
-Printer removes them via the Cancel-Subscription operation or until the
-registration is terminated by the Printer or it expires. The Server
-object uses Subscription object to know who and how to notify when it
-receives Notifications specifying a registration-id.
-
-
-4.7.1 Create-Subscription Request
-
-The Request for this operation includes the union of all of the REQUIRED
-attributes and any of the OPTIONAL attributes indicated in [ipp-ntfy]
-for the Create-Job-Subscription and Create-Printer-Subscription
-operations, with the following chages:
-
-
-Parra, Hastings [page 24]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-a)The "printer-uri" operational attribute is replaced by "server-uir"
- and MUST contain the URI of the Notification Delivery Service.
-b)The request MUST include the operational attribute "registration-id"
- (integer(0:MAX)) specifying the registration-id the IPP Printer
- obtained from the Server object via the Register-Notification-Source
- operation.
-
-The rules that govern when each individual attribute MUST or MAY be
-included in this operation precisely mirror those specified in [ipp-
-ntfy] for the Create-Job-Subscription and Create-Printer-Subscription
-operations, but obviously not simultaneously. If the request contains a
-"job-id" the Server object enforces applies the validation rules defined
-for the Create-Job-Subscription operation. If the "job-id" is not
-present, the Server object enforces the validation rules defined for the
-Create-Printer-Subscription operation.
-
-4.7.2 Create-Subscription Response
-
-The Response for this operation is defined to be identical to the
-Response for the Create-Printer-Subscription operation as specified in
-[ipp-ntfy] except for the following changes:
-
-a)The Response MUST include the operational attribute "notify-events"
- (1setOf type2 keyword) containing the list of events that the printer
- must notify the Server object of to satisfy the creatioin of the new
- Subscription object.
-
-b)The "notify-server-up-time" operational attribute contains the up-
- time of the Notification Delivery Service instead of the IPP Printer.
-
-c)The Response does not include the "Unsupported Attribute" Group.
-
-The Response that results from creating a job-related Subscription
-object doesn't include the "notify-lease-expiration-time" and "notify-
-server-up-time" attributes.
-
-
-4.8 Validate-Subscription Operation
-
-
-This REQUIRED operation allows an IPP Printer to request the Sever
-object to validate the contents of what could become a Subscription
-object without actually creating the object. It employs the same logic
-used by the Create-Subscription operation to validate a request.
-
-
-4.8.1 Validate-Subscription Request
-
-The Request for this operation is identical to the Create-Subscription
-operation Request.
-
-
-
-Parra, Hastings [page 25]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-4.8.2 Validate-Subscription Response
-
-
-The Server object returns the following set of attributes as part of the
-Validate-Subscription Registration Response:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
-
-4.9 Cancel-Subscription Operation
-
-
-This REQUIRED operation allows an IPP Printer to cause the Server object
-to cancel a Subscription object currently associated with a given
-registration-id.
-
-
-4.9.1 Cancel-Subscription Request
-
-The following set of attributes is part of the Cancel-Subscription
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- "server-uri":
- The URI of the Notification Delivery Service.
-
- "registration-id" (integer(0:MAX)):
- The IPP Printer MUST specify this REQUIRED attribute using the
- registration-id it obtained from the Server object via the
- Register-Notification-Source operation.
-
- "subscription-id" (integer(0:MAX)):
- This REQUIRED attribute specifies the ID of the Subscription
- object to be cancelled. The IPP Printer must provide here the
- same "subscription-id" that it received back from the Create-
- Subscription or Get-Subscriptions operations.
-
-
-4.9.2 Cancel-Subscription Response
-
-
-The Server object returns the following set of attributes as part of the
-Cancel-Subscription Response:
-
-Parra, Hastings [page 26]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
- "notify-events" (1setOf type2 keyword):
- The Server object MUST return in this attribute the list of
- events that the printer must discontinue as a result of
- canceling the Subscription object.
-
-
-4.10 Renew-Subscription Operation
-
-
-The REQUIRED Renew-Subscription operation permits an IPP Printer to
-request the Server object to extend the lease on a Subscription object
-instance. This operation is only valid for Subscription object that
-don't specify a "job-id", or Per-Printer Subscription objects as they
-are referred to in [ipp-ntfy].
-
-
-4.10.1 Renew-Subscription Request
-
-The following set of attributes is part of the Renew-Subscription
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- "server-uri":
- The URI of the Notification Delivery Service.
-
- "registration-id" (integer(0:MAX)):
- The IPP Printer MUST specify this REQUIRED attribute using the
- registration-id it obtained from the Server object via the
- Register-Notification-Source operation.
-
- "subscription-id" (integer(0:MAX))
-
- The IPP Printer MUST specify the ID of the Subscription object
- whose lease is being extended.
-
- "notify-lease-time-requested" (integer(0:MAX))
-
- The IPP Printer MUST specify the time by which it wishes to
- extend the Subscription object's lease.
-
-
-
-Parra, Hastings [page 27]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-4.10.2 Renew-Subscription Response
-
-
-The Server object returns the following set of attributes as part of the
-Renew-Subscription Response:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as defined in [rfc 2566] section 3.1.4.1.
-
- "subscription-lease-expiration-time" (integer(0:86,400)):
- This REQUIRED attribute specifies the time in the future when
- the Subscription's lease will expire. If the Server object is
- not able to grant the lease-time requested by the IPP Printer,
- this attribute may contain a different value that the one
- provided in the request.
-
-
-4.11 Get-Subscriptions Operation
-
-
-This REQUIRED operation allows an IPP Printer to get a list of the
-Subscription objects associated with a given registration ID.
-
-
-4.11.1 Get-Subscriptions Request
-
-The Request for this operation is defined to be identical to the Request
-for the Get-Subscriptions operation as specified in [ipp-ntfy], except
-for the following changes:
-
-a)The "printer-uri" operational attribute is replaced by "server-uir"
- (uri) and MUST contain the URI of the Notification Delivery Service.
-b)The request MUST include the operational attribute "registration-id"
- (integer(0:MAX)) specifying the registration-id the IPP Printer
- obtained from the Server object via the Register-Notification-Source
- operation.
-
-
-4.11.2 Get Subscriptions Response
-
-The Response for this operation is defined to be identical to the
-Response for the Get-Subscriptions operation as specified in [ipp-ntfy].
-
-
-5 Encoding of the Operation Layer
-
-INDP uses the same operation layer encoding model and syntax as IPP
-[ipp-pro] with the following extensions:
-
-
-Parra, Hastings [page 28]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-5.1 New attribute tag
-
-
-A new notification attributes tag is defined:
-
-
- notification-attributes-tag = %x07 ; tag of 7
-
-
-5.2 New status codes
-
-
-ISSUE 02 - Should we move the status codes into the Notification Model
-document in order to have the same status codes for any other delivery
-method that might be defined?
-
-
-The following status codes are defined:
-
-
-5.2.1 unknown-notification-recipient. (0xXXX)
-
-The Notification Recipient returns this status code in order to indicate
-that the intended Ultimate Notification Recipient is not known to the
-Notification Recipient.
-
-
-5.2.2 unable-to-delivery-notification-report (0xXXX)
-
-The Notification Recipient returns this status code in order to indicate
-that it was unable to deliver the event Notification to the intended
-Ultimate Notification Recipient.
-
-
-5.2.3 successful-ok-but-cancel-subscription (0xXXXX)
-
-The Notification Recipient indicates that it no longer wants to receive
-Notifications for this Subscription object. Therefore, the Subscription
-object is canceled. Note: this status code allows the Notification
-Recipient to cancel a Subscription object without having to be the owner
-of the Subscription object. Only the owner of the Subscription object
-can cancel a Subscription object using the Cancel-Subscription
-operation.
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 29]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-5.2.4 unknown-registration-id (0xXXX)
-
-
-5.2.5 successful-ok-but-error-accessing-persistent-storage (0xXXXX)
-
-
-5.3 Encoding
-
-
-The encoding of INDP is based strictly on the encoding used by IPP.
-This specification, however, defines a new Group tag which is used it to
-encode multiple notifications in a Request. As multiple instances of
-the same group type have only been included in operation Responses in
-the past, this section describes the encoding of an operation that uses
-the new tag for illustration purposes.
-
-
-The encoding for the Send-Notification Request consists of:
-
- -----------------------------------
- | version-number | 2 byte
- -----------------------------------
- | operation-id | 2 bytes
- -----------------------------------
- | request-id | 4 bytes
- -----------------------------------
- | operation-attributes-tag | 1 byte
- -----------------------------------
- | attributes-charset | u bytes
- -----------------------------------
- | attributes-natural-language | v bytes
- -----------------------------------
- | target-attribute | w bytes
- ----------------------------------------------
- | notification-attributes-tag | 1 byte |
- ----------------------------------- | - 1 or more
- | notification-attr-list | x bytes |
- ----------------------------------------------
- | end-of-attributes-tag | 1 byte
- -----------------------------------
-
-Where:
-
-
-version-number is made up of a major-version-number of %d1 and a minor-
-version-number of %d0 indicating the 1.0 version of the INDP protocol.
-
-
-operation-id, in the 1.0 version of the protocol, can be 0xXXXX _
-0xXXXX.
-
-
-
-Parra, Hastings [page 30]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-request-id is any 4 byte number provided by the notification source and
-must be matched by the notification recipient in the corresponding
-response to a request. It assists the notification source in associating
-operation responses with their corresponding requests. Note that this
-request id is independent of the request id embedded in the notification
-report, which is opaque to the delivery method but assists the
-notification recipient order and identity missing or duplicate
-notification reports.
-
-
-operation-attribute tag, natural-language-attribute, charset-attribute,
-target-attribute, and end-of-attributes-tag have the same syntax and
-semantics as in [ipp-pro].
-
-
-notification-attr-list contains a list of the attributes that make up a
-single notification (see section 2 above) encoded using the syntax
-specified in [ipp-pro].
-
-
-The encoding for the Send-Notification Response consists of:
-
- -----------------------------------
- | version-number | 2 byte
- -----------------------------------
- | status-code | 2 bytes
- -----------------------------------
- | request-id | 4 bytes
- -----------------------------------
- | operation-attributes-tag | 1 byte
- -----------------------------------
- | attributes-charset | u bytes
- -----------------------------------
- | attributes-natural-language | v bytes
- -----------------------------------
- | target-attribute | w bytes
- ----------------------------------------------
- | notification-attributes-tag | 1 byte |
- ----------------------------------- | - 1 or more
- | ntfy-status-code | 2 bytes |
- ----------------------------------------------
- | end-of-attributes-tag | 1 byte
- -----------------------------------
-
-6 Encoding of Transport Layer
-
-HTTP/1.1 [rfc2616] is the transport layer for this protocol.
-
-
-The operation layer has been designed with the assumption that the
-transport layer contains the following information:
-
-
-Parra, Hastings [page 31]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
- - the URI of the target INDP operation.
-
-
- - the total length of the data in the operation layer, either as a
- single length or as a sequence of chunks each with a length.
-
-
-It is REQUIRED that a Notification Delivery Service and a 'indp://'
-Notification Recipient implementation support HTTP over the IANA
-assigned Well Known Port XXX (INDP's default port), though a
-notification recipient implementation MAY support HTTP over some other
-port as well.
-
-
-Each HTTP operation MUST use the POST method where the request-URI is
-the object target of the operation, and where the "Content-Type" of the
-message-body in each request and response MUST be "application/ipp-
-notify-send". The message-body MUST contain the operation layer and MUST
-have the syntax described in section 3, "Encoding of Operation Layer".
-An INDP client implementation (be it an IPP Printer or a Notification
-Delivery Service) MUST adhere to the rules for a client described for
-HTTP1.1 [rfc2616]. An INDP server implementation (be it a Notification
-Delivery Method or a notification Recipient) MUST adhere the rules for
-an origin server described for HTTP1.1 [rfc2616].
-
-
-An INDP server implementation sends a response for each request that it
-receives. If it detects an error, it MAY send a response before it has
-read the entire request. If the HTTP layer of the INDP server
-implementation completes processing the HTTP headers successfully, it
-MAY send an intermediate response, such as "100 Continue", with no
-notification data before sending the notification response. The INDP
-client implementation MUST expect such a variety of responses. For
-further information on HTTP/1.1, consult the HTTP documents [rfc2616].
-
-
-An INDP server implementation MUST support chunking for HTTP
-notification requests, and an INDP client implementation MUST support
-chunking for HTTP notification responses according to HTTP/1.1[rfc2616].
-Note: this rule causes a conflict with non-compliant implementations of
-HTTP/1.1 that don't support chunking for POST methods, and this rule may
-cause a conflict with non-compliant implementations of HTTP/1.1 that
-don't support chunking for CGI scripts
-
-
-INDP uses 'indp://' as its URI scheme.
-
-
-7 IANA Considerations
-
-IANA will be asked to register this 'ipp-notify-send' notification
-delivery scheme and protocol and will be asked to assign a default port.
-
-Parra, Hastings [page 32]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-8 Internationalization Considerations
-
-When the client requests Human Consumable form by supplying the "notify-
-text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or
-any Notification Service that the IPP Printer might be configured to
-use) supplies and localizes the text value of the "human-readable-
-report" attribute in the Notification according to the charset and
-natural language requested in the notification subscription.
-
-
-9 Security Considerations
-
-The IPP Model and Semantics document [ipp-mod] discusses high-level
-security requirements (Client Authentication, Server Authentication and
-Operation Privacy). Client Authentication is the mechanism by which the
-client proves its identity to the server in a secure manner. Server
-Authentication is the mechanism by which the server proves its identity
-to the client in a secure manner. Operation Privacy is defined as a
-mechanism for protecting operations from eavesdropping.
-
-The Notification Recipient can cancel unwanted Subscriptions created by
-other parties without having to be the owner of the subscription by
-returning the 'successful-ok-but-cancel-subscription' status code in the
-Send-Notifications response returned to the Notification Source.
-
-9.1 Security Conformance
-
-
-Notification Sources (client) MAY support Digest Authentication
-[rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess
-MUST be supported, but the Message Integrity feature NEED NOT be
-supported.
-
-
-Notification Recipient (server) MAY support Digest Authentication
-[rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess
-MUST be supported, but the Message Integrity feature NEED NOT be
-supported.
-
-
-Notification Recipients MAY support TLS for client authentication,
-server authentication and operation privacy. If a notification recipient
-supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites
-are OPTIONAL. Notification recipients MAY support Basic Authentication
-(described in HTTP/1.1 [rfc2616]) for client authentication if the
-channel is secure. TLS with the above mandated cipher suite can provide
-such a secure channel.
-
-
-
-
-
-Parra, Hastings [page 33]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-10 References
-[ipp-mod]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
- ipp-model-v11-06.txt>, March 1, 2000.
-
-[ipp-ntfy]
- Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
- Bergman, R., "Internet Printing Protocol/1.1: IPP Event
- Notification Specification", <draft-ietf-ipp-not-spec-02.txt>,
- February 2, 2000.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 05.txt, March 1, 2000.
-
-[rfc2026]
- S. Bradner, "The Internet Standards Process -- Revision 3", RFC
- 2026, October 1996.
-
-[rfc2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-[rfc2617]
- J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.
- Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access
- Authentication", RFC 2617, June 1999.
-
-
-11 Author's Addresses
- Hugo Parra
- Novell, Inc.
- 1800 South Novell Place
- Provo, UT 84606
-
- Phone: 801-861-3307
- Fax: 801-861-2517
- e-mail: hparra@novell.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
-
-
-Parra, Hastings [page 34]
-
- Expires: Sep 9, 2000
-
-
-
-
-INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
-
-12 Full Copyright Statement
-Copyright (C) The Internet Society (2000). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 35]
-
- Expires: Sep 9, 2000
+++ /dev/null
-
-
-INTERNET-DRAFT
-<draft-ietf-ipp-indp-method-00.txt>
- Hugo Parra
- Novell, Inc.
- Tom Hastings
- Xerox Corp.
- March 9, 2000
-
- Internet Printing Protocol (IPP):
-
- The INDP Notification Delivery Method
-
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [rfc2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-
-The IPP event notification specification [ipp-ntfy] is an OPTIONAL
-extension to IPP/1.0, IPP/1.1, and future versions. [ipp-ntfy] requires
-the definition of one or more delivery methods for dispatching
-Notifications to Notification Recipients. This document describes the
-semantics and syntax of the INDP Notification Delivery Method that is
-itself a request/response protocol. For this delivery method, an IPP
-Printer sends (pushes) IPP event Notifications to the Notification
-Recipients using the IPP Notification Delivery Protocol (INDP) defined
-in [indp]. The Notification Recipient can either be the Ultimate
-Recipient of the Notification or can be a Notification Service that
-forwards the Notification to the Ultimate Recipient.
-
-
-
-Parra, Hastings [page 1]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
- Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting a message body over
-HTTP whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 2]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-
-
-
- Table of Contents
-
-
-1 Introduction ......................................................4
-
-2 Terminology .......................................................4
-
-3 Model and Operation ...............................................4
-
-4 Notification Operations ...........................................5
- 4.1 SEND-NOTIFICATIONS OPERATION.....................................6
- 4.1.1 Send-Notifications Request ..................................6
- 4.1.2 Send-Notifications Response .................................7
- 4.2 NOTIFICATION PROTOCOL URI SCHEME.................................8
-
-5 Encoding of the Operation Layer ...................................9
-
-6 Encoding of Transport Layer .......................................9
-
-7 IANA Considerations ...............................................9
-
-8 Internationalization Considerations ...............................9
-
-9 Security Considerations ...........................................9
- 9.1 SECURITY CONFORMANCE............................................10
-
-10 References .......................................................10
-
-11 Author's Addresses ...............................................11
-
-12 Full Copyright Statement .........................................11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 3]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-
-
-
-1 Introduction
-
-An IPP Printer that supports the OPTIONAL IPP event notification
-extension [ipp-ntfy] is called a Notification Source which sends event
-Notifications to Notification Recipients. As such, a Printer either a)
-accepts, stores, and uses notification Subscription objects to generate
-event Notification and implements one or more delivery methods for
-notifying interested parties, or b) supports a subset of these tasks and
-farms out the remaining tasks to a Notification Delivery Service. The
-INDP Notification Delivery Method specified in this document employs a
-request/response protocol, which is a subset of the IPP Notification
-Delivery Protocol (INDP), defined in [indp]. A Notification Source may
-implement the INDP Notification Delivery Method to send (push) event
-notifications to Notification Recipients using the INDP Send-
-Notifications operation (see section 4.1) over HTTP.
-
-
-2 Terminology
-
-This document uses terms such as "attributes", "keywords", and
-"support". These terms have special meaning and are defined in the
-model terminology [ipp-mod] section 12.2.
-
-
-Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
-MAY, NEED NOT, and OPTIONAL, have special meaning relating to
-conformance. These terms are defined in [ipp-mod] section 12.1 on
-conformance terminology, most of which is taken from RFC 2119 [RFC2119].
-
-
-This section defines the following additional terms that are used
-throughout this document:
-
- REQUIRED: if an implementation supports the extensions described in
- this document, it MUST support a REQUIRED feature.
- OPTIONAL: if an implementation supports the extensions described in
- this document, it MAY support an OPTIONAL feature.
- Event Notification (Notification for short) - See [ip-ntfy]
- Notification Source - See [ipp-ntfy]
- Notification Recipient - See [ipp-ntfy]
- Subscription object - See [ipp-ntfy]
- Ultimate Notification Recipient - See [ipp-ntfy]
-
-3 Model and Operation
-
-In the IPP Notification Model [ipp-ntfy], a client is able to:
-
-
-
-
-Parra, Hastings [page 4]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-1.supply one or more Per-Job Subscriptions in the Job Creation
- operation
-
-
-2.OPTIONALLY supply Per-Job Subscriptions as subsequent Create-Job-
- Subscription operations
-
-
-3.Supply one Per-Printer Subscription in the Create-Printer-
- Subscription operation.
-
-
-The client that creates these Subscription objects becomes the owner of
-the Subscription object.
-
-
-When creating each Subscription object, the client supplies the "notify-
-recipient" (uri) attribute. The "notify-recipient" attribute specifies
-both a single Notification Recipient that is to receive the
-Notifications when subsequent events occur and the method for
-notification delivery that the IPP Printer is to use. For the
-Notification delivery method defined in this document, the notification
-method is 'indp' and the rest of the URI is the address of the
-Notification Recipient to which the IPP Printer will send the INDP Send-
-Notifications operation.
-
-
-The INDP Notification Delivery Method defined in this document also uses
-a client/server protocol paradigm. The "client" in this HTTP
-relationship is the Notification Source described in [ipp-ntfy] while
-the "server" is the Notification Recipient. The Notification Source
-invokes the Send-Notifications operation supported in INDP to
-communicate IPP event Notification contents to the Notification
-Recipient. The Notification Recipient only conveys information to the
-Notification Source in the form of responses to the operations initiated
-by the Notification Source.
-
-
-Notification Sources that implement the INDP Notification Delivery
-Method will need to include an INDP client stack (and hence an HTTP
-client stack) while notification recipients that implement this delivery
-method will need to support an INDP server stack (and hence an HTTP
-server stack). See section 6 for more details.
-
-
-4 Notification Operations
-
-The Notification Source composes the information defined for an IPP
-Notification [ipp-ntfy] and sends it using the Sent-Notifications
-operation to the Notification Recipient supplied in the Subscription
-object.
-
-
-Parra, Hastings [page 5]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-INDP makes extensive use of the operations model defined by IPP
-[rfc2566]. This includes, the use of a URI as the identifier for the
-target of each operation, the inclusion of a version number, operation-
-id, and request-id in each request, and the definition of attribute
-groups. The Send-Notifications operation uses the Operation Attributes
-group, but currently has no need for the Unsupported Attributes, Printer
-Object Attributes, and Job-Object Attributes groups. However, it uses a
-new attribute group, the Notification Attributes group (see [indp]).
-
-
-4.1 Send-Notifications Operation
-
-
-This REQUIRED operation allows a Notification Source to send one or more
-Notifications to a Notification Recipient using HTTP. The operation has
-been tailored to accommodate the current definition of IPP Notification
-[ipp-ntfy].
-
-
-Both Machine-Consumable and Human-Consumable notifications may be sent
-to a Notification Recipient through this operation.
-
-4.1.1 Send-Notifications Request
-
-
-Every operation request contains the following REQUIRED parameters (see
-[ipp-mod] section 3.1.1):
-
- - a "version-number"
- - an "operation-id"
- - a "request-id"
-
-The following groups of attributes are part of the Send-Notifications
-Request:
-
-Group 1: Operation Attributes
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- Target:
- The "notification-recipient-uri" (uri) operation attribute
- which is the target of this operation as described in [ipp-
- mod] section 3.1.5, i.e., the URI of the 'indp' Notification
- Recipient.
-
-Group 2 to N: Notification Attributes
-
- "human-readable-report" (text)
- The 'indp' Notification Source OPTIONALLY supports this attribute.
- This attribute is a text string generated by the IPP printer or
- Notification Delivery Service from the contents of the IPP
-
-Parra, Hastings [page 6]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
- Notification suitable for human consumption. If the Notification
- Source supports this attribute, it MUST supply this attribute if
- the Subscription object contains the "notify-text-format"
- (mimeMediaType) attribute. The text value of this attribute MUST
- be localized in the charset identified by the "notify-charset"
- (charset) attribute and the natural language identified by the
- notify-natural-language" (naturalLanguage) attribute supplied in
- the associated Subscription object that generates this event
- Notification. The format of the text value is specified by the
- value of the "notify-text-format" (mimeMediaType) supplied in the
- associated Subscription object.
-
- "human-readable-report-format" (mime)
- This attribute MUST be supplied by the Notification Source whenever
- the "human-readable-report" attribute is present. It indicates the
- format, e.g., text/plain, text/html, etc. of the "human-readable-
- report" attribute.
-
- All of the REQUIRED attributes and any of the OPTIONAL attributes
- indicated in [ipp-ntfy] for a Push event Notification, including
- "notify-text-format-type" (mimeMediaType), if the "human-readable-
- report" (text) attribute is included, so that the Notification
- Recipient will know the text format of the "human-readable-report"
- (text) attribute value.
-
- These attributes communicate the same information as the notification
- attributes by the same name described in sections 7.4, 7.5, and 7.6
- of [ipp-ntfy]. The rules that govern when each individual attribute
- MUST or MAY be included in this operation precisely mirror those
- specified in [ipp-ntfy].
-
-
-4.1.2 Send-Notifications Response
-
-
-The 'indp' Notification Recipient returns a status code for the entire
-operation and one for each Notification Report in the request if the
-operation's status code is other than "successful-ok". If the 'indp'
-Notification Recipient receives a Notification report that it can't pair
-up with a Subscription it knows about, it can return a 'client-error-
-unknown-subscription' error status-code to indicate that events
-associated with that subscription should no longer be sent to it.
-Alternatively, the Notification Recipient can return the 'successful-ok-
-but-cancel-subscription' to the Notification Source and cancel a
-Subscription that is no longer wanted.
-
-
-Every operation response contains the following REQUIRED parameters (see
-[ipp-mod] section 3.1.1}:
-
- - a "version-number"
- - a "status-code"
-
-Parra, Hastings [page 7]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
- - the "request-id" that was supplied in the corresponding request
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
-ISSUE 01 _ Should there be an Unsupported Attributes group to return
-attributes that are not supported to the client?
-
-Group 2 to N: Notification Attributes
-
- "notification-report-status-code" (type2 enum)
- Indicates whether the 'ipp-notify-send' Notification Recipient was
- able to consume the n-th Notification Report.
-
- The following standard enum values are defined:
-
- 'successful-ok'
- 'successful-ok-but-cancel-subscription'
- 'client-error-unknown-subscription'
- 'client-error-bad-request'
-
-ISSUE 02 _ Should this use the same status code space as IP, namely:
- "successful" _ 0x0000 to 0x00FF
- "informational" _ 0x0100 to 0x01FF
- "redirection" _ 0x0400 to 0x04FF
- "server-error" _ 0x0500 to 0x05FF
-
-ISSUE 03 _ What status code from IPP can we re-use?
-
-ISSUE 04 _ Where should the status code be defined? Here, in [indp], in
-[ipp-ntfy], or in [ipp-mod]?
-
-ISSUE 05 _ Since there is an overall status code for the entire
-operation and one fore each Notification, what status code is returned
-for the overall operation, if one Notification succeeds and another
-fails? Do we need a status code for this such as 'client-error-some-
-notifications-failed'?
-
-4.2 Notification Protocol URI Scheme
-
-
-The INDP Notification Delivery Method uses the 'indp://' URI scheme in
-the "notify-recipients" attribute in the Subscription object in order to
-indicate the notification delivery method defined in this document. The
-remainder of the URI indicates the host and address of the Notification
-Recipient that is to receive the Send-Notification operation.
-
-
-
-
-Parra, Hastings [page 8]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-5 Encoding of the Operation Layer
-
-The INDP Notification Delivery Method uses the INDP operation layer
-encoding described in [indp].
-
-
-6 Encoding of Transport Layer
-
-The INDP Notification Delivery Method uses the INDP transport layer
-encoding described in [indp].
-
-
-It is REQUIRED that an 'indp' Notification Recipient implementation
-support HTTP over the IANA assigned Well Known Port XXX (the INDP
-default port), though a notification recipient implementation MAY
-support HTTP over some other port as well.
-
-
-7 IANA Considerations
-
-The 'indp://' URL scheme and the IDNP default fort will be registered
-with IANA.
-
-
-8 Internationalization Considerations
-
-When the client requests Human Consumable form by supplying the "notify-
-text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or
-any Notification Service that the IPP Printer might be configured to
-use) supplies and localizes the text value of the "human-readable-
-report" attribute in the Notification according to the charset and
-natural language requested in the notification subscription.
-
-
-9 Security Considerations
-
-The IPP Model and Semantics document [ipp-mod] discusses high level
-security requirements (Client Authentication, Server Authentication and
-Operation Privacy). Client Authentication is the mechanism by which the
-client proves its identity to the server in a secure manner. Server
-Authentication is the mechanism by which the server proves its identity
-to the client in a secure manner. Operation Privacy is defined as a
-mechanism for protecting operations from eavesdropping.
-
-The Notification Recipient can cancel unwanted Subscriptions created by
-other parties without having to be the owner of the subscription by
-returning the 'successful-ok-but-cancel-subscription' status code in the
-Send-Notifications response returned to the Notification Source.
-
-
-
-
-
-Parra, Hastings [page 9]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-9.1 Security Conformance
-
-
-Notification Sources (client) MAY support Digest Authentication
-[rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess
-MUST be supported, but the Message Integrity feature NEED NOT be
-supported.
-
-
-Notification Recipient (server) MAY support Digest Authentication
-[rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess
-MUST be supported, but the Message Integrity feature NEED NOT be
-supported.
-
-
-Notification Recipients MAY support TLS for client authentication,
-server authentication and operation privacy. If a notification recipient
-supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites
-are OPTIONAL. Notification recipients MAY support Basic Authentication
-(described in HTTP/1.1 [rfc2616]) for client authentication if the
-channel is secure. TLS with the above mandated cipher suite can provide
-such a secure channel.
-
-
-10 References
-
-[indp]
- Parra, H., T. Hastings, "Internet Printing Protocol (IPP): IPP
- Notification Delivery Protocol (INDP)", <draft-ietf-indp-00.txt>,
- February 29, 2000.
-
-[ipp-mod]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
- ipp-model-v11-06.txt>, March 1, 2000.
-
-[ipp-ntfy]
- Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
- Bergman, R., "Internet Printing Protocol/1.1: IPP Event
- Notification Specification", <draft-ietf-ipp-not-spec-02.txt>,
- February 2, 2000.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 05.txt, March 1, 2000.
-
-[rfc2026]
- S. Bradner, "The Internet Standards Process -- Revision 3", RFC
- 2026, October 1996.
-
-
-Parra, Hastings [page 10]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-[rfc2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-[rfc2617]
- J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.
- Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access
- Authentication", RFC 2617, June 1999.
-
-
-11 Author's Addresses
- Hugo Parra
- Novell, Inc.
- 1800 South Novell Place
- Provo, UT 84606
-
- Phone: 801-861-3307
- Fax: 801-861-2517
- e-mail: hparra@novell.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
-
-12 Full Copyright Statement
-Copyright (C) The Internet Society (2000). 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
-
-Parra, Hastings [page 11]
-
- Expires: Sep 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra, Hastings [page 12]
-
- Expires: Sep 9, 2000
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Hugo Parra
+<draft-ietf-ipp-indp-method-04.txt> Novell, Inc.
+[Target Category: standards track] Tom Hastings
+ Xerox Corp.
+ February 28, 2001
+
+ Internet Printing Protocol (IPP):
+ The 'indp' Delivery Method for Event Notifications and Protocol/1.0
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+Abstract
+
+ The IPP notification extension document [ipp-ntfy] defines operations
+ that a client can perform in order to create Subscription Objects in
+ a Printer and carry out other operations on them. The Subscription
+ Object specifies that when one of the specified Events occurs, the
+ Printer sends an asynchronous Event Notification to the specified
+ Notification Recipient via the specified Delivery Method (i.e.,
+ protocol).
+
+ The notification extension document [ipp-ntfy] specifies that each
+ Delivery Method is defined in another document. This document is one
+ such document, and it specifies the 'indp' Delivery Method and
+ Protocol. This Delivery Method is a simple protocol consisting of a
+ single operation: the Send-Notifications operation which uses the
+ same encoding and transport as IPP. This document defines version
+ '1.0' of the protocol.
+
+ For this Delivery Method, when an Event occurs, the Printer
+ immediately sends (pushes) an Event Notification via the Send-
+
+ Parra, Hastings Expires: August 28, 2001 [page 1]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ Notifications operation to the Notification Recipient specified in
+ the Subscription Object. The Event Notification content consists of
+ Machine Consumable attributes and a Human Consumable "notify-text"
+ attribute. The Notification Recipient returns a response to the
+ Printer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 2]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
+ Mapping between LPD and IPP Protocols [RFC2569]
+ Internet Printing Protocol (IPP): IPP Event Notification
+ Specification [ipp-ntfy]
+
+ The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that
+ are satisfied in IPP/1.0. A few OPTIONAL operator operations have
+ been added to IPP/1.1.
+
+ The "Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol" document describes IPP from a high level
+ view, defines a roadmap for the various documents that form the suite
+ of IPP specification documents, and gives background and rationale
+ for the IETF working group's major decisions.
+
+ The "Internet Printing Protocol/1.1: Model and Semantics" document
+ describes a simplified model with abstract objects, their attributes,
+ and their operations that are independent of encoding and transport.
+ It introduces a Printer and a Job object. The Job object optionally
+ supports multiple documents per Job. It also addresses security,
+ internationalization, and directory issues.
+
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1 [RFC2616]. It defines the
+ encoding rules for a new Internet MIME media type called
+ "application/ipp". This document also defines the rules for
+ transporting a message body over HTTP whose Content-Type is
+ "application/ipp". This document defines a new scheme named 'ipp'
+ for identifying IPP printers and jobs.
+
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them understand IPP/1.1 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.
+
+Parra, Hastings Expires: August 28, 2001 [page 3]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ The "Mapping between LPD and IPP Protocols" document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+ The "Internet Printing Protocol (IPP): IPP Event Notification
+ Specification" document defines the semantics for Subscription
+ Creation Operations and the requirements for other Delivery Method
+ documents to define a Delivery Method to carry an Event Notifications
+ to a Notification Recipient.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 4]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+
+
+Table of Contents
+
+
+ 1 Introduction....................................................7
+
+ 2 Terminology.....................................................7
+
+ 3 Model and Operation.............................................8
+
+ 4 General Information.............................................9
+
+ 5 Subscription object attributes.................................12
+ 5.1 Subscription Template Attribute Conformance.................12
+ 5.2 Additional Information about Subscription Template Attributes12
+ 5.2.1 notify-recipient-uri (uri)................................12
+ 5.3 Subscription Description Attribute Conformance..............12
+
+ 6 Printer Description Attributes.................................12
+ 6.1 Printer Description Attribute Conformance...................13
+ 6.2 New Values for Existing Printer Description Attributes......13
+ 6.2.1 notify-schemes-supported (1setOf uriScheme)...............13
+ 6.2.2 operations-supported (1setOf type2 enum)..................13
+
+ 7 Attributes Only in Event Notifications.........................13
+
+ 8 Operations for Notification....................................14
+ 8.1 Send-Notifications operation................................14
+ 8.1.1 Send-Notifications Request................................14
+ 8.1.2 Send-Notifications Response...............................18
+
+ 9 Status Codes...................................................19
+ 9.1 Additional Status Codes.....................................19
+ 9.1.1 successful-ok-ignored-notifications (0x0004)..............20
+ 9.1.2 client-error-ignored-all-notifications (0x0416)...........20
+ 9.2 Status Codes returned in Event Notification Attributes Groups20
+ 9.2.1 client-error-not-found (0x0406)...........................20
+ 9.2.2 successful-ok-but-cancel-subscription (0x0006)............20
+
+ 10 Encoding and Transport.........................................21
+ 10.1 Encoding of the Operation Layer.............................21
+ 10.2 Encoding of Transport Layer.................................21
+
+ 11 Conformance Requirements.......................................21
+ 11.1 Conformance Requirements for Printers.......................21
+ 11.2 Conformance Requirements for INDP Notification Recipients...22
+
+ 12 INDP URL Scheme................................................23
+ 12.1 INDP URL Scheme Applicability and Intended Usage............23
+
+Parra, Hastings Expires: August 28, 2001 [page 5]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ 12.2 INDP URL Scheme Associated INDP Port........................23
+ 12.3 INDP URL Scheme Associated MIME Type........................23
+ 12.4 INDP URL Scheme Character Encoding..........................23
+ 12.5 INDP URL Scheme Syntax in ABNF..............................23
+ 12.5.1 INDP URL Examples.........................................24
+ 12.5.2 INDP URL Comparisons......................................25
+
+ 13 IANA Considerations............................................26
+ 13.1 Operation Registrations.....................................26
+ 13.2 Additional values of existing attributes....................26
+ 13.2.1 Additional values for the "notify-schemes-supported" Printer
+ attribute..............................................26
+ 13.2.2 Additional values for the "operations-supported" Printer
+ attribute..............................................27
+ 13.3 Status code Registrations...................................27
+
+ 14 Internationalization Considerations............................27
+
+ 15 Security Considerations........................................28
+ 15.1 Security Conformance........................................28
+
+ 16 References.....................................................28
+
+ 17 Author's Addresses.............................................30
+
+ 18 Full Copyright Statement.......................................30
+
+
+Tables
+
+ Table 1 - Information about the Delivery Method...................10
+ Table 2 - Operation-id assignments................................13
+ Table 3 - Attributes in Event Notification Content................16
+ Table 4 - Additional Attributes in Event Notification Content for Job
+ Events ........................................................17
+ Table 5 - Combinations of Events and Subscribed Events for "job-
+ impressions-completed" ........................................17
+ Table 6 - Additional Attributes in Event Notification Content for
+ Printer Events ................................................18
+ Table 7 - The "event-notification-attributes-tag" value...........21
+
+
+
+
+
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 6]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+
+
+
+1 Introduction
+
+ The notification extension document [ipp-ntfy] defines operations
+ that a client can perform in order to create Subscription Objects in
+ a Printer and carry out other operations on them. A Subscription
+ Object represents a Subscription abstraction. The Subscription Object
+ specifies that when one of the specified Events occurs, the Printer
+ sends an asynchronous Event Notification to the specified
+ Notification Recipient via the specified Delivery Method (i.e.,
+ protocol).
+
+ The notification extension document [ipp-ntfy] specifies that each
+ Delivery Method is defined in another document. This document is one
+ such document, and it specifies the 'indp' Delivery Method. This
+ Delivery Method is a simple protocol consisting of a single
+ operation: the Send-Notifications operation which uses the same
+ encoding and transport as IPP. This document defines version '1.0'
+ of the protocol.
+
+ For the 'indp' Delivery Method, an IPP Printer sends (pushes) a Send-
+ Notifications operation request containing one or more Event
+ Notifications to the Notification Recipient specified in the
+ Subscription Object. The Event Notification content consists of
+ Machine Consumable attributes and a Human Consumable "notify-text"
+ attribute.
+
+ The Notification Recipient receives the Event Notification as a Send-
+ Notifications operation, in the same way as an IPP Printer receives
+ IPP operations. The Notification Recipient returns a response to the
+ Printer.
+
+
+2 Terminology
+
+ This section defines the following terms that are used throughout
+ this document:
+
+ Terms such as attributes, keywords, and support. These terms have
+ special meaning and are defined in the model terminology
+ [RFC2911] section 12.2.
+
+ Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD,
+ SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special
+ meaning relating to conformance as specified in RFC 2119
+ [RFC2119] and [RFC2911] section 12.1. These terms refer to
+ conformance to this document, if this document is
+ implemented.
+
+Parra, Hastings Expires: August 28, 2001 [page 7]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ Capitalized terms, such as Notification Recipient, Event
+ Notification, Printer, etc., that are defined in [ipp-ntfy]
+ with the same meanings and are not reproduced here.
+
+ Event Notification Attributes Group - The attributes group in a
+ request that contains Event Notification Attributes in a
+ request or response.
+
+
+3 Model and Operation
+
+ See [ipp-ntfy] for the description of the Event Notification Model
+ and Operation. This Delivery Method takes advantage of combining
+ several Event Notifications into a single Compound Event Notification
+ that is delivery by a single Send-Notification operation to a single
+ Notification Recipient.
+
+ When creating each Subscription object, the client supplies the
+ "notify-recipient" (uri) Subscription Template attribute. The
+ "notify-recipient" attribute specifies both a single Notification
+ Recipient that is to receive the Notifications when subsequent events
+ occur and the method for notification delivery that the IPP Printer
+ is to use. For the Notification Delivery Method defined in this
+ document, the notification method is 'indp' and the rest of the URI
+ is the address of the Notification Recipient to which the IPP Printer
+ will send the Send-Notifications operation.
+
+ The 'indp' Notification Delivery Method defined in this document uses
+ a client/server protocol paradigm. The "client" in this relationship
+ is the Printer described in [ipp-ntfy] while the "server" is the
+ Notification Recipient. The Printer invokes the Send-Notifications
+ operation to communicate IPP Event Notification contents to the
+ Notification Recipient. The Notification Recipient only conveys
+ information to the Printer in the form of responses to the operations
+ initiated by the Printer.
+
+ Printers that implement the 'indp' Notification Delivery Method will
+ need to include an HTTP client stack while Notification Recipients
+ that implement this Delivery Method will need to support an HTTP
+ server stack. See section 10.2 for more details.
+
+ If the client wants the Printer to send Event Notifications via the
+ 'indp' Delivery Method, the client MUST choose a value for "notify-
+ recipient-uri" attribute which conforms to the rules of section
+ 5.2.1.
+
+ When an Event occurs, the Printer MUST immediately:
+
+ 1.Find all pertinent Subscription Objects P according to the rules of
+ section 9 of [ipp-ntfy], AND
+
+Parra, Hastings Expires: August 28, 2001 [page 8]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ 2.Find the subset M of these Subscription Objects P whose "notify-
+ recipient-uri" attribute has a scheme value of 'indp', AND
+
+ 3.For each Subscription Object in M, the Printer MUST
+
+ a)generate a Send-Notifications request as specified in section
+ 8.1.1 AND
+
+ b)send the Send-Notifications request to the Notification
+ Recipient specified by the address part of the "notify-
+ recipient-uri" attribute value (see section 5.2.1).
+
+ If several events occur sufficiently close to one another for the
+ same or different Subscription objects, but with the same
+ Notification Recipient, the Printer MAY combine them into a single
+ Send-Notifications request using a separate Event Notification
+ Attributes group for each event (see section 8.1.1).
+
+
+4 General Information
+
+ If a Printer supports this Delivery Method, Table 1 lists its
+ characteristics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 9]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ Table 1 - Information about the Delivery Method
+
+
+ Document Method conformance 'indp' realization
+ requirement
+
+
+ 1. What is the URL scheme name indp
+ for the Delivery Method?
+
+ 2. Is the Delivery Method is RECOMMENDED
+ REQUIRED, RECOMMENDED, or
+ OPTIONAL for an IPP Printer to
+ support?
+
+ 3. What transport and delivery A Printer MUST support a
+ protocol does the Printer use complete HTTP/1.1 stack
+ to deliver the Event [RFC2616]
+ Notification content, i.e.,
+ what is the entire network
+ stack?
+
+ 4. Can several Event A Printer implementation MAY
+ Notifications be combined into combine several Event
+ a Compound Event Notification? Notifications into a single
+ Event Notifications request as
+ separate Event Notification
+ Attributes Groups, see section
+ 8.1.1
+
+ 5. Is the Delivery Method This Delivery Method is a push.
+ initiated by the Notification
+ Recipient (pull), or by the
+ Printer (push)?
+
+ 6. Is the Event Notification Machine Consumable with the
+ content Machine Consumable or "notify-text" attribute being
+ Human Consumable? Human Consumable
+
+ 7. What section in this document The representation and encoding
+ answers the following is the same as IPP. See
+ question? For a Machine section 8.1.1
+ Consumable Event Notification,
+ what is the representation and
+ encoding of values defined in
+ section 9.1 of [ipp-ntfy] and
+ the conformance requirements
+ thereof? For a Human
+ Consumable Event Notification,
+
+
+Parra, Hastings Expires: August 28, 2001 [page 10]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+
+ Document Method conformance 'indp' realization
+ requirement
+
+
+ what is the representation and
+ encoding of pieces of
+ information defined in section
+ 9.2 of [ipp-ntfy] and the
+ conformance requirements
+ thereof?
+
+ 8. What are the latency and
+ reliability of the transport itselfs(see [RFC2911]).IPP/1.1
+ and delivery protocol?
+
+ 9. What are the security aspects 15
+ of the transport and delivery
+ protocol, e.g., how it is See section
+ handled in firewalls?
+
+ 10. What are the content length They are the same as for
+ restrictions? IPP/1.0 and IPP/1.1 itself (see
+ [RFC2911]).
+
+ 11. What are the additional values A new Event Notifications
+ or pieces of information that attribute group (see section
+ a Printer sends in an Event 10.1) and additional status
+ Notification and the codes for use in the response
+ conformance requirements (see section 9)
+ thereof?
+
+ 12. What are the additional None
+ Subscription Template and/or
+ Subscription Description
+ attributes and the conformance
+ requirements thereof?
+
+ 13. What are the additional None
+ Printer Description attributes
+ and the conformance
+ requirements thereof?
+
+
+ The remaining sections of this document parallel the sections of
+ [ipp-ntfy].
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 11]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+5 Subscription object attributes
+
+ This section defines the Subscription object conformance requirements
+ for Printers.
+
+
+5.1 Subscription Template Attribute Conformance
+
+ The 'indp' Delivery Method has the same conformance requirements for
+ Subscription Template attributes as defined in [ipp-ntfy]. The
+ 'indp' Delivery Method does not define any addition Subscription
+ Template attributes.
+
+
+5.2 Additional Information about Subscription Template Attributes
+
+ This section defines additional information about Subscription
+ Template attributes defined in [ipp-ntfy].
+
+
+5.2.1 notify-recipient-uri (uri)
+
+ This section describes the syntax of the value of this attribute for
+ the 'indp' Delivery Method. The syntax for values of this attribute
+ for other Delivery Method is defined in other Delivery Method
+ Documents.
+
+ In order to support the 'indp' Delivery Method and Protocol, the
+ Printer MUST support the following syntax:
+
+ The 'indp://' URI scheme. The remainder of the URI indicates
+ the host name or host address (and optional path) of the
+ Notification Recipient that is to receive the Send-
+ Notification operation.
+
+
+5.3 Subscription Description Attribute Conformance
+
+ The 'indp' Delivery Method has the same conformance requirements for
+ Subscription Description attributes as defined in [ipp-ntfy]. The
+ 'indp' Delivery Method does not define any addition Subscription
+ Description attributes.
+
+
+6 Printer Description Attributes
+
+ This section defines the Printer Description Attributes conformance
+ requirements for Printers.
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 12]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+6.1 Printer Description Attribute Conformance
+
+ The 'indp' Delivery Method has the same conformance requirements for
+ Printer Description attributes as defined in [ipp-ntfy]. The 'indp'
+ Delivery Method does not define any addition Printer Description
+ attributes.
+
+
+6.2 New Values for Existing Printer Description Attributes
+
+ This section defines additional values for existing Printer
+ Description attributes.
+
+
+6.2.1 notify-schemes-supported (1setOf uriScheme)
+
+ The following "notify-schemes-supported" value is added in order to
+ support the new Delivery Method defined in this document:
+
+ 'indp' - The IPP Notification Delivery Method defined in this
+ document.
+
+6.2.2 operations-supported (1setOf type2 enum)
+
+ Table 2 lists the "operation-id" value added in order to support the
+ new operation defined in this document. The operation-id is assigned
+ in the same name space as other operations that a Printer supports.
+ However, a Printer MUST NOT include this value in its "operations-
+ supported" attribute unless it can accept the Send-Notifications
+ request.
+
+ Table 2 - Operation-id assignments
+
+
+ Value Operation Name
+
+
+ 0x001D Send-Notifications
+
+
+
+
+7 Attributes Only in Event Notifications
+
+ No additional attributes are defined only for use in Event
+ Notifications besides those defined in [ipp-ntfy].
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 13]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+8 Operations for Notification
+
+ This section defines the operation for Event Notification using the
+ 'indp' Delivery Method.
+
+ There is only one operation defined: Send-Notifications. Section
+ 6.2.2 assigns of the "operation-id" for the Send-Notifications
+ operation and the following section defined the operation.
+
+
+8.1 Send-Notifications operation
+
+ This REQUIRED operation allows a Printer to send one or more Event
+ Notifications to a Notification Recipient using HTTP.
+
+ The Printer composes the information defined for an IPP Notification
+ [ipp-ntfy] and sends it using the Sent-Notifications operation to the
+ Notification Recipient supplied in the Subscription object.
+
+ The Send-Notifications operations uses the operations model defined
+ by IPP [RFC2566]. This includes, the use of a URI as the identifier
+ for the target of each operation, the inclusion of a version number,
+ operation-id, and request-id in each request, and the definition of
+ attribute groups. The Send-Notifications operation uses the Operation
+ Attributes group, but currently has no need for the Unsupported
+ Attributes, Printer Object Attributes, and Job-Object Attributes
+ groups. However, it uses a new attribute group, the Event
+ Notification Attributes group.
+
+ The Notification Recipient MUST accept the request in any state.
+ There is no state defined for the Notification Recipient for this
+ Delivery Method.
+
+ Access Rights: Notification Recipient MAY enforce access rights. If
+ the Printer receives a rejection with these status codes: 'client-
+ error-forbidden', 'client-error-not-authenticated', or 'client-error-
+ not-authorized' status code , the Printer SHOULD cancel the
+ subscription.
+
+
+8.1.1 Send-Notifications Request
+
+ Every operation request MUST contains the following parameters (see
+ [RFC2911] section 3.1.1):
+
+ - a "version-number" '1.0' - the version of the 'indp'
+ protocol is '1.0'.
+ - an "operation-id" - the value defined in Table 2
+ - a "request-id" - the request id (see [RFC2911] section 3.1.2).
+
+
+Parra, Hastings Expires: August 28, 2001 [page 14]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ The following groups of attributes MUST be part of the Send-
+ Notifications Request:
+
+
+ Group 1: Operation Attributes
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as defined in [RFC2911] section 3.1.4.1.
+
+ The Printer MUST use the values of "notify-charset" and
+ "notify-natural-language", respectively, from one Subscription
+ Object associated with the Event Notifications in this request.
+
+ Normally, there is only one matched Subscription Object, or the
+ value of the "notify-charset" and "notify-natural-language"
+ attributes is the same in all Subscription Objects. If not, the
+ Printer MUST pick one Subscription Object from which to obtain
+ the value of these attributes. The algorithm for picking the
+ Subscription Object is implementation dependent. The choice of
+ natural language is not critical because 'text' and 'name'
+ values can override the "attributes-natural-language" Operation
+ attribute. The Printer's choice of charset is critical because
+ a bad choice may leave it unable to send some 'text' and 'name'
+ values accurately.
+
+ Target:
+ A copy of the Subscription object's "notify-recipient-uri"
+ (uri) attribute which is the target of this operation as
+ described in [RFC2911] section 3.1.5, i.e., the URI of the
+ 'indp' Notification Recipient (see section 5.2.1).
+
+ Group 2 to N: Event Notification Attributes
+
+ In each group 2 to N, each attribute is encoded using the IPP
+ rules for encoding attributes [RFC2910] and may be encoded in
+ any order. Note: the Get-Jobs response in [RFC2911] acts as a
+ model for encoding multiple groups of attributes.
+
+ Each Event Notification Group MUST contain all of attributes
+ specified in [ipp-ntfy] section 9.1 ("Content of Machine
+ Consumable Event Notifications") with exceptions denoted by
+ asterisks in the tables below.
+
+ The tables below are copies of the tables in [ipp-ntfy] section
+ 9.1 ("Content of Machine Consumable Event Notifications")
+ except that each cell in the "Sends" column is a "MUST".
+
+ For an Event Notification for all Events, the Printer sends the
+ following attributes.
+
+
+Parra, Hastings Expires: August 28, 2001 [page 15]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ Table 3 - Attributes in Event Notification Content
+
+
+ Source Value Sends Source Object
+
+
+ notify-subscription-id (integer(1:MAX)) MUST Subscription
+
+ notify-printer-uri (uri) MUST Subscription
+
+ notify-subscribed-event (type2 keyword) MUST Event
+ Notification
+
+ printer-up-time (integer(MIN:MAX)) MUST Printer
+
+ printer-current-time (dateTime) * MUST Printer
+
+ notify-sequence-number (integer (0:MAX)) MUST Subscription
+
+ notify-charset (charset) MUST Subscription
+
+ notify-natural-language (naturalLanguage) MUST Subscription
+
+ notify-user-data (octetString(63)) ** MUST Subscription
+
+ notify-text (text (MAX)) MUST Event
+ Notification
+
+ attributes from the "notify-attributes" MUST *** Printer
+ attribute, if any ***
+
+ attributes from the "notify-attributes" MUST *** Job
+ attribute, if any ***
+
+ attributes from the "notify-attributes" MUST *** Subscription
+ attribute, if any ***
+
+
+ * The Printer MUST send "printer-current-time" if and only if
+ it supports the "printer-current-time" attribute on the Printer
+ object.
+
+ ** If the associated Subscription Object does not contain a
+ "notify-user-data" attribute, the Printer MUST send an octet-
+ string of length 0.
+
+ *** If the "notify-attributes" attribute is present on the
+ Subscription Object, the Printer MUST send all attributes
+ specified by the "notify-attributes" attribute. Note: if the
+ Printer doesn't support the "notify-attributes" attribute, it
+
+Parra, Hastings Expires: August 28, 2001 [page 16]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ is not present on the associated Subscription Object and the
+ Printer does not send any client-requested attributes.
+
+ For Event Notifications for Job Events, the Printer sends the
+ following additional attributes shown in Table 4.
+
+ Table 4 - Additional Attributes in Event Notification Content for
+ Job Events
+
+
+ Source Value Sends Source Object
+
+
+ job-id (integer(1:MAX)) MUST Job
+
+ job-state (type1 enum) MUST Job
+
+ job-state-reasons (1setOf type2 keyword) MUST Job
+
+ job-impressions-completed MUST Job
+ (integer(0:MAX)) *
+
+
+ * The Printer MUST send the "job-impressions-completed"
+ attribute in an Event Notification only for the combinations of
+ Events and Subscribed Events shown in Table 5.
+
+
+
+ Table 5 - Combinations of Events and Subscribed Events for "job-
+ impressions-completed"
+
+
+ Job Event Subscribed Job Event
+
+
+ 'job-progress' 'job-progress'
+
+ 'job-completed' 'job-completed'
+
+ 'job-completed' 'job-state-changed'
+
+
+ For Event Notification for Printer Events, the Printer sends
+ the following additional attributes shown in Table 6.
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 17]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ Table 6 - Additional Attributes in Event Notification Content for
+ Printer Events
+
+
+ Source Value Sends Source Object
+
+
+ printer-state (type1 enum) MUST Printer
+
+ printer-state-reasons (1setOf type2 keyword) MUST Printer
+
+ printer-is-accepting-jobs (boolean) MUST Printer
+
+
+
+8.1.2 Send-Notifications Response
+
+ The Notification Recipient MUST return (to the client which is the
+ Printer) the following sets of attributes as part of a Send-
+ Notifications response:
+
+ Every operation response contains the following REQUIRED parameters
+ (see [RFC2911] section 3.1.1}:
+
+ - a "version-number"
+ - a "status-code"
+ - the "request-id" that was supplied in the corresponding request
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ As defined in [RFC2911].
+
+ The Notification Recipient can return any status codes defined
+ in [RFC2911] and section 9.1 that applies to all of the Event
+ Notification Attribute groups. The following is a description
+ of the important status codes:
+
+ 'successful-ok': the Notification Recipient received all of
+ the Event Notification Attribute Groups and was expecting
+ each of them.
+
+ 'successful-ok-ignored-notifications': the Notification
+ Recipient was able to consume some, but not all of the
+ Event Notification Attributes Groups sent. The Event
+ Notification Attributes Groups with a "notify-status-
+ code" attribute are the ones that were ignored or are to
+ be canceled.
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 18]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ 'client-error-ignored-all-notifications': the Notification
+ Recipient was unable to consume any of the Event
+ Notification Attributes Groups sent. The Event
+ Notification Attributes Groups with a "notify-status-
+ code" attribute are the ones that were ignored or are to
+ be canceled.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as defined in [RFC2911] section 3.1.4.1.
+
+ Group 2 to N: Notification Attributes
+
+ These groups MUST be returned if and only if the "status-code"
+ parameter returned in Group 1 is anything but the 'successful-ok'
+ status code.
+
+ "notify-status-code" (type2 enum)
+ Indicates whether the Notification Recipient was able to
+ consume the n-th Notification Report as follows:
+
+ 'successful-ok' - this Event Notification Attribute Group
+ was consumed
+ 'client-error-not-found' - this Event Notification
+ Attribute Group was not able to be consumed. The Printer
+ MUST cancel the Subscription and MUST NOT attempt to send
+ any further Event Notifications from the associated
+ Subscription object.
+ 'successful-ok-but-cancel-subscription' - the Event
+ Notification Attribute Group was consumed, but the
+ Notification Recipient wishes to cancel the Subscription
+ object. The Printer MUST cancel the Subscription and
+ MUST NOT attempt to send any further Event Notifications
+ from the associated Subscription object.
+
+9 Status Codes
+
+ This section lists status codes whose meaning have been extended
+ and/or defined for returning in Event Notification Attribute Groups
+ as the value of the "notify-status-code" operation attribute. The
+ code values are allocated in the same space as the status codes in
+ [RFC2911].
+
+
+9.1 Additional Status Codes
+
+ The following status codes are defined as extensions for Notification
+ and are returned as the value of the "status-code" parameter in the
+ Operation Attributes Group of a response (see [RFC2911] section
+ 3.1.6.1). Operations in this document can also return the status
+
+Parra, Hastings Expires: August 28, 2001 [page 19]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ codes defined in section 13 of [RFC2911]. The 'successful-ok' status
+ code is an example of such a status code.
+
+
+9.1.1 successful-ok-ignored-notifications (0x0004)
+
+ The Notification Recipient was able to consume some, but not all, of
+ the Event Notifications Attributes Groups sent by the Printer in the
+ Send-Notifications request. See section 8.1.2 for further details.
+
+
+9.1.2 client-error-ignored-all-notifications (0x0416)
+
+ The Notification Recipient was unable to consume any of the Event
+ Notification Attributes Groups sent by the Printer. The Event
+ Notification Attributes Groups with a "notify-status-code" attribute
+ are the ones that were ignored or are to be canceled.
+
+
+9.2 Status Codes returned in Event Notification Attributes Groups
+
+ This section contains values of the "notify-status-code" attribute
+ that the Notification Recipient returns in a Event Notification
+ Attributes Group in a response when the corresponding Event
+ Notification Attributes Group in the request:
+
+ 1.was not consumed OR
+
+ 2.was consumed, but the Notification Recipient wants to cancel the
+ corresponding Subscription object
+
+ The following sections are ordered in decreasing order of importance
+ of the status-codes.
+
+
+9.2.1 client-error-not-found (0x0406)
+
+ This status code is defined in [RFC2911]. This document extends its
+ meaning and allows it to be returned in an Event Notification
+ Attributes Group of a response.
+
+ The Notification Recipient was unable to consume this Event
+ Notification Attributes Group because it was not expected. See
+ section 8.1.2 for further details.
+
+
+9.2.2 successful-ok-but-cancel-subscription (0x0006)
+
+ The Notification Recipient was able to consume this Event
+ Notification Attributes Group that the Printer sent, but wants the
+
+Parra, Hastings Expires: August 28, 2001 [page 20]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ corresponding Subscription object to be canceled none-the-less. See
+ section 8.1.2 for further details.
+
+
+10 Encoding and Transport
+
+ This section defines the encoding and transport used by the 'indp'
+ Delivery Method.
+
+
+10.1 Encoding of the Operation Layer
+
+ The 'indp' Delivery Method uses the IPP operation layer encoding
+ described in [RFC2910] and the Event Notification Attributes Group
+ tag allocated by [ipp-ntfy] as shown in Table 7:
+
+ Table 7 - The "event-notification-attributes-tag" value
+
+
+ Tag Value (Hex) Meaning
+
+
+ 0x07 "event-notification-attributes-tag"
+
+
+
+10.2 Encoding of Transport Layer
+
+ The 'indp' Notification Delivery Method uses the IPP transport layer
+ encoding described in [RFC2910].
+
+ It is REQUIRED that an 'indp' Notification Recipient implementation
+ support HTTP over the IANA assigned Well Known Port assigned to the
+ 'indp' Delivery Method as its default port by IANA (see section 13),
+ though a Notification Recipient implementation MAY support HTTP over
+ some other port as well.
+
+
+11 Conformance Requirements
+
+ This section defines conformance requirements for Printers and
+ Notification Recipients.
+
+
+11.1 Conformance Requirements for Printers
+
+ The 'indp' Delivery Method is RECOMMENDED for a Printer to support.
+
+ IPP Printers that conform to this specification:
+
+
+Parra, Hastings Expires: August 28, 2001 [page 21]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ 1.MUST meet the conformance requirements defined in [ipp-ntfy].
+
+ 2.MUST support the conformance requirements for Subscription object
+ attributes defined in section 5, including the syntax for the
+ "notify-recipient-uri" Subscription Object attribute defined in
+ section 5.2.1.
+
+ 3.MUST support the conformance requirements for Printer Description
+ object attributes defined in section 6.
+
+ 4.MUST support the 'indp' protocol by sending Event Notifications
+ using the Send-Notifications operation defined in section 8.1.
+
+ 5.MUST send INDP URLs (e.g., in the "notify-recipient-uri" attribute
+ in 'Send-Notifications') that conform to the ABNF specified in
+ section 12.5 of this document;
+
+ 6.MUST send INDP operations via the port specified in the INDP URL
+ (if present) or otherwise via IANA assigned well-known port [TBD];
+
+ 7.MUST convert INDP URLs to their corresponding HTTP URL forms by
+ the same rules used to convert IPP URLs to their corresponding
+ HTTP URL forms (see section 5 'IPP URL Scheme' in [RFC2910]).
+
+
+11.2 Conformance Requirements for INDP Notification Recipients
+
+ INDP Notification Recipients that conform to this specification:
+
+ 1.MUST accept Send-Notifications requests and return Send-
+ Notifications responses as defined in sections 8 and 9.
+
+ 2.SHOULD reject received INDP URLs in "application/ipp" request
+ bodies (e.g., in the "notify-recipient-uri" attribute in 'Send-
+ Notifications') that do not conform to the ABNF for INDP URLs
+ specified in section 12.5 of this document;
+
+ 3.MUST listen for INDP operations on IANA-assigned well-known port
+ [TBD], unless explicitly configured by system administrators or
+ site policies;
+
+ 4.SHOULD NOT listen for INDP operations on any other port, unless
+ explicitly configured by system administrators or site policies.
+
+
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 22]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+12 INDP URL Scheme
+
+
+12.1 INDP URL Scheme Applicability and Intended Usage
+
+ This section is intended for use in registering the "indp" URL scheme
+ with IANA and fully conforms to the requirements in [RFC2717]. This
+ document defines the "indp" URL (Uniform Resource Locator) scheme for
+ specifying the location of an INDP Notification Recipient object
+ which implements IPP Notification Delivery Protocol (INDP) specified
+ in this document.
+
+ The intended usage of the "indp" URL scheme is COMMON.
+
+
+12.2 INDP URL Scheme Associated INDP Port
+
+ All INDP URLs which do NOT explicitly specify a port MUST be used
+ over IANA-assigned well-known port [TBD] for the INDP protocol.
+
+ See: IANA Port Numbers Registry [IANA-PORTREG].
+
+
+12.3 INDP URL Scheme Associated MIME Type
+
+ All INDP protocol operations (requests and responses) MUST be
+ conveyed in an "application/ipp" MIME media type as registered in
+ [IANA-MIMEREG]. INDP URLs MUST refer to INDP Notification Recipient
+ objects which support this "application/ipp" MIME media type.
+
+ See: IANA MIME Media Types Registry [IANA-MIMEREG].
+
+
+12.4 INDP URL Scheme Character Encoding
+
+ The INDP URL scheme defined in this document is based on the ABNF for
+ the HTTP URL scheme defined in HTTP/1.1 [RFC2616], which is derived
+ from the URI Generic Syntax [RFC2396] and further updated by
+ [RFC2732] and [RFC2373] (for IPv6 addresses in URLs). The INDP URL
+ scheme is case-insensitive in the host name or host address part;
+ however the path part is case-sensitive, as in [RFC2396]. Code
+ points outside [US-ASCII] MUST be hex escaped by the mechanism
+ specified in [RFC2396].
+
+
+12.5 INDP URL Scheme Syntax in ABNF
+
+ This section is intended for use in registering the "indp" URL scheme
+ with IANA and fully conforms to the requirements in [RFC2717]. This
+ document defines the "indp" URL (Uniform Resource Locator) scheme for
+
+Parra, Hastings Expires: August 28, 2001 [page 23]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ specifying the location of an INDP Notification Recipient object
+ which implements IPP Notification Delivery Protocol (INDP) specified
+ in this document.
+
+ The intended usage of the "indp" URL scheme is COMMON.
+
+ The IPP protocol places a limit of 1023 octets (NOT characters) on
+ the length of a URI (see section 4.1.5 'uri' in [RFC2911]). An INDP
+ Notification Recipient MUST return 'client-error-request-value-too-
+ long' (see section 13.1.4.10 in [RFC2911]) when a URI received in a
+ request is too long.
+
+ Note: INDP Notification Recipients ought to be cautious about
+ depending on URI lengths above 255 bytes, because some older client
+ or proxy implementations might not properly support these lengths.
+
+ INDP URLs MUST be represented in absolute form. Absolute URLs always
+ begin with a scheme name followed by a colon. For definitive
+ information on URL syntax and semantics, see "Uniform Resource
+ Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This
+ specification adopts the definitions of "port", "host", "abs_path",
+ and "query" from [RFC2396], as updated by [RFC2732] and [RFC2373]
+ (for IPv6 addresses in URLs).
+
+ The INDP URL scheme syntax in ABNF is as follows:
+
+ indp_URL = "indp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+
+ If the port is empty or not given, IANA-assigned well-known port
+ [TBD] is assumed. The semantics are that the identified resource
+ (see section 5.1.2 of [RFC2616]) is located at the INDP Notification
+ Recipient listening for HTTP connections on that port of that host,
+ and the Request-URI for the identified resource is 'abs_path'.
+
+ Note: The use of IP addresses in URLs SHOULD be avoided whenever
+ possible (see [RFC1900]).
+
+ If the 'abs_path' is not present in the URL, it MUST be given as "/"
+ when used as a Request-URI for a resource (see section 5.1.2 of
+ [RFC2616]). If a proxy receives a host name which is not a fully
+ qualified domain name, it MAY add its domain to the host name it
+ received. If a proxy receives a fully qualified domain name, the
+ proxy MUST NOT change the host name.
+
+
+12.5.1 INDP URL Examples
+
+ The following are examples of valid INDP URLs for Notification
+ Recipient objects (using DNS host names):
+
+
+Parra, Hastings Expires: August 28, 2001 [page 24]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ indp://abc.com
+ indp://abc.com/listener
+
+ Note: The use of IP addresses in URLs SHOULD be avoided whenever
+ possible (see [RFC1900]).
+
+ The following literal IPv4 addresses:
+
+ 192.9.5.5 ; IPv4 address in IPv4 style
+ 186.7.8.9 ; IPv4 address in IPv4 style
+
+ are represented in the following example INDP URLs:
+
+ indp://192.9.5.5/listener
+ indp://186.7.8.9/listeners/tom
+
+ The following literal IPv6 addresses (conformant to [RFC2373]):
+
+ ::192.9.5.5 ; IPv4 address in IPv6 style
+ ::FFFF:129.144.52.38 ; IPv4 address in IPv6 style
+ 2010:836B:4179::836B:4179 ; IPv6 address per RFC 2373
+
+ are represented in the following example INDP URLs:
+
+ indp://[::192.9.5.5]/listener
+ indp://[::FFFF:129.144.52.38]/listener
+ indp://[2010:836B:4179::836B:4179]/listeners/tom
+
+
+12.5.2 INDP URL Comparisons
+
+ When comparing two INDP URLs to decide if they match or not, an INDP
+ Client SHOULD use a case-sensitive octet-by-octet comparison of the
+ entire URLs, with these exceptions:
+
+ . A port that is empty or not given is equivalent to the well-
+ known port for that INDP URL (port [TBD]);
+
+ . Comparisons of host names MUST be case-insensitive;
+
+ . Comparisons of scheme names MUST be case-insensitive;
+
+ . An empty 'abs_path' is equivalent to an 'abs_path' of "/".
+
+ Characters other than those in the "reserved" and "unsafe" sets (see
+ [RFC2396] and [RFC2732]) are equivalent to their ""%" HEX HEX"
+ encoding.
+
+ For example, the following three URIs are equivalent:
+
+
+Parra, Hastings Expires: August 28, 2001 [page 25]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ indp://abc.com/~smith/listener
+ indp://ABC.com/%7Esmith/listener
+ indp://ABC.com:/%7esmith/listener
+
+
+13 IANA Considerations
+
+ IANA is requested to register the indp URL scheme as defined in
+ section 12.
+
+ IANA is requested to assign a default system port (less than 1024)
+ for use with the indp URL as defined in section 12.
+
+ The rest of this section contains the exact information for IANA to
+ add to the IPP Registries according to the procedures defined in RFC
+ 2911 [RFC2911] section 6.
+
+ Note to RFC Editors: Replace RFC NNNN below with the RFC number
+ for this document, so that it accurately reflects the content of
+ the information for the IANA Registry.
+
+
+13.1 Operation Registrations
+
+ The operations defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.4 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/operations/
+
+ The registry entry will contain the following information:
+
+ Operations: Ref. Section:
+ Send-Notifications operation RFC NNNN 8.1
+
+
+13.2 Additional values of existing attributes
+
+
+13.2.1 Additional values for the "notify-schemes-supported" Printer
+ attribute
+
+ The "notify-schemes-supported" uriScheme attribute value defined in
+ this document will be published by IANA according to the procedures
+ in RFC 2911 [RFC2911] section 6.1 with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attribute-values/notify-schemes-
+ supported/
+
+ The registry entry will contain the following information:
+
+Parra, Hastings Expires: August 28, 2001 [page 26]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ Ref. Section:
+ indp RFC NNNN 6.2.1
+
+
+13.2.2 Additional values for the "operations-supported" Printer
+ attribute
+
+ The "operations-supported" type2 enum attribute value defined in this
+ document will be published by IANA according to the procedures in RFC
+ 2911 [RFC2911] section 6.1 with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attribute-values/operations-
+ supported/
+
+ The registry entry will contain the following information:
+
+ Value Ref. Section:
+ Send-Notifications 0x001D RFC NNNN 6.2.1
+
+
+13.3 Status code Registrations
+
+ The status codes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.6 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/status-codes/
+
+ The registry entry will contain the following information:
+
+ Status codes: Ref. Section:
+ successful-ok-ignored-notifications (0x0004) RFC NNNN 9.1.1
+ client-error-ignored-all-notifications (0x0416) RFC NNNN 9.1.2
+
+
+
+14 Internationalization Considerations
+
+ When the client requests Human Consumable form by supplying the
+ "notify-text-format" operation attribute (see [ipp-ntfy]), the IPP
+ Printer (or any Notification Service that the IPP Printer might be
+ configured to use) supplies and localizes the text value of the
+ "human-readable-report" attribute in the Notification according to
+ the charset and natural language requested in the notification
+ subscription.
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 27]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+15 Security Considerations
+
+ The IPP Model and Semantics document [RFC2911] discusses high level
+ security requirements (Client Authentication, Server Authentication
+ and Operation Privacy). Client Authentication is the mechanism by
+ which the client proves its identity to the server in a secure
+ manner. Server Authentication is the mechanism by which the server
+ proves its identity to the client in a secure manner. Operation
+ Privacy is defined as a mechanism for protecting operations from
+ eavesdropping.
+
+ The Notification Recipient can cancel unwanted Subscriptions created
+ by other parties without having to be the owner of the subscription
+ by returning the 'successful-ok-but-cancel-subscription' status code
+ in the Send-Notifications response returned to the Printer.
+
+15.1 Security Conformance
+
+ Printers (client) MAY support Digest Authentication [RFC2617]. If
+ Digest Authentication is supported, then MD5 and MD5-sess MUST be
+ supported, but the Message Integrity feature NEED NOT be supported.
+
+ Notification Recipient (server) MAY support Digest Authentication
+ [RFC2617]. If Digest Authentication is supported, then MD5 and MD5-
+ sess MUST be supported, but the Message Integrity feature NEED NOT be
+ supported.
+
+ Notification Recipients MAY support TLS for client authentication,
+ server authentication and operation privacy. If a Notification
+ Recipient supports TLS, it MUST support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC
+ 2246 [RFC2246]. All other cipher suites are OPTIONAL. Notification
+ recipients MAY support Basic Authentication (described in HTTP/1.1
+ [RFC2616]) for client authentication if the channel is secure. TLS
+ with the above mandated cipher suite can provide such a secure
+ channel.
+
+
+16 References
+
+
+ [ipp-iig]
+ Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P.,
+ "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers-
+ guide-v11-02.txt, work in progress, January 25, 2001
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 28]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ [ipp-ntfy]
+ Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
+ Bergman, R., "Internet Printing Protocol/1.1: IPP Event
+ Notification Specification", <draft-ietf-ipp-not-spec-06.txt>,
+ January 24, 2001.
+
+ [IANA-MIMEREG]
+ IANA MIME Media Types Registry. ftp://ftp.isi.edu/in-
+
+ notes/iana/assignments/media-types/
+
+
+ [IANA-PORTREG]
+ IANA Port Numbers Registry. ftp://ftp.isi.edu/in-
+
+ notes/iana/assignments/port-numbers
+
+
+ [RFC1900]
+ B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC 1900,
+ February 1996.
+
+ [RFC2026]
+ S. Bradner, "The Internet Standards Process -- Revision 3", RFC
+ 2026, October 1996.
+
+ [RFC2373]
+ R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC
+ 2373, July 1998.
+
+ [RFC2396]
+ Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic
+ Syntax, RFC 2396, August 1998
+
+ [RFC2616]
+ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
+ Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2617]
+ J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.
+ Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access
+ Authentication", RFC 2617, June 1999.
+
+ [RFC2717]
+ R. Petke and I. King, "Registration Procedures for URL Scheme
+ Names", RFC 2717, November 1999.
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 29]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ [RFC2732]
+ R. Hinden, B. Carpenter, L. Masinter. Format for Literal IPv6
+ Addresses in URL's, RFC 2732, December 1999.
+
+ [RFC2910]
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", RFC 2910, September 2001.
+
+ [RFC2911]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911,
+ September 2001.
+
+
+17 Author's Addresses
+
+ Hugo Parra
+ Novell, Inc.
+ 1800 South Novell Place
+
+ Provo, UT 84606
+
+ Phone: 801-861-3307
+ Fax: 801-861-2517
+ e-mail: hparra@novell.com
+
+ Tom Hastings
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+
+18 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). 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
+
+Parra, Hastings Expires: August 28, 2001 [page 30]
+\f
+
+INTERNET-DRAFT IPP: The 'indp' Method and Protocol February 28, 2001
+
+
+ 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 RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parra, Hastings Expires: August 28, 2001 [page 31]
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT
+<draft-ietf-ipp-install-02.txt>
+[Target category: standards track] Hugo Parra
+ Novell, Inc.
+ Ted Tronson
+ Novell, Inc.
+ Tom Hastings
+ Xerox Corp.
+ February 28, 2001
+ Internet Printing Protocol (IPP):
+ Printer Installation Extension
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+Abstract
+
+ Various client platforms require that some setting up take place at
+ the workstation before the client can properly submit jobs to a
+ specific printer. This setup process is sometimes referred to as
+ printer installation. Most clients need some information about the
+ printer being installed as well as support files to complete the
+ printer installation. The nature of the support files varies
+ depending on the specific client platform, from simple configuration
+ files to highly sophisticated printer drivers. This document refers
+ to these support files as "Client Print Support Files".
+ Traditionally, the selection and installation of the correct Client
+ Print Support Files has been error prone. The selection and
+ installation process can be simplified and even automated if the
+ workstation can learn some key information about the printer and
+ which sets of Client Print Support Files are available. Such key
+ information includes: operating system type, CPU type, document-
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 1]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ format (PDL), natural language, compression mechanism, file type,
+ client file name, policy for automatic loading, file size, file
+ version, file date and time, file information description, and
+ digital signature. This document describes the IPP extensions that
+ enable workstations to obtain the information needed to perform a
+ proper printer driver installation using IPP, including security for
+ downloading executable code and data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 2]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
+ Mapping between LPD and IPP Protocols [RFC2569]
+
+ The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that
+ are satisfied in IPP/1.0. A few OPTIONAL operator operations have
+ been added to IPP/1.1.
+
+ The "Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol" document describes IPP from a high level
+ view, defines a roadmap for the various documents that form the suite
+ of IPP specification documents, and gives background and rationale
+ for the IETF working group's major decisions.
+
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1 [RFC2616]. It defines the
+ encoding rules for a new Internet MIME media type called
+ "application/ipp". This document also defines the rules for
+ transporting a message body over HTTP whose Content-Type is
+ "application/ipp". This document defines a new scheme named 'ipp'
+ for identifying IPP printers and jobs.
+
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 3]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+
+Table of Contents
+
+ 1 Introduction....................................................6
+
+
+ 2 Terminology.....................................................6
+
+
+ 3 Model Extensions................................................7
+
+ 3.1 client-print-support-files-supported (1setOf octetString(MAX))
+
+ ..........................................................7
+ 3.1.1 Use of Keyword Values in fields.............................12
+
+ 3.1.2 Use of the Special Keyword Value: 'unknown'.................12
+
+ 3.1.3 Examples of "client-print-support-files-supported" attribute
+
+ values.................................................12
+
+ 3.2 Get-Printer-Attributes Operation Extension..................13
+
+ 3.2.1 Get-Printer-Attributes Request..............................13
+
+ 3.2.1.1 client-print-support-files-filter (octetString(MAX))
+
+ operation attribute..................................13
+
+ 3.2.1.1.1 Filter matching rules.................................15
+
+ 3.2.2 Get-Printer-Attributes Response.............................16
+
+ 3.3 Get-Client-Print-Support-Files..............................17
+
+ 3.3.1 Get-Client-Print-Support-Files Request......................17
+
+ 3.3.2 Get-Client-Print-Support-Files Response.....................18
+
+
+ 4 Conformance....................................................19
+
+
+ 5 Encoding of the Operation Layer................................20
+
+
+ 6 Encoding of Transport Layer....................................20
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 4]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ 7 IANA Considerations............................................20
+
+ 7.1 Attribute Registrations.....................................21
+
+ 7.2 Operation Registrations.....................................22
+
+
+ 8 Internationalization Considerations............................22
+
+
+ 9 Security Considerations........................................22
+
+
+ 10 References.....................................................23
+
+
+ 11 Author's Addresses.............................................24
+
+
+ 12 Full Copyright Statement.......................................25
+
+
+
+Tables
+
+ Table 1 - "client-print-support-files-supported" attribute fields..9
+
+ Table 2 - "client-print-support-files-filter" attribute fields....14
+
+ Table 3 - REQUIRED "client-print-support-files-filter" fields.....14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 5]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+1 Introduction
+
+ A common configuration for printing from a workstation requires that
+ some Client Print Support Files (e.g., PPD, printer driver files)
+ specific to the target printer be installed on that workstation.
+ Selection and configuration of the appropriate Client Print Support
+ Files can be simplified and even automated if the workstation can
+ obtain some key information about the printer and which sets of
+ Client Print Support Files are available. Such key information
+ includes: operating system type, CPU type, document-format (PDL),
+ natural language, compression mechanism, file type, client file name,
+ policy for automatic loading, file size, file version, file date and
+ time, file information description, and digital signature. With a
+ few extensions, IPP provides a simple and reliable vehicle for
+ printers to convey this information to interested workstations. The
+ IPP extensions described in this document enable a flexible solution
+ for installing Client Print Support Files on workstations running
+ different operating systems and for printers of all makes and models.
+ It allows Client Print Support Files to be downloaded from
+ repositories of different sorts. A possible repository for the files
+ is the printer itself. The extensions necessary for getting Client
+ Print Support Files from the printer are included in this document,
+ including security for downloading executable code and data.
+
+
+2 Terminology
+
+ Client Print Support Files - a set of files, such as a printer
+ driver, font metric file, printer configuration file (PPD, GPD, etc.)
+ that support a client printing to a particular Printer. A Printer
+ MAY have multiple sets of Client Print Support Files that work for
+ different operating systems, document formats, natural languages,
+ CPUs, etc.
+
+ This document uses terms such as "attributes", "keywords", and
+ "support". These terms have special meaning and are defined in the
+ model terminology [RFC2911] section 12.2. This document also uses
+ the terms "IPP Printer", "Printer" and "Printer object"
+ interchangeably as in [RFC2911] to mean the software entity that
+ accepts IPP operation requests and returns IPP operation responses
+ (see [RFC2911] section 2).
+
+ Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+ NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+ conformance. These terms are defined in [RFC2911] section 12.1 on
+ conformance terminology, most of which is taken from RFC 2119
+ [RFC2119].
+
+ This section defines the following additional terms that are used
+ throughout this document:
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 6]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ REQUIRED: if an implementation supports the extensions described
+ in this document, it MUST support a REQUIRED feature.
+ OPTIONAL: if an implementation supports the extensions described
+ in this document, it MAY support an OPTIONAL feature.
+
+3 Model Extensions
+
+ To assist workstations in the printer installation process, an IPP
+ printer needs to provide the workstation with information about the
+ Client Print Support Files, such as the their name and location/s.
+ This information needs to match the workstation's specific
+ environment, such as its operating system, preferred natural
+ language, and preferred document format.
+
+ The following extensions to the IPP model enable assisted or
+ automated printer installation. This section describes each
+ extension in detail.
+
+
+ - A new REQUIRED Printer Description attribute: "client-print-
+ support-files-supported" (1setOf octetString(MAX)).
+ - A new REQUIRED Get-Printer-Attributes operation attribute:
+ "client-print-support-files-filter" (octetString(MAX)).
+ - A new RECOMMENDED printer operation: Get-Client-Print-Support-
+ Files.
+
+
+3.1 client-print-support-files-supported (1setOf octetString(MAX))
+
+ An IPP Printer uses the REQUIRED Printer Description attribute
+ "client-print-support-files-supported" to represent relevant
+ information about all of the Client Print Support Files it supports.
+ Each value is a composite UTF-8 string with well-defined fields (see
+ Table 1). Each value string MUST be formatted as follows:
+
+ "uri=val1< field-name2=val21,_,val2p< _ < field-namen=valn1,_,valnq<"
+
+ The first field MUST be the "uri" field. The remaining fields MAY be
+ in any order.
+
+ The string MUST NOT include any control characters (hex 00 to 1F),
+ even the so-called white space control characters (TAB, CR, and LF)
+ anywhere. Only zero or more UTF-8 SPACE characters (hex 20) can be
+ included and they can be included only IMMEDIATELY AFTER the
+ delimiter character: "<", but NOT anywhere else, including after "="
+ and ",". However, if the UTF-8 SPACE character is needed in a
+ client-file-name value, then each occurrence is included directly,
+ without escaping (see example). On the other hand, if the UTF-8
+ SPACE character is needed in a URL value, then each occurrence is
+ escaped as: "%20" (URI conventions - see [RFC2396]).
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 7]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ Table 1 lists the REQUIRED fields that a Printer MUST support and the
+ OPTIONAL fields that a Printer MAY support in the "client-print-
+ support-files-supported" (1setOf octetString(MAX)) Printer
+ Description attribute. A Printer implementation MAY support
+ additional fields using the same syntax. Values are defined to be
+ either CASE-SENSITIVE or ALL-LOWER-CASE according to the definitions
+ for the attribute syntaxes from [RFC2911] (set off by single quotes
+ in the table). The CASE-SENSITIVE values MAY have upper and lower
+ case letters as for the corresponding attribute syntaxes in
+ [RFC2911]. The LOWER-CASE values MUST have all lower case alphabetic
+ letters. Additional characters, such as digits, hyphen-minus (-),
+ period (.), and slash (/) are according to the corresponding
+ attribute syntaxes in [RFC2911].
+
+ Clients SHOULD ignore fields they don't recognize in a given value.
+ This allows for future extensions to the format of the string without
+ breaking compatibility with earlier clients.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 8]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ Table 1 - "client-print-support-files-supported" attribute fields
+
+
+ Field Field value
+ name
+
+
+ "uri" One REQUIRED CASE-SENSITIVE 'uri' string identifying the
+ uri where to obtain the support files for each OS
+ platform, document format, and natural language the
+ printer supports. This MUST be the first field in each
+ value. Examples of uri schemes that MAY be found here
+ are 'ftp', 'http', and 'ipp'. The 'ftp' and 'http'
+ schemed URIs identify the archive file that contains all
+ the necessary client support files.
+
+ The 'ipp' schemed URIs identify the archive file that
+ clients MAY obtain from the Printer using the Get-
+ Client-Print-Support-Files operation (see section 3.3).
+ The URI MUST be a valid URI to the same Printer object,
+ i.e., one of the values of the Printer's "printer-uri-
+ supported" attribute. The 'ipp' URI is used to
+ distinguish between multiple Client Print Support Files
+ in an implementation dependent manner using the URL
+ query syntax (e.g., "?drv-id=xxx") [RFC2396]. The
+ query part MUST NOT exceed 127 octets, not counting the
+ "?" character that begins the query part. A Printer
+ SHOULD support the 'ipp' scheme.
+
+ "os-type" One or more REQUIRED comma-separated LOWER-CASE
+ 'keyword' strings identifying the operating system types
+ supported by this set of Client Print Support Files.
+ Valid values are the operating system names defined in
+ the IANA document [os-names] and the special keyword
+ value: 'unknown'. Although the IANA registry requires
+ that the names be all upper-case, the values MUST be all
+ lower case in this field (plus hyphen-minus (-), period
+ (.), and slash (/)). Examples: 'linux', 'linux-2.2',
+ 'os/2', 'sun-os-4.0', 'unix', 'unix-bsd', 'win32',
+ 'windows-95', 'windows-98', 'windows-ce', 'windows-nt',
+ 'windows-nt-4', 'windows-nt-5', 'unknown'.
+
+ "cpu- One or more REQUIRED comma-separated LOWER-CASE
+ type" 'keyword' strings identifying the CPU types supported by
+ this set of Client Print Support Files. The values
+ indicate the CPU family independent of the CPU
+ manufacturer. Valid keyword values are: 'x86-16',
+ 'x86-32', 'x86-64', 'dec-vax', 'alpha', 'power-pc', 'm-
+ 68000, 'sparc', 'itantium', 'mips', 'arm' and will be
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 9]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+
+ Field Field value
+ name
+
+
+ used as the initial value for the "cpu-type" IANA
+ registry. In addition, the special keyword value:
+ 'unknown' is valid.
+
+ "document One or more REQUIRED comma-separated CASE-SENSITIVE
+ -format" 'mimeMediaType' strings identifying the document formats
+ supported by this set of Client Print Support Files.
+ Valid values are the string representation of the IPP
+ mimeMediaType attribute syntax (see [RFC2911] section
+ 4.1.9), for example 'application/postscript'. In
+ addition, the special keyword value: 'unknown' is valid.
+
+ "natural- One or more REQUIRED comma-separated LOWER-CASE
+ language" 'naturalLanguage' strings identifying the natural
+ language used by this set of Client Print Support Files.
+ Valid values are the string representation of the IPP
+ 'naturalLanguage' attribute syntax (see [RFC2911]
+ section 4.1.8), for example 'en' and 'en-us'. In
+ addition, the special keyword value: 'unknown' is valid.
+
+ "compress One REQUIRED LOWER-CASE 'keyword' string identifying the
+ ion" mechanism used to compress this set of Client Print
+ Support Files. All files needed for the installation of
+ a printer driver MUST be compressed into a single file.
+ Valid keyword values are the keywords defined by
+ [RFC2911] or registered with IANA for use in the IPP
+ "compression" and "compression-supported" attributes.
+ See [RFC2911] section 4.4.32), for example 'gzip'. The
+ 'none' value limits the uncompressed Client Print
+ Support File to a single file. The values for the
+ "compression" field that a Printer supports NEED NOT be
+ the same values that the Printer is configured to
+ support in Job Creation operations as indicated in the
+ Printer's "compressions-supported" attribute.
+
+ "file- One or more REQUIRED comma-separated LOWER-CASE
+ type" 'keyword' strings identifying the type of the Client
+ Print Support Files. Valid keyword values are:
+ 'printer-driver', 'ppd', 'updf', 'gpd'.
+
+ "client- One REQUIRED CASE-SENSITIVE string identifying the name
+ file- by which the Client Print Support Files will be
+ name" installed on the workstation. For Client Print Support
+ Files of type 'printer-driver', this is also the name
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 10]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+
+ Field Field value
+ name
+
+
+ that identifies this printer driver in an .inf file.
+
+ "policy" One OPTIONAL LOWER-CASE 'keyword' string indicating the
+ policy for automatic loading. Valid keyword values are:
+ 'manufacturer-recommended', 'administrator-recommended',
+ 'manufacturer-experimental, 'administrator-
+ experimental'. The experimental values are for beta
+ test.
+
+ "file- One OPTIONAL file size in octets represented as ASCII
+ size" decimal digits.
+
+ "file- One OPTIONAL LOWER-CASE version number. Recommended to
+ version" be of the form "Major.minor[.revision]" where "Major" is
+ the major version number, "minor" is the minor version
+ number and "revision" is an optional revision number.
+
+ "file- One OPTIONAL File CASE-SENSITIVE creation date and time
+ date- according to ISO 8601 where all fields are fixed length
+ time" with leading zeroes (see [RFC2518] Appendix 2).
+ Examples: 2000-01-01T23:09:05Z and 2000-01-01T02:59:59-
+ 04.00
+
+ "file- One OPTIONAL CASE-SENSITIVE human readable 'text' string
+ info" describing this set of Client Print Support Files. The
+ natural language for this value MUST be the natural
+ language indicated by the Printer's "natural-language-
+ configured" attribute. To avoid exceeding the maximum
+ limit imposed on IPP attributes and to increase
+ interoperability with other systems, the length of this
+ field value MUST not exceed 127 characters.
+
+ "digital- One REQUIRED LOWER-CASE 'keyword' string identifying the
+ signature mechanism used to ensure the integrity and authenticity
+ " of this set of Client Print Support Files. Valid values
+ are: 'smime', 'pgp', 'dss', and 'xmldsig' which are
+ defined in [RFC2634], [RFC1991], [dss], and [xmldsig],
+ respectively. In addition, the special keyword value:
+ 'none' is valid.
+
+
+ Each value MUST refer to one and only one set of Client Print Support
+ Files, even if the files are downloadable from various repositories
+ (i.e., even if they are associated with multiple URIs).
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 11]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+3.1.1 Use of Keyword Values in fields
+
+ A number of the fields in Table 1 use keyword strings as values. The
+ syntax of these keywords is the same as in [RFC2911], including the
+ use of private keywords. See [RFC2911] sections 4.1.3 and 6.1.
+ Printer implementers are strongly RECOMMENDED to submit additional
+ keyword values for registration with IANA according to the procedures
+ for registering attributes. See section 7 and [RFC2911] section 6.1.
+
+
+3.1.2 Use of the Special Keyword Value: 'unknown'
+
+ A number of REQUIRED 'keyword' value fields have a special keyword
+ value: 'unknown' defined. This value is intended for use when the
+ actual value is not known, such as by an administrator automatic
+ software configuring the IPP Printer object. However, it is strongly
+ RECOMMENDED that other more meaningful values be used, instead of the
+ 'unknown' value whenever possible.
+
+
+3.1.3 Examples of "client-print-support-files-supported" attribute
+ values
+
+ The following illustrates what two valid values of the "client-print-
+ support-files-supported" (1setOf octetString(MAX)) Printer
+ Description attribute might look like:
+
+ uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz<
+ os-type=windows-95< cpu-type=x86-32<
+ document-format=application/postscript<
+ natural-language=en< compression=gzip<
+ file-type=printer-driver<
+ client-file-name=CompanyX-ModelY-driver.gz<
+ policy=manufacturer-recommended<
+
+ uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz<
+ os-type=windows-95< cpu-type=x86-32<
+ document-format=application/postscript,application/vnd.hp-PCL<
+ natural-language=en,fr< compression=gzip<
+ file-type=printer-driver<
+ client-file-name=Company T Model Z driver.gz<
+ policy=manufacturer-recommended<
+
+ The above examples have been broken onto separate lines for
+ readability in this document. However, there MUST NOT be any line
+ breaks in the actual values.
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 12]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ The "client-print-support-files-supported" Printer Description
+ attribute MAY be preset at manufacturing time or through
+ administrative means outside the scope of this document.
+
+
+3.2 Get-Printer-Attributes Operation Extension
+
+ The "client-print-support-files-supported" Printer Description
+ attribute defined in section 3.1 contains information, such as
+ operating system, natural language, and document format, about all of
+ the sets of Client Print Support Files. This section defines an
+ extension to the Get-Printer-Attributes operation that allows a
+ workstation to filter out all but the Client Print Support Files of
+ interest.
+
+
+3.2.1 Get-Printer-Attributes Request
+
+ A Printer MAY contain information about multiple sets of Client Print
+ Support Files to match the different operating systems, natural
+ languages and document formats it supports. A workstation MAY query
+ this information by including the 'client-print-support-files-
+ supported' keyword as a value of the "requested-attributes" operation
+ attribute of the Get-Printer-Attributes operation.
+
+
+3.2.1.1 client-print-support-files-filter (octetString(MAX)) operation
+ attribute
+
+ The client can request a subset of the values of the "client-print-
+ support-files-supported" Printer attribute by supplying the "client-
+ print-support-files-filter" (octetString(MAX)) operation attribute in
+ the request as a filter. The filter value indicates in which Client
+ Print Support Files the client is interested. The client MAY supply
+ this attribute. The Printer MUST support this attribute.
+
+ The filter value of the "client-print-support-files-filter" attribute
+ is a composite string with the same format as that of "client-print-
+ support-files-supported" (see Table 1 - "client-print-support-files-
+ supported" attribute fields in section 3.1) with the following
+ exceptions:
+
+
+
+
+
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 13]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ Table 2 - "client-print-support-files-filter" attribute fields
+
+
+ Field Field Value in the "client-print-support-files-filter"
+ Name attribute
+
+
+ uri- One or more comma-separated LOWER-CASE 'uriScheme'
+ scheme string values identifying the uri scheme to be
+ filtered on. Valid values are the string
+ representation of the IPP 'uriScheme' attribute syntax
+ (see [RFC2911] section 4.1.6). Example URI schemes
+ are: 'ftp', 'http', and 'ipp'. The Printer SHOULD
+ support the 'ipp' scheme. If supplied by the client,
+ this field NEED NOT be first. If this field is
+ omitted by the client, the Printer returns all
+ schemes.
+
+ xxx One or more comma-separated values for any of the
+ fields defined in Table 1, with the single exception
+ of the "uri" field which a client MUST NOT supply and
+ a Printer MUST NOT support.
+ The Printer MUST support any filter field having more
+ than one value separated by a COMMA (,), including the
+ fields that Table 1 indicates MUST BE single valued.
+
+
+ Printer implementations MUST support the "client-print-support-files-
+ filter" operation attribute in a Get-Printer-Attributes request with
+ the member fields listed Table 3. Printers MAY support any
+ additional filter fields listed in Table 2.
+
+ Client implementations MAY supply any filter fields listed in Table 2
+ in the "client-print-support-files-filter" operation attribute of a
+ Get-Printer-Attributes request.
+
+ Table 3 - REQUIRED "client-print-support-files-filter" fields
+
+
+ uri-scheme
+
+ os-type
+
+ cpu-type
+
+ document-format
+
+ natural-language
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 14]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+3.2.1.1.1 Filter matching rules
+
+ The Printer returns only the values of the "client-print-support-
+ files-supported" Printer Description attribute that match the filter
+ in the "client-print-support-files-filter" operation attribute. The
+ following filter matching rules are defined:
+
+ 1. A match occurs if at least one value of each field supplied by
+ the client in the filter matches a Client Print Support File
+ value. Printers MUST ignore a filter field supplied by a client
+ that the Printer does not support and return a match if all
+ supported fields do match, no matter what value the client
+ supplied for that unsupported field. Similarly, Printers MUST
+ ignore a filter field supplied by a client that the Printer does
+ support, but which the field has not been populated for a Client
+ Print Support Files and return a match if all supported and
+ populated fields do match, no matter what value the client
+ supplied for that unpopulated field.
+
+ 2. A match for a CASE-INSENSITIVE field occurs independent of the
+ case of the letters supplied by the client and those stored by
+ the Printer, while a match for a LOWER-CASE field is a strict
+ character for character match.
+
+ 3. A match for a 'keyword' Printer field that is populated with the
+ 'unknown' special keyword value occurs for any value supplied by
+ the client for that field.
+
+ 4. If the "client-print-support-files-filter" operation attribute
+ filter is not supplied by the client, the printer SHOULD behave
+ as if the attribute had been provided with all fields left empty
+ (i.e., return an unfiltered list).
+
+ The following are two examples of a "client-print-support-files-
+ filter" filter value:
+
+ os-type=windows-95< cpu-type=x86-32<
+ document-format=application-postscript< natural-language=en,de<
+
+ uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32<
+ document-format=application-postscript< natural-language=en,de<
+
+ See section 3.2.2 for example matching responses.
+
+ It is RECOMMENDED that workstations first use the Get-Printer-
+ Attributes operation in combination with "client-print-support-files-
+ filter" operation attribute filter to get a list of the potential
+ Client Print Support Files that meet the workstation's requirements.
+ The workstation can then choose from the returned list which Client
+ Print Support Files to use and where to get them. If one of the URIs
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 15]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ returned is an IPP uri, the workstation can retrieve the Client Print
+ Support Files from an IPP printer via the Get-Client-Print-Support-
+ Files operation (see section 3.3).
+
+
+3.2.2 Get-Printer-Attributes Response
+
+
+ A Printer MUST return the "client-print-support-files-supported"
+ (1setOf octetString(MAX)) attribute in the Printer Object Attributes
+ group (group 3) when requested by a client. Each returned attribute
+ value MUST satisfy the criteria specified by the client in the
+ request.
+
+
+ For example, if the request contains the following "client-print-
+ support-files-filter" filter:
+
+ os-type=windows-95< cpu-type=x86-32<
+ document-format=application-postscript<
+ natural-language=en,de<
+
+ A conforming response is the following two octet String values:
+
+ uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz<
+ os-type=windows-95< cpu-type=x86-32<
+ document-format=application/postscript<
+ natural-language=en< compression=gzip<
+ file-type=printer-driver<
+ client-file-name=CompanyX-ModelY-driver.gz<
+ policy=manufacturer-recommended<
+ digital-signature=smime<
+
+ uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz<
+ os-type=windows-95< cpu-type=x86-32<
+ document-format=application/postscript,application/vnd.hp-PCL<
+ natural-language=en,fr< compression=gzip<
+ file-type=printer-driver<
+ client-file-name=CompanyX-ModelY-driver.gz<
+ policy=manufacturer-recommended<
+ digital-signature=smime<
+
+
+ These examples have been broken onto separate lines for readability
+ in this document. However, there MUST NOT be any line breaks in the
+ actual values.
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 16]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ As another example, if the above request had also contained the "uri-
+ scheme" field in the following "client-print-support-files-filter"
+ filter:
+
+ uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32<
+ document-format=application-postscript<
+ natural-language=en,de<
+
+ Then only the first value would have been returned as a single
+ octetString value:
+
+ uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz<
+ os-type=windows-95< cpu-type=x86-32<
+ document-format=application/postscript<
+ natural-language=en< compression=gzip<
+ file-type=printer-driver<
+ client-file-name=CompanyX-ModelY-driver.gz<
+ policy=manufacturer-recommended<
+ digital-signature=smime<
+
+3.3 Get-Client-Print-Support-Files
+
+ This RECOMMENDED operation allows a client to download Client Print
+ Support Files from an IPP Printer.
+
+
+3.3.1 Get-Client-Print-Support-Files Request
+
+
+ The following sets of attributes are part of the Get-Client-Print-
+ Support-Files request:
+
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911], section 3.1.4.1.
+
+ Target:
+ The "printer-uri" (uri) operation attribute which is the target
+ for this operation as described in [RFC2911], section 3.1.5.
+ The client MUST use the URI value as the target of this
+ operation that the Printer returns in the "uri" field (see Table
+ 1) in the Get-Printer-Attributes response. Furthermore, the
+ client MUST use the appropriate authorization and security
+ regime for this URI as indicated by the Printer's "printer-uri-
+ supported", "uri-authentication-supported" and "uri-security-
+ supported" attributes (see [RFC2911] sections 4.4.1, 4.4.2, and
+ 4.4.3). Only if the URI returned in the "uri" field matches the
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 17]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ URI that the client used for the Get-Printer-Attributes request
+ MAY the client use the same HTTP connection. The 'ipp' URL
+ matching rules are defined in [ipp-url] and do not include the
+ query part.
+
+ Requesting User Name:
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be
+ supplied by the client as described in [RFC2911], section 8.3.
+
+ "client-print-support-files-query" (text(127)):
+ The client MUST supply this attribute specifying the query part
+ [RFC2396] of the ipp uri for the desired Client Print Support
+ Files not including the "?" character that starts the query
+ part, i.e., the value of the "uri" field following the "?"
+ character returned by the Get-Printer-Attributes in one of the
+ values of the "client-print-support-files-supported" (1setOf
+ octetString(MAX)) Printer attribute (see Table 1) that had an
+ 'ipp' scheme.
+
+
+3.3.2 Get-Client-Print-Support-Files Response
+
+
+ The Printer object returns the following sets of attributes as part
+ of the Get-Client-Print-Support-Files Response:
+
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ In addition to the REQUIRED status code returned in every
+ response, the response OPTIONALLY includes a "status-message"
+ (text(255)) operation attribute as described in [RFC2911],
+ sections 13 and 3.1.6.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911], section 3.1.4.2.
+
+ Group 2: Unsupported Attributes
+ See [RFC2911], section 3.1.7 for details on returning Unsupported
+ Attributes.
+
+
+ Group 3: Printer Object Attributes
+ "client-print-support-files-supported" (octetString(MAX)).
+ This attribute identifies the properties of the returned Client
+ Print Support Files. The Printer object MUST return this
+ attribute if the response includes Group 4 (i.e., if a set of
+ Client Print Support Files identified by the supplied "client-
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 18]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ print-support-files-query" operation attribute was found). The
+ Printer MUST return all configured fields for the selected
+ Client Print Support Files in the format shown in section 3.1.
+
+
+ Group 4: Client Print Support Files
+ The printer MUST supply the Client Print Support Files that match
+ the client's criteria following the "end-of-attributes" tag. All
+ necessary files MUST be compressed into a single transferred file.
+
+
+4 Conformance
+
+ A Printer conforming to this specification:
+
+ 1.MUST support the "client-print-support-files-supported" Printer
+ Description attribute as defined in section 3.1, including all
+ of the REQUIRED fields defined in Table 1 and MAY support the
+ OPTIONAL fields defined in Table 1.
+
+ 2.MUST support the "client-print-support-files-filter" operation
+ attribute in the Get-Printer-Attributes request as defined in
+ section 3.2, including all of the fields listed in Table 3 and
+ ignoring any fields not recognized.
+
+ 3.MUST support at least one of the following URI schemes that
+ identify the support files: 'ftp', 'http', or 'ipp', of which
+ the 'ipp' scheme is the RECOMMENDED one.
+
+ 4.SHOULD support the Get-Client-Print-Support-Files operation as
+ described in section 3.3. If this operation is supported, then
+ one of the supported schemes MUST be 'ipp'.
+
+ 5.SHOULD support TLS as described in section 9.
+
+ 6.SHOULD support the downloading of Client Print Support Files
+ that have been digitally signed as described in section 9.
+
+ A client conforming to this specification:
+
+ 1.MUST ignore any fields returned by the Printer in the "client-
+ print-support-files-supported" Printer Description attribute
+ that the client does not recognize or support.
+
+ 2.SHOULD be able to retrieve Client Print Support Files by either
+ FTP Get or HTTP Get operations.
+
+ 3.MUST be able to retrieve Client Print Support Files using the
+ Get-Client-Print-Support-Files operation, i.e., support the
+ 'ipp' scheme.
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 19]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ 4.MUST supply the proper URI value for the "printer-uri" operation
+ attribute as specified in section 3.3.1 under Target:.
+
+ 5.MUST validate that files that are supposed to be digitally
+ signed are done with the indicated mechanism as described in
+ section 9.
+
+ 6.SHOULD support TLS as described in section 9.
+
+
+5 Encoding of the Operation Layer
+
+ This extension uses the operation layer encoding described in
+ [RFC2910].
+
+
+6 Encoding of Transport Layer
+
+ This specification uses the transport layer encoding described in
+ [RFC2910] with the following extensions.
+
+ New Error codes:
+
+ 0x0417 client-error-client-print-support-file-not-found
+
+ New Operation code
+
+ 0x0021 Get-Client-Print-Support-Files
+
+
+7 IANA Considerations
+
+ The IANA-registered operating system names that IANA has registered
+ [os-names] are required by this spec for use in the "os-type" field
+ (see Table 1).
+
+ Table 1 of this document defines possible 'keyword' values for the
+ "cpu-type" field. However, the existing IANA machine registration
+ [cpu-names] is inadequate for two reasons: a) it is really a machine
+ model number, not a CPU type, and b) it doesn't express whether a
+ CPU is 16-bit, 32-bit, or 64-bit which needs to be indicated in the
+ keyword value. Therefore, the "os-type" field will be a new
+ registration with initial values assigned.
+
+ The rest of this section contains the exact information for IANA to
+ add to the IPP Registries according to the procedures defined in RFC
+ 2911 [RFC2911] section 6.
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 20]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ Note to RFC Editors: Replace RFC NNNN below with the RFC number
+ for this document, so that it accurately reflects the content of
+ the information for the IANA Registry.
+
+
+7.1 Attribute Registrations
+
+ The attributes and fields defined in this document will be published
+ by IANA according to the procedures in RFC 2911 [RFC2911] section 6.2
+ with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attributes/
+
+ The registry entry will contain the following information:
+
+ Printer Description Attributes: Ref: Section:
+ client-print-support-files-supported (1setOf octetString(MAX))
+ RFC NNNN 3.1
+
+ For purposes of IANA attribute registration, the following fields of
+ the "client-print-support-files-supported" and the "client-print-
+ support-files-filter" attributes are registered following the
+ procedures for IPP attribute registration:
+ Ref: Section:
+ uri (uri) RFC NNNN 3.1
+ os-type (type2 keyword) RFC NNNN 3.1
+ cpu-type (type2 keyword) RFC NNNN 3.1
+ document-format (mimeMediaType) RFC NNNN 3.1
+ natural-language (naturalLanguage) RFC NNNN 3.1
+ compression (type2 keyword) RFC NNNN 3.1
+ file-type (type2 keyword) RFC NNNN 3.1
+ client-file-name (name(MAX)) RFC NNNN 3.1
+ policy (type2 keyword) RFC NNNN 3.1
+ file-size (integer(0:MAX)) RFC NNNN 3.1
+ file-version (name(MAX)) RFC NNNN 3.1
+ file-date-time (text(25)) RFC NNNN 3.1
+ file-info (text(127)) RFC NNNN 3.1
+ digital-signature (type2 keyword) RFC NNNN 3.1
+
+ uri-scheme (uriScheme) RFC NNNN 3.2
+
+ Operation Attributes: Ref: Section:
+ client-print-support-files-filter (octetString(MAX))RFC NNNN 3.2
+
+
+
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 21]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+7.2 Operation Registrations
+
+ The operations defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.4 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/operations/
+
+ The registry entry will contain the following information:
+
+ Operations: Ref. Section:
+ Get-Client-Print-Support-Files RFC NNNN 3.3
+
+
+8 Internationalization Considerations
+
+ All text representations introduced by this specification adhere to
+ the internationalization-friendly representation supported by IPP.
+ This work is also accommodates the use of Client Print Support Files
+ of different languages.
+
+
+9 Security Considerations
+
+ The IPP Model and Semantics document [RFC2911] discusses high-level
+ security requirements (Client Authentication, Server Authentication
+ and Operation Privacy). Client Authentication is the mechanism by
+ which the client proves its identity to the server in a secure
+ manner. Server Authentication is the mechanism by which the server
+ proves its identity to the client in a secure manner. Operation
+ Privacy is defined as a mechanism for protecting operations from
+ eavesdropping.
+
+ Only operators of a printer SHOULD be allowed to set the "client-
+ print-support-files-supported" attribute and only users of the
+ printer SHOULD be allowed to query that information.
+
+ The IPP extension described in this document introduces the potential
+ for a security threat previously not encountered by IPP. As Client
+ Print Support Files might exist in the form of executable objects (as
+ is the case with printer drivers, for example), additional provisions
+ are needed to prevent the distribution of malicious code through this
+ mechanism. Digital signatures provide the message level security
+ commonly used to help consumers of network resources verify the
+ authenticity and integrity of those resources. Specifically, digital
+ signatures help defend against security threats such as message
+ insertion, message deletion, and message modification, and their
+ combined use into man-in-the-middle attacks.
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 22]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ This document identifies some commonly used signing mechanisms (SMIME
+ [RFC2634], PGP [RFC1991], DSS [dss], and XML Digital Signatures
+ [xmldsig]), though any others MAY be used. Of course, it is assumed
+ that once end-users know the identity of the provider of Client Print
+ Support Files, they can make the correct determination as to whether
+ it is safe to use those files.
+
+ Printers that support the Get-Client-Print-Support-Files operation
+ SHOULD support the downloading of Client Print Support Files that
+ have been digitally signed. Clients that invoke the Get-Client-
+ Print-Support-Files operation MUST make sure that Client Print
+ Support Files that are supposed to be signed (i.e., whose client-
+ print-support-files-supported attribute value includes the "digital-
+ signature" field) are indeed signed via the specified mechanism when
+ downloaded from the printer.
+
+ Furthermore, printers that support the Get-Client-Print-Support-Files
+ operation SHOULD implement TLS to provide application level channel
+ security and enable users to reliably authenticate the source of the
+ Client Print Support Files.
+
+
+10 References
+
+
+ [cpu-names]
+ IANA Registry of CPU Names at ftp://ftp.isi.edu/in-
+ notes/iana/assignments/XXX.
+
+ [dss]
+ U.S. Department of Commerce, "Digital Signature Standard (DDS)",
+ Federal Information Processing Standards Publication 186-1 (FIPS
+ PUB 186-1), December 15, 1998.
+
+ [ipp-url]
+ Herriot, R., McDonald, I., "Internet Printing Protocol (IPP): IPP
+ URL Scheme." <draft-ietf-ipp-url-scheme-02.txt>, February 14,
+ 2001.
+
+ [os-names]
+ IANA Registry of Operating System Names at ftp://ftp.isi.edu/in-
+ notes/iana/assignments/operating-system-names.
+
+ [RFC1991]
+ D. Atkins, W. Stallings, P. Zimmermann, "PGP Message Exchange
+ Formats", RFC 1991, August, 1996.
+
+ [RFC2026]
+ S. Bradner, "The Internet Standards Process -- Revision 3", RFC
+ 2026, October 1996.
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 23]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+ [RFC2396]
+ Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+ [RFC2518]
+ Goland, Y., et al, "HTTP Extensions for Distributed Authoring --
+ WEBDAV", RFC 2518, February 1999.
+
+ [RFC2616]
+ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
+ Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2634]
+ P. Hoffman, "Enhanced Security Services for S/MIME", RFC 2634, June
+ 1999.
+
+ [RFC2910]
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
+
+ [RFC2911]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911,
+ September 2000.
+
+ [xmldsig]
+ D. Eastlake, J. Reagle, D. Solo "XML-Signature Syntax and
+ Processing", <draft-ietf-xmldsig-core-11.txt>, October 31, 2000.
+
+
+11 Author's Addresses
+
+ Hugo Parra
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, UT 84606
+
+ Phone: 801-861-3307
+ Fax: 801-861-4025
+ e-mail: hparra@novell.com
+
+ Ted Tronson
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, UT 84606
+
+ Phone: 801-861-3338
+ Fax: 801-861-4025
+ e-mail: ttronson@novell.com
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 24]
+\f
+
+INTERNET-DRAFT IPP: Printer Installation Extension February 28, 2001
+
+
+
+ Thomas N. Hastings
+ Xerox Corp.
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+
+
+12 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). 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 RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Parra, Tronson, Hastings Expires August 28, 2001 [page 25]
+++ /dev/null
-INTERNET-DRAFT T. Hastings
-<draft-ietf-ipp-job-printer-set-ops-02.txt> R. Herriot
- Xerox Corporation
- Carl Kugler
- H. Lewis
- IBM Corporation
- March 23, 2000
-
- Internet Printing Protocol (IPP):
- Job and Printer Set Operations
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
- Abstract
-
-This document specifies 3 additional OPTIONAL operations for use with
-the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], IPP/1.1
-[ipp-mod, ipp-pro], and future versions. The end user, operator, and
-administrator Set-Job-Attributes and Set-Printer-Attributes operations
-are used to modify IPP Job objects and Printer objects, respectively.
-The third administrator Get-Printer-Supported-Values operation returns
-values that the IPP Printer will accept for setting its "xxx-supported"
-attributes.
-
-Three out-of-band values are defined for use with these operations:
-'delete-attribute', 'admin-define', and 'not-settable', along with a
-'client-error-attributes-not-settable' status code.
-
-Two operation attributes: "printer-message-from-operator" (text) and
-"job-message-from-operator" (text) are defined to set the corresponding
-IPP/1.1 Printer and Job Description attributes with the same names.
-
-Nine Printer Description attributes are defined:
- printer-settable-attributes-supported (1setOf type2 keyword)
- job-settable-attributes-supported (1setOf type2 keyword)
- document-format-varying-attributes (1setOf type2 keyword)
- printer-message-time (integer(MIN:MAX))
- printer-message-date-time (dateTime)
-
-Hastings, Herriot, Kugler, Lewis [Page 1]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- printer-xri-supported (1setOf collection)
- xri-uri-scheme-supported (1setOf uriScheme)
- xri-authentication-supported (1setOf type2 keyword)
- xri-security-supported (1setOf type2 keyword)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 2]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting over HTTP a message
-body whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 3]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- Table of Contents
-
-
-1 Introduction.....................................................7
-
-2 Terminology......................................................7
-2.1 Conformance Terminology.......................................7
-2.2 Other terminology.............................................8
-
-3 Requirements and Use Cases.......................................8
-
-4 Definition of the Set operations.................................9
-4.1 Set-Printer-Attributes Operation..............................9
- 4.1.1 Settable and READ-ONLY Printer Description attributes....11
- 4.1.2 Set-Printer-Attributes Request...........................12
- 4.1.3 Set-Printer-Attributes Response..........................13
-4.2 Set-Job-Attributes Operation.................................15
- 4.2.1 Settable and READ-ONLY Job Description attributes........17
- 4.2.2 Set-Job-Attributes Request...............................17
- 4.2.3 Set-Job-Attributes Response..............................18
-4.3 Get-Printer-Supported-Values Operation.......................19
- 4.3.1 Definition of the usage of the 'admin-define' out-of-band
- attribute value..................................................20
-
-5 New Operation attributes........................................21
-5.1 "printer-message-from-operator" (text(127))..................22
-5.2 "job-message-from-operator" (text(127))......................23
-
-6 New Printer Description Attributes..............................24
-6.1 printer-settable-attributes-supported (1setOf type2 keyword).24
-6.2 job-settable-attributes-supported (1setOf type2 keyword).....24
-6.3 document-format-varying-attributes (1setOf type2 keyword)....24
-6.4 printer-message-time (integer(MIN:MAX))......................25
-6.5 printer-message-date-time (dateTime).........................25
-6.6 printer-xri-supported (1setOf collection)....................25
-6.7 xri-uri-scheme-supported (1setOf uriScheme)..................27
-6.8 xri-authentication-supported (1setOf type2 keyword)..........28
-6.9 xri-security-supported (1setOf type2 keyword)................28
-
-7 Additional status codes.........................................28
-7.1 'client-error-attributes-not-settable' (0x0413)..............28
-
-8 Additional out-of-band values...................................29
-8.1 'not-settable' out-of-band value.............................29
- 8.1.1 Encoding of the 'not-settable' out-of-band attribute value29
-8.2 'delete-attribute' out-of-band value.........................29
- 8.2.1 Encoding of the 'delete-attribute' out-of-band value.....30
-8.3 'admin-define' out-of-band attribute value...................30
- 8.3.1 Encoding of the 'admin-define' out-of-band attribute value31
-
-9 Conformance Requirements........................................31
-
-10 IANA Considerations.............................................32
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 4]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-11 Internationalization Considerations.............................33
-
-12 Security Considerations.........................................33
-
-13 Author's Addresses..............................................33
-
-14 References......................................................34
-
-15 Change History..................................................35
-15.1 Changes to the March 21, 2000 version to make the March 23, 2000
-version 35
-15.2 Changes to the March 8, 2000 version to make the March 21, 2000
-version 36
-15.3 Changes to the March 1, 2000 version to make the March 8, 2000
-version 37
-15.4 Changes to the January 30, 2000 version to make the March 1, 2000
-version 37
-15.5 Changes to the January 20, 2000 version to make the January 30,
-2000 version39
-15.6 Changes to the January 4, 2000 version to make the January 20,
-2000 version39
-15.7 Changes to the December 8, 1999 version to make the January 4,
-2000 version41
-
-16 Appendix A: Allowed Values for Set-Printer-Attributes and Set-Job-
-Attributes requests................................................42
-
-17 Appendix B: Attributes returned from Get-Printer-Supported-Values47
-
-18 Appendix C: Full Copyright Statement............................50
-
-
- Table of Tables
-
-Table 1 - Operation-Id assignments....................................9
-Table 2 - Job State Transition Table for the Set-Job-Attributes
- operation........................................................16
-Table 3 - Member attributes of "printer-xri-supported" (1setOf
- collection)......................................................26
-Table 4 - Validation rules for 'Any of "xxx-supported" '.............42
-Table 5 - Validation rules for 'From Get-Printer-Supported-Values'...43
-Table 6 - Values allowed for Job Template Attributes in the Set-Job-
- Attributes Operation.............................................43
-Table 7 - Values allowed for Job Description Attributes in the Set-Job-
- Attributes Operation.............................................44
-Table 8 - Values allowed for Printer Job Template Attributes in the Set-
- Printer-Attributes Operation.....................................45
-Table 9 - Values allowed for Printer Description Attributes in the Set-
- Printer-Attributes Operation.....................................45
-Table 10 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values.................................................48
-Table 11 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values.................................................48
-Table 12 - Printer Description Attributes returned from Get-Printer-
- Supported-Values.................................................48
-
-Hastings, Herriot, Kugler, Lewis [Page 5]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Table 13 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values.................................................48
-Table 14 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values.................................................49
-Table 15 - Printer Description Attributes returned from Get-Printer-
- Supported-Values.................................................49
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 6]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-1 Introduction
-
-
-The Internet Printing Protocol (IPP) is an application level protocol
-that can be used for distributed printing using Internet tools and
-technologies. IPP version 1.1 [ipp-mod, ipp-pro] focuses on end user
-functionality with a few administrative operations included. This
-document defines additional OPTIONAL end user, operator, and
-administrator Set-Job-Attributes and Set-Printer-Attributes operations
-used to modify IPP Job objects and Printer objects, respectively. It
-also defines a third administrator Get-Printer-Supported-Values
-operation that returns values that the IPP Printer will accept for
-setting its "xxx-supported" attributes. The Get-Printer-Supported-
-Values operation MUST be supported, if the implementation supports
-setting any "xxx-supported" Printer attributes using the Set-Printer-
-Attributes operation.
-
-Three out-of-band values are defined for use with these three
-operations: 'delete-attribute' for deleting Job attributes with the
-Set-Job-Attributes request, 'not-settable' for use in either the Set-
-Job-Attributes or Set-Printer-Attributes responses, and 'admin-define'
-for use in the Get-Printer-Supported-Values response.
-
-Two operation attributes: "printer-message-from-operator" (text) and
-"job-message-from-operator" (text) are defined to set the corresponding
-IPP/1.1 Printer and Job Description attributes with the same names.
-These operation attributes may be used with any operation that affect
-the Printer or Job object for which an operation might want to indicate
-a message. For the Set-Job-Attributes and Set-Printer-Attributes
-operations, the client MUST explicitly set them, rather than using these
-operation attributes.
-
-A Printer implementation can make the value of some attributes dependent
-on the document-format, e.g. "resolution-supported".
-
-This document is an extension to IPP/1.0 [RFC2565, RFC2566] and IPP/1.1
-[ipp-mod, ipp-pro], and future versions.
-
-
-
-2 Terminology
-
-This section defines terminology used throughout this document.
-
-2.1 Conformance Terminology
-
-
-Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
-MAY, NEED NOT, and OPTIONAL, have special meaning relating to
-conformance. These terms are defined in [ipp-mod] section 12.1 on
-conformance terminology, most of which is taken from RFC 2119 [RFC2119].
-
-The following specialization of these terms apply to this document:
-
- REQUIRED: if an implementation supports the extensions described in
- this document, it MUST support a REQUIRED feature.
-
-Hastings, Herriot, Kugler, Lewis [Page 7]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- OPTIONAL: if an implementation supports the extensions described in
- this document, it MAY support an OPTIONAL feature.
-
-2.2 Other terminology
-
-
-This document uses terms such as Job object (or Job), IPP Printer object
-(or Printer), "operation", "request", response", "attributes",
-"keywords", and "support". These terms have special meaning and are
-defined in the model terminology [ipp-mod] section 12.2. The following
-additional terms are introduced in this document:
-
- READ-ONLY: used in an attribute definition document to indicate that
- the attribute MUST NOT be settable using an IPP protocol Set
- operation. In other words, the attribute is not settable by
- definition.
- not-settable: an implementation does not support setting an
- attribute (whether or not the attribute's definition is READ-ONLY).
-
-
-3 Requirements and Use Cases
-
-
-The following requirements and usage are intended to be met by the
-specification in this document.
-
-1.The end-user and the operator need a way to modify a Job that is in
- the 'pending' or 'pending-held' state.
-
- Usage: The end-user discovers that he/she forgot to include a print
- instruction, such as "finishings" = 'staple' after submitting a job.
- Rather than canceling the job and resubmitting it to the same IPP
- Printer, the end-user is able to modify the job on the IPP Printer.
-
- The operator needs to modify a job because it is requesting a
- particular kind of media for which there is no more, but the policy
- is to print the job on a comparable medium.
-
-2.The system administrator needs a way to re-configure or change the
- policy of the IPP Printer remotely.
-
- Usage: The system administrator is adding additional named media to
- the supported media list (setting 'name' values to the "media-
- supported" Printer attribute).
-
- The system administrator is reducing the capability of the IPP
- Printer by removing one of the operations from the supported
- operations list, such as Cancel-Job, because the policy is to run the
- IPP Printer like a public facsimile machine. After having removed
- Cancel-Job from the list of supported operations, an administrative
- client needs to be able to display to an administrator that the
- implementation is capable of being reconfigured to support Cancel-Job
- once again.
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 8]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- The system administrator is remotely configuring the IPP Printer
- after installing it, and so is replacing the Printer Description
- attributes that have the out-of-band 'no-value' value (see [ipp-mod]
- section 4.1) with the proper values.
-
- The operator is changing the media loaded in the input tray and so is
- replacing the "media-ready" Job Template Printer attribute value with
- the proper values
-
-
-
-4 Definition of the Set operations
-
-
-The Set-Printer-Attributes operation (as are all Printer operations) are
-directed at Printer objects. A client MUST always supply the "printer-
-uri" operation attribute in order to identify the correct target of the
-operation. These descriptions assume all of the common semantics of
-IPP/1.1 Model and Semantics document [ipp-mod] section 3.1.
-
-The Set-Job-Attributes operation (as are all Job operations) are
-directed at Job objects. A client MUST always supply some means of
-identifying the Job object in order to identify the correct target of
-the operation. That job identification MAY either be a single Job URI
-or a combination of a Printer URI with a Job ID as defined in [ipp-mod].
-The IPP object implementation MUST support both forms of identification
-for every job. If possible, a client SHOULD use the Printer URI with a
-Job ID rather than a Job URI, since the 32-bit "job-id" is more readily
-translated to and from other print protocols that MAY be serving as
-gateways into or out of the IPP implementation.
-
-The Set Printer operations are summarized in Table 1:
-
- Table 1 - Operation-Id assignments
-
- Operation Name Operation Brief description
- -Id
- Set-Printer- 0x0013 Sets attribute values of the target
- Attributes Printer object
- Set-Job-Attributes 0x0014 Sets attribute values of the target
- Job object
- Get-Printer- 0x0015 Gets values that are valid for
- Supported-Values setting "xxx-supported" attributes
- using the Set-Printer-Attributes
- operation
-
-4.1 Set-Printer-Attributes Operation
-
-
-This OPTIONAL operation allows a client to set the values of the
-attributes of a Printer object. In the request, the client supplies
-the set of Printer keyword attribute names and values that are to be
-set. In the response, the Printer object returns success or rejects the
-entire request with indications of which attribute or attributes could
-not be set.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 9]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-The Printer object validates the client-supplied attributes in the Set-
-Printer-Attributes request. For an attribute to validate it MUST meet
-all of the following rules:
-
- 1. The number of attributes supplied by the client MUST NOT exceed the
- maximum number that the Printer supports in a Set-Printer-
- Attributes request. A Printer MUST accept at least one attribute,
- but SHOULD accept a reasonable number in a single Set-Printer-
- Attributes request.
-
- Note: There is no way for the client to determine the maximum
- number of attributes that the Printer supports in a Set-Printer-
- Attributes request, except to try a reasonable number.
-
- 2. The Printer MUST support the attribute.
-
- 3. The attribute MUST NOT be READ-ONLY, i.e., the definition of the
- attribute MUST NOT indicate that the attribute is READ-ONLY (see
- Appendix A for an indication of which IPP/1.1 attributes are READ-
- ONLY).
-
- 4. The attribute MUST be settable in this implementation.
-
- 5. The Printer MUST support the value according to the rules defined
- in Appendix A, i.e., each value of each supplied "xxx" attribute
- MUST be validated against a value of a corresponding "xxx-
- supported" Printer attribute. One of those rules permits an
- administrator to set arbitrary 'name' values to those "xxx-
- supported" Printer attributes that include the 'name' attribute
- syntax if the implementation supports the 'admin-define' out-of-
- band value for that "xxx-supported" attribute (see section 0 and
- 8.3).
-
- 6. The attribute's values MUST NOT conflict with the values of other
- Printer attributes, including ones being set in this same
- operation.
-
-If any of the supplied attributes does not validate, the Printer object
-MUST reject the entire operation; the Printer object MUST NOT partially
-set some of the supplied attributes. In other words, after the
-operation, all the supplied attributes MUST be set or none of them MUST
-be set, thus making the Set-Printer-Attributes an atomic operation.
-
-The Printer MUST accept this operation when its READ-ONLY "printer-
-state" attribute (see ipp-mod] section 4.4.11) is 'idle' or 'stopped',
-and SHOULD accept it when the value is 'processing'. The Printer MUST
-accept this operation for any of the values of the Printer object's
-READ-ONLY "printer-state-reasons" and "printer-is-accepting-jobs"
-attributes, unless explicitly defined otherwise in the definition of
-these attributes' values.
-
-This operation MUST NOT change the value of attributes not specified in
-the operation unless the definition of the attribute explicitly
-specifies such side-effects. For example, this document explicitly
-
-Hastings, Herriot, Kugler, Lewis [Page 10]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-specifies that when this operation sets "printer-message-from-operator",
-the Printer also MUST set the READ-ONLY "printer-message-time" and READ-
-ONLY "printer-message-date-time" attributes to the time of the operation
-as a side effect . In particular, if this operation changes an "xxx-
-default" attribute, the new value MUST be in the "xxx-supported"
-attribute or the request MUST contain a new value for "xxx-supported"
-which contains the new value for the "xxx-default". Otherwise, the
-Printer MUST reject the operation. In general, Printer attribute
-definitions that are settable will not define side-effects on other
-attributes that are settable, only side effects on READ-ONLY attributes,
-if any.
-
-
-4.1.1Settable and READ-ONLY Printer Description attributes
-
-If the Printer supports the Set-Printer-Attributes operation, then it
-SHOULD support setting of:
-
- all Job Template Default ("xxx-default") attributes
- all Job Template Supported ("xxx-supported") attributes
- all Job Template Ready ("xxx-ready") attributes
-
-that the implementation supports (see [ipp-mod] section 4.2 and
-extensions).
-
-Some Printer Description attributes (see [ipp-mod] section 4.4) MUST NOT
-be settable, i.e., they are defined to be READ-ONLY. An attribute
-marked as "READ-ONLY" in the Printer Description attribute table in
-Appendix A is such an attribute. The Printer attributes that are not
-marked as "READ-ONLY" MAY be settable using the Set-Printer-Attributes
-operation, depending on implementation.
-
-Note: From now on, all extensions that define new object attributes
-will indicate whether or not the attributes are READ-ONLY, by including
-the "READ-ONLY" adjective in their descriptions and/or explicitly
-stating whether they MAY be settable.
-
-The current values of each "xxx-supported" Printer attribute MUST
-reflect the current policy for support of the corresponding "xxx"
-attribute. If an "xxx-supported" Printer attribute is settable in an
-implementation, then its value(s) MUST affect the behavior of the
-implementation. If an "xxx-supported" Printer attribute is defined to
-be READ-ONLY or is not-settable in an implementation, then its values
-MUST NOT be settable using the Set-Printer-Attributes operation.
-Consider the following example:
-
- For example, if the "operations-supported" Printer Description
- attribute (see [ipp-mod] section 4.4.15) is settable in a
- particular implementation, then changing its value with a Set-
- Printer-Attributes operation MUST affect the operations that the
- implementation accepts or rejects. Such an implementation will
- need to be able to reject values for operations that it contains no
- code support for (see section 4.3). If the "operations-supported"
- Printer Description attribute is not settable in a particular
- implementation, then that implementation MUST reject an attempt to
-
-
-Hastings, Herriot, Kugler, Lewis [Page 11]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- set it with a Set-Printer-Attributes operation, return the 'client-
- error-attributes-not-settable' status code (see section 7.1), and
- return the "operations-supported" attribute with the out-of-band
- 'not-settable' value in the Unsupported Attributes Group.
-
- As another example, consider an implementation in which the "media-
- default" and "media-supported" are settable. If a client supplies
- a Set-Printer-Attributes request that contains the "media-default"
- attribute with a value that is not a member of the Printer's
- "media-supported" attribute, the Printer MUST reject the request
- and return the "client-error-conflicting-attributes" status code
- with the "media-default" and "media-supported" attributes and their
- values (see [ipp-mod] section 3.1.7).
-
- As a third example, if a client supplies a Set-Printer-Attributes
- request that contains both the "media-default" and the "media-
- supported" attributes, but includes a value in the "media-default"
- that is not a member of the supplied "media-supported" attribute,
- the Printer MUST reject the request and return the "client-error-
- conflicting-attributes" status code with the "media-default" and
- "media-supported" attributes and their values (see [ipp-mod]
- section 3.1.7).
-
-Access Rights: The authenticated user (see [ipp-mod] section 8.3)
-performing this operation must be an operator or administrator of the
-Printer object (see [ipp-mod] Sections 1 and 8.5). Most Printer
-attributes will require administrator access rights to set, such as
-"xxx-supported", while some will require operator access rights only,
-such as "media-ready" and "printer-message-from-operator". Which
-attributes require which access rights depends on implementation and MAY
-depend on site policy.
-
-
-4.1.2Set-Printer-Attributes Request
-
-The following sets of attributes are part of the Set-Printer-Attributes
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.1.
-
- Target:
- The "printer-uri" (uri) operation attribute which is the target for
- this operation as described in [ipp-mod] section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in [ipp-mod] section 8.3.
-
- "document-format" (mimeMediaType):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. This attribute is useful for a client
-
-Hastings, Herriot, Kugler, Lewis [Page 12]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- to select the document-format to which the attribute modification
- should be applied. A Printer implementation MAY allow some
- attributes to have different values for each document format that
- it supports. See [ipp-mod] section 3.2.5.1 "Get-Printer-Attributes
- Request".
-
- If the client includes this attribute, the Printer MUST change the
- supplied attributes for the document format specified by this
- attribute. If a supplied attribute is a member of the "document-
- format-varying-attributes" (i.e., the attribute varies by document
- format, see section 6.3), the Printer MUST change the supplied
- attribute for the document format specified by this attribute, but
- not for other document formats. If a supplied attribute isn't a
- member of the "document-format-varying-attributes" (i.e. it doesn't
- vary by document format), the Printer MUST change the supplied
- attribute for all document formats.
-
- If the client omits this attribute, the Printer MUST change the
- supplied attributes for all document formats whether or not they
- vary by document-format.
-
- If the client supplies a value for the "document-format" Operation
- attribute that is either 'application/octet-stream' or not
- supported by the Printer, i.e., is not among the values of the
- Printer object's "document-format-supported" attribute, the Printer
- object MUST reject the operation and return the 'client-error-
- document-format-not-supported' status code. Note: the document-
- format 'application/octet-stream' is the union of several document-
- formats (see [ipp-mod] section 3.2.5.1, Get-Printer-Attributes) and
- is not a true document-format.
-
-
-Group 2: Printer Attributes
-
- The client MUST supply a set of Printer attributes with one or more
- values (including explicitly allowed out-of-band values) as defined
- in [ipp-mod] section 4.2 Job Template Attributes ("xxx-default",
- "xxx-supported", and "xxx-ready" attributes), section 4.4 Printer
- Description Attributes, and any attribute extensions supported by
- the Printer. The value(s) of each Printer attribute supplied in
- Group 2 replaces the value(s) of the corresponding Printer
- attribute on the target Printer object. For attributes that can
- have multiple values (1setOf), all values supplied by the client
- replace all values of the corresponding Printer object attribute.
- If a Printer object attribute had not been configured yet and so
- had the 'no-value' out-of-band value (see [ipp-mod] section 4.1),
- the supplied value(s) replace the 'no-value' value.
-
-
-4.1.3Set-Printer-Attributes Response
-
-The Printer object returns the following sets of attributes as part of
-the Get-Printer-Attributes Response:
-
-Group 1: Operation Attributes
-
-Hastings, Herriot, Kugler, Lewis [Page 13]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in [ipp-mod] sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See [ipp-mod] section 3.1.7 for details on returning Unsupported
- Attributes.
-
- If some of the attributes in the operation fail to validate, the
- Printer MUST reject the operation, MUST NOT change any Printer
- attributes, and MUST return the indicated status code below. In
- this group, the Printer MUST also return all attributes that fail
- to validate. The following are the reasons that an attribute fails
- to validate and the value returned for the attribute, along with
- the indicated status code and order of detection:
-
- 1. The number of attributes supplied by the client exceeds the
- maximum number that the Printer supports in a Set-Printer-
- Attributes request: return the 'client-error-request-entity-
- too-large' (see [ipp-mod] section 13.1.4.9).
-
- 2. The Printer doesn't support the attribute: return the
- attribute with the "out-of-band" value 'unsupported' (see
- [ipp-mod] section 3.1.7 and [ipp-pro]) and the 'client-error-
- attributes-or-values-not-supported (see [ipp-mod] section
- 13.1.4.12).
-
- 3. The attribute is either READ-ONLY (in its definition) or is
- not-settable in this implementation: return the attribute
- with the "out-of-band" value 'not-settable' (see section 8.1)
- and the 'client-error-attributes-not-settable' status code
- (see section 7.1).
-
- 4. The Printer doesn't support the value: if the attribute in
- the operation has a single value return it. If the attribute
- in the operation is multi-valued, return only those values in
- a 1setOf that are not supported. Return the 'client-error-
- attributes-or-values-not-supported' status code (see [ipp-mod]
- section 13.1.4.12).
-
- 5. The values of some of the supplied attributes conflict with
- one another and/or other Printer attribute values not being
- set: if the conflicting attribute in the operation has a
- single value return the attribute and the value. If the
- attribute in the operation is multi-valued, return only the
- attribute and those values in a 1setOf that are conflicting
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 14]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- with other attributes. Return the 'client-error-conflicting-
- attributes' status code (see [ipp-mod] section 13.1.4.15).
-
-
-4.2 Set-Job-Attributes Operation
-
-
-This OPTIONAL operation allows a client to set the values of the
-attributes of a Job object. In the request, the client supplies the set
-of Job keyword attribute names and values that are to be set. In the
-response, the IPP object returns success or rejects the entire request
-with indications of which attribute or attributes could not be set.
-
-This operation is almost identical to the Set-Printer-Attributes
-operation and follows the same rules for validation (see section 4.1).
-The only differences are that the Set-Job-Attributes operation is
-directed at a Job object rather than a Printer object, there is no
-"document-format" operation attribute used when setting a Job object,
-the operation can add an attribute to the (Job) object, the 'delete-
-attributes' out-of-band value is permitted to remove an attribute, and
-the validation is the same as the Job Creation operations (Print-Job,
-Print-URI, and Create-Job), i.e., depends on the "xxx-supported" Printer
-Description attributes (see [ipp-mod] section 3.1). Using the Set-
-Printer-Attributes operation, the administrator can set arbitrary 'name'
-values to those "xxx-supported" Printer attributes that include the
-'name' attribute syntax if the implementation supports the 'admin-
-define' out-of-band value for that "xxx-supported" attribute (see
-section 0 and 8.3). However, the Set-Job-Attributes cannot be used to
-add unsupported names to the Job object.
-
-If a client supplies a job attribute in a Set-Job-Attributes request
-that the Printer supports, and the job was originally submitted without
-supplying that attribute, the Printer adds the attribute to the Job
-object.
-
-If the client supplies a job attribute with the "out-of-band" value
-'delete-attribute' (see section 8.2), then the Printer MUST remove the
-attribute and all of its values from the Job object, if present. The
-semantic effect of the client supplying the 'delete-attribute' value in
-a Set-Job-Attributes operation MUST be the same as if the attribute had
-not been supplied with the Job object in the Job Creation operation,
-i.e., the Printer applies its default attribute or behavior with lower
-precedence that the PDL (see the beginning of [ipp-mod] section 4.2 and
-[ipp-mod] 3.2.1.1). Any subsequent query of the Job object using Get-
-Job-Attributes or Get-Jobs MUST NOT return any attribute that has been
-deleted using the 'delete-attribute' out-of-band value. However, a
-client can re-establish such a deleted Job attribute with any supported
-value(s) using a subsequent Set-Job-Attributes operation.
-
-If the client supplies an attribute in a Set-Job-Attributes request with
-the 'delete-attribute' value and that attribute is not present on the
-Job object, the Printer ignores that supplied attribute in the request,
-does not return the attribute in the Unsupported Attributes group, and
-returns the 'successful-ok' status code, if there are no other problems
-with the request.
-
-Hastings, Herriot, Kugler, Lewis [Page 15]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-The validation of the Set-Job-Attributes request is performed by the
-Printer as if the job had been submitted originally with the new
-attribute values (and the deleted attributes removed) and with "ipp-
-attribute-fidelity" set to 'true', i.e., all modified attributes Job
-attributes and values MUST be supported in combination with the Job
-attributes not modified. If such a Job Creation operation would have
-been accepted, then the Set-Job-Attributes MUST be accepted. If such a
-Job Creation operation would have been rejected, then the Set-Job-
-Attributes MUST be rejected and the Job MUST be unchanged. In addition,
-if any of the supplied attributes are not supported, are not settable,
-or the values are not supported, the Printer object MUST reject the
-entire operation; the Printer object MUST NOT partially set some of the
-supplied attributes. In other words, after the operation, all the
-supplied attributes MUST be set or none of them MUST be set, thus making
-the Set-Job-Attributes an atomic operation.
-
-The IPP object MUST accept or reject this operations when the Job's
-READ-ONLY "job-state" attribute has the values shown in Table 2. The
-job's current state MUST affect whether the IPP object accepts or
-rejects the request. For example, in the case where the operation
-creates a request for unavailable resources, the Job transitions to a
-new state. Table 2 shows the allowed behaviors in each job state and
-the transitions.
-
- Table 2 - Job State Transition Table for the Set-Job-Attributes
- operation
-
- Current "job- New "job- IPP object's response status
- state" state" code and action:
-
- 'pending' 'pending' 'successful-ok'
- 'pending' 'pending- 'successful-ok' - needed
- held' resources are not ready
- 'pending-held' 'pending- 'successful-ok'
- held'
- 'pending-held' 'pending' 'successful-ok' - needed
- resources are ready
- 'processing' 'processing' 'successful-ok' or 'client-
- error-not-possible' depending on
- implementation, including the
- attributes being set, whether
- the job has started marking
- media, etc.
- 'processing- 'processing- 'successful-ok' or 'client-
- stopped' stopped' error-not-possible' depending on
- implementation, including the
- attributes being set, whether
- the job has started marking
- media, etc.
- 'completed' 'completed' 'client-error-not-possible'
- 'canceled' 'canceled' 'client-error-not-possible'
- 'aborted' 'aborted' 'client-error-not-possible'
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 16]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-This operation MUST NOT change the value of attributes not specified in
-the operation unless the definition of the attribute explicitly
-specifies such side-effects. In general, Job attribute definitions that
-are settable will not define side-effects on other attributes that are
-settable, only side effects on READ-ONLY attributes, if any.
-
-
-4.2.1Settable and READ-ONLY Job Description attributes
-
-If the Printer supports the "job-message-from-operator" Job Description
-attribute (see [ipp-mod] section 4.3.16) and the client explicitly
-supplies a new value for the "job-message-from-operator" in the Set-Job-
-Attributes request, then the Printer MUST set the "job-message-from-
-operator" Job attribute to this new value.
-
-If the Printer supports the Set-Job-Attributes operation, then it SHOULD
-support setting of:
-
- all Job Template job ("xxx") attributes
-
-that the implementation supports (see [ipp-mod] section 4.2 and
-extensions).
-
-Some Job Description attributes (see [ipp-mod] section 4.3) MUST NOT be
-settable, i.e., they are defined to be READ-ONLY. An attribute marked
-as "READ-ONLY" in the Job Description attribute table in Appendix A is
-such an attribute. The Job attributes not marked as "READ-ONLY" MAY be
-settable using the Set-Job-Attributes operation, depending on
-implementation.
-
-Note: From now on, all extensions that define new object attributes
-will indicate whether or not the attributes are READ-ONLY, by including
-the "READ-ONLY" adjective in their descriptions and/or explicitly
-stating whether they MAY be settable.
-
-Access Rights: The authenticated user (see [ipp-mod] section 8.3)
-performing this operation must either be the job owner (as determined in
-the Job Creation operation) or an operator or administrator of the
-Printer object (see [ipp-mod] Sections 1 and 8.5).
-
-
-4.2.2Set-Job-Attributes Request
-
-The following sets of attributes are part of the Set-Job-Attributes
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.1.
-
- Target:
- Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))
- or (2) the "job-uri" (uri) operation attribute(s) which define the
- target for this operation as described in [ipp-mod] section 3.1.5.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 17]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in [ipp-mod] section 8.3.
-
-
-Group 2: Job Attributes
-
- The client MUST supply a set of Job attributes with one or more
- values (including explicitly allowed out-of-band values) as defined
- in [ipp-mod] section 4.2 Job Template Attributes ("xxx"
- attributes), section 4.3 Job Description Attributes, and any
- attribute extensions supported by the Printer. The value(s) of
- each Job attribute supplied in Group 2 replaces the value(s) of the
- corresponding Job attribute on the target Job object. For
- attributes that can have multiple values (1setOf), all values
- supplied by the client replace all values of the corresponding Job
- object attribute.
-
- If the client supplies an "xxx" attribute with the 'delete-
- attribute' out-of-band value (see section 8.2), the Printer MUST
- remove the "xxx" attribute from the Job object, if present.
-
-
-4.2.3Set-Job-Attributes Response
-
-The IPP object returns the following sets of attributes as part of the
-Set-Job-Attributes Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in [ipp-mod] sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See [ipp-mod] section 3.1.7 for details on returning Unsupported
- Attributes.
-
- If some of the attributes in the operation fail to validate, the
- Printer MUST reject the operation, MUST NOT change any Job
- attributes, and MUST return the indicated status code below. In
- this group, the Printer MUST also return all attributes that fail
- to validate. The following are the reasons that an attribute fails
- to validate and the value returned for the attribute, along with
- the indicated status code and order of detection:
-
- 1. The number of attributes supplied by the client exceeds the
- maximum number that the Printer supports in a Set-Printer-
-
-Hastings, Herriot, Kugler, Lewis [Page 18]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- Attributes request: return the 'client-error-request-entity-
- too-large' (see [ipp-mod] section 13.1.4.9).
-
- 2. The Printer doesn't support the attribute: return the
- attribute with the 'unsupported' out-of-band attribute value
- (see [ipp-mod] section 3.1.7 and [ipp-pro]) and the 'client-
- error-attributes-or-values-not-supported (see [ipp-mod]
- section 13.1.4.12).
-
- 3. The attribute is READ-ONLY (in its definition) or is not-
- settable in this implementation: return the attribute with
- the 'not-settable' out-of-band attribute value (see section
- 8.1) and the 'client-error-attributes-not-settable' status
- code (see section 7.1).
-
- 4. The Printer doesn't support the value: if the attribute in
- the operation has a single value return it. If the attribute
- in the operation is multi-valued, return only those values in
- a 1setOf that are not supported. Return the 'client-error-
- attributes-or-values-not-supported' status code (see [ipp-mod]
- section 13.1.4.12).
-
- 5. The values of some of the supplied attributes conflict with
- one another and/or other Job attribute values not being set:
- if the conflicting attribute in the operation has a single
- value return the attribute and the value. If the attribute in
- the operation is multi-valued, return only the attribute and
- those values in a 1setOf that are conflicting with other
- attributes. Return the 'client-error-conflicting-attributes'
- status code (see [ipp-mod] section 13.1.4.15).
-
-
-4.3 Get-Printer-Supported-Values Operation
-
-
-This OPTIONAL operation allows a client to request the values that the
-Printer allows in the Set-Printer-Attributes operation for "xxx-
-supported" attributes. If the Printer supports the Set-Printer-
-Attributes operation AND some of its "xxx-supported" Printer attributes
-are settable, then the Printer MUST also support this operation.
-
-The Printer MUST return in the Get-Printer-Supported-Values response
-those, and only those, "xxx-supported" Printer attributes that it
-supports setting with the Set-Printer-Attributes operation.
-Furthermore, if a client requests the value of an attribute that is not
-settable or is not supported (as in the Get-Printer-Attributes
-response), the Unsupported Attributes Group of the response NEED NOT
-contain the "requested-attributes" operation attribute with any such
-requested (attribute keyword) values.
-
-This operation has identical request/response attributes to the Get-
-Printer-Attributes operation in IPP/1.1 [ipp-mod]. The operation also
-behaves identically to the Get-Printer-Attributes operation in IPP/1.1
-[ipp-mod] with the following exceptions:
-
-
-Hastings, Herriot, Kugler, Lewis [Page 19]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- 1. The Get-Printer-Supported-Values operation supports only "xxx-
- supported" attributes.
-
- 2. The Get-Printer-Attributes operation returns the few "xxx-
- supported" attributes that are defined to be single valued, such as
- "page-ranges-supported" (boolean) or "pdl-override-supported"
- (type2 keyword), as single values, while Get-Printer-Supported-
- Values returns the possible values that can be set as a 1setOf of
- the same attribute syntax type (See Appendix B: Attributes returned
- from Get-Printer-Supported-Values).
-
- 3. The Get-Printer-Attributes operation returns the current values of
- requested attributes while the Get-Printer-Supported-Values
- operation returns the values that are inherently supported by the
- implementation code, i.e., the values that an administrative client
- can set in a Set-Printer-Attributes request.
-
- 4. The Get-Printer-Attributes operation returns the current values of
- requested "xxx-supported" attributes that the Printer is configured
- to accept in Job Creation operations, including additional values
- defined by the administrator, while the Get-Printer-Supported-
- Values operation returns only the values of "xxx-supported"
- attributes that are inherently supported by the implementation and
- does not return any additional values defined by the administrator
- where the implementation supports the 'admin-define' out-of-band
- value.
-
- 5. The Get-Printer-Attributes never returns the 'admin-define' out-of-
- band attribute value, while the Get-Printer-Supported-Attributes
- operation does, if the implementation allows the administrator to
- define name values by setting that "xxx-supported" attribute with
- any 'name' value(s).
-
- 6. The Get-Printer-Attributes operation only requires end-user access
- rights, while the Get-Printer-Supported-Values requires
- administrator access rights.
-
-Access Rights: The authenticated user (see [ipp-mod] section 8.3)
-performing this operation must be an administrator of the Printer object
-(see [ipp-mod] Sections 1 and 8.5).
-
-
-4.3.1Definition of the usage of the 'admin-define' out-of-band attribute
- value
-
-If the Set-Printer-Attributes operation allows the System Administrator
-to define arbitrary 'name' values for an "xxx-supported" attribute, then
-the Get-Printer-Supported-Values operation MUST return the 'admin-
-define' out-of-band attribute value (see section 8.3) as one of the
-values of the "xxx-supported" attribute. In other words, the 'admin-
-define' out-of-band attribute value indicates that the Printer
-implementation supports clients setting arbitrary 'name' attribute
-syntax values for that "xxx-supported" attribute using the Set-Printer-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 20]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Attributes operation as long as the attribute is defined with the 'name'
-attribute syntax.
-
-For example, if the Get-Printer-Supported-Values operation returns
-several keywords as the value of the "media-supported" attribute, then
-the Set-Printer-Attributes operation MUST accept any of these keywords
-as values for the "media-supported" attribute. If the Get-Printer-
-Supported-Values operation returns an 'admin-define' out-of-band
-attribute value as one of the values of the "media-supported" attribute,
-then the Set-Printer-Attributes operation MUST accept any value whose
-attribute syntax is 'name' as a value for the "media-supported"
-attribute (provided that the user is properly authenticated to use the
-Set-Printer-Attributes operation, e.g., has administrative access
-rights).
-
-The Get-Printer-Supported-Values MAY return the 'admin-define' out-of-
-band attribute value for any IPP/1.1 or extension Job Template attribute
-if the implementation supports allowing the System Administrator to add
-values to the "xxx-supported" attribute using the Set-Printer-Attributes
-operation. In this case, the Printer MUST accept any 'name' value of
-the correct attribute syntax in a Set-Printer-Attributes operation that
-is setting that attribute. For "xxx-supported" attributes that are
-defined with a choice of attribute syntaxes, such as 'keyword | name',
-it is the 'name' attribute syntax that the System Administrator can use
-to add new values, not the 'keyword' attribute syntax. For IPP/1.1 this
-requirement includes the following Job Template attributes:
-
- media-supported
- job-hold-until-supported
- job-sheets-supported
-
-Implementations that support additional Job Template attributes that
-include the 'name' attribute syntax, MAY use the 'admin-define' out-of-
-band value with them.
-
-If the 'admin-define' out-of-band attribute value is not one of the
-values of an "xxx-supported" attribute returned in a Get-Printer-
-Supported-Values response, then the Printer MUST NOT allow the Set-
-Printer-Attributes operation for that attribute to contain a value that
-is not one of the explicit 'keyword' or 'name' values returned in a Get-
-Printer-Supported-Values response.
-
-See Appendix B: Attributes returned from Get-Printer-Supported-Values
-for a full list of values returned by this operation.
-
-
-
-5 New Operation attributes
-
-
-This section defines new operation attributes for use with the IPP/1.1
-operations indicated. As new operations are defined they will also
-indicate explicitly whether these operation attributes are defined for
-use with them.
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 21]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-5.1 "printer-message-from-operator" (text(127))
-
-
-The Printer SHOULD support this Operation attribute in following
-operations if it supports the corresponding "printer-message-from-
-operator" Printer Description attribute.
-
- Pause-Printer
- Resume-Printer
- Purge-Jobs
-
-The client OPTIONALLY supplies this attribute in the above operations.
-The value of this attribute is a message from the operator about the
-Printer object on which the operator is performing the operation. If
-this operation attribute is supported, the Printer copies the value to
-its "printer-message-from-operator" Printer Description attribute (see
-[ipp-mod] section 4.4.25) even if this Operation attribute is a zero-
-length text value or consists solely of white space.
-
-If the Printer supports this operation attribute, it MUST support both a
-zero-length text value and the 'no-value' out-of-band value (see [ipp-
-mod] section 4.1) to indicate that the operator has sent no message. In
-this case, the Printer sets the value of the "printer-message-from-
-operator" to the zero-length value or 'no-value' out-of-band value,
-respectively. If the client queries the "printer-message-from-operator"
-Printer attribute, the Printer returns the attribute with the zero-
-length value or the 'no-value' value, respectively.
-
-In addition, the Printer automatically copies:
-
- 1. the value of its "printer-up-time" attribute (see [ipp-mod] section
- 4.4.29) to its "printer-message-time" attribute,
-
- 2. the value of its printer-current-time" (dateTime) attribute (see
- [ipp-mod] section 4.4.30) to its "printer-message-date-time"
- attribute, if supported.
-
-If the client omits this operation attribute, the Printer does not
-change the value of its "printer-message-from-operator", "printer-
-message-time" and "printer-message-date-time" Printer Description
-attributes.
-
-The "printer-message-from-operator" operation attribute MUST NOT be
-supported as an operation attribute for the Set-Printer-Attributes
-operation. If the operator wants to set the Printer's "printer-message-
-from-operator" Printer Description attribute when issuing the Set-
-Printer-Attributes operation, the client supplies the "printer-message-
-from-operator" explicitly with its new value as one of the Printer
-Description attributes in Group 2 in the request. The Printer also
-updates its "printer-message-time" and "printer-message-date-time"
-Printer Description attributes. If the client does not explicitly
-supply the "printer-message-from-operator" with its new value in the
-Set-Printer-Attributes request, the Printer leaves the value of the
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 22]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Printer's "printer-message-from-operator" Printer Description attribute
-unchanged.
-
-
-5.2 "job-message-from-operator" (text(127))
-
-
-The Printer SHOULD support this Operation attribute in following
-operations if it supports the corresponding "job-message-from-operator"
-Job Description attribute.
-
- Cancel-Job
- Hold-Job
- Release-Job
- Restart-Job
-
-The client OPTIONALLY supplies this attribute in the above operations.
-The value of this attribute is a message from the operator about the Job
-object on which the operator has just performed an operation. If
-supported, the Printer copies the value to the Job's "job-message-from-
-operator" Job Description attribute (see [ipp-mod] section 4.3.16) (even
-if this Operation attribute is a zero-length text value or consists
-solely of white space).
-
-If the Printer supports this operation attribute, it MUST support both a
-zero-length text value and the 'no-value' out-of-band value (see [ipp-
-mod] section 4.1) to indicate that the operator has sent no message. In
-this case, the Printer sets the value of the "job-message-from-operator"
-to the zero-length value or 'no-value' out-of-band value, respectively.
-If the client queries the "job-message-from-operator" Job attribute, the
-IPP object returns the attribute with the zero-length value or the 'no-
-value' value, respectively.
-
-If the client omits this attribute, the Printer does not change the
-value of its "job-message-from-operator" Job Description attribute.
-
-Note: There are no corresponding 'job-message-time" and "job-message-
-date-time" Job Description attributes, since the usual lifetime of a job
-is limited.
-
-The "job-message-from-operator" operation attribute MUST NOT be
-supported as an operation attribute for the Set-Job-Attributes
-operation. If the operator wants to set the Job's "job-message-from-
-operator" Job Description attribute when issuing the Set-Job-Attributes
-operation, the client MUST supply the "job-message-from-operator" with
-its new value as one of the Job Description attributes in Group 2 in the
-request. Otherwise, the Printer leaves the value of the Job's "job-
-message-from-operator" Job Description attribute unchanged by not
-explicitly setting the attribute. If the client does not explicitly
-supply the "job-message-from-operator" with its new value in the Set-
-Job-Attributes request, the Printer leaves the value of the Job's "job-
-message-from-operator" Job Description attribute unchanged.
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 23]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-6 New Printer Description Attributes
-
-
-The following new Printer Description attributes are needed to support
-the new operations defined in this document.
-
-
-6.1 printer-settable-attributes-supported (1setOf type2 keyword)
-
-
-This REQUIRED READ-ONLY Printer attribute identifies the Printer object
-attributes that are settable in this implementation, i.e., that are
-settable using the Set-Printer-Attributes operations (see section 4.1).
-This attribute MUST be supported if the Set-Printer-Attributes
-operations is supported. The Printer MUST reject attempts to set any
-Printer attributes that are not one of the values of this attribute,
-returning the 'client-error-attributes-not-settable' status code (see
-section 7.1). The value of this attribute MAY depend on the value of
-the "document-format" operation attribute supplied in the Get-Printer-
-Attributes operation (see [ipp-mod] section 3.2.5.1).
-
-Standard keyword values are:
-
- 'none': There are no settable Printer attributes.
- 'xxx': Where 'xxx' is any of the keyword attribute names allowed by
- section 4.1.1
-
-6.2 job-settable-attributes-supported (1setOf type2 keyword)
-
-
-This REQUIRED READ-ONLY Printer attribute identifies the Job object
-attributes that are settable in this implementation, i.e., that are
-settable using the Set-Job-Attributes operation (see section 4.2). This
-attribute MUST be supported if the Set-Job-Attributes operations is
-supported. The Printer MUST reject attempts to set any Job attributes
-that are not one of the values of this attribute, returning the 'client-
-error-attributes-not-settable' status code (see section 7.1).
-
-Standard keyword values are:
-
- 'none': There are no settable Job attributes.
- 'xxx': Where 'xxx' is any of the keyword attribute names allowed by
- section 4.2.1.
-
-6.3 document-format-varying-attributes (1setOf type2 keyword)
-
-
-This OPTIONAL READ-ONLY Printer Description attribute contains a set of
-attribute name keywords. This attribute SHOULD be supported by a
-Printer object, if the Printer object has Printer attributes whose value
-vary depending on document format (see [ipp-mod] Get-Printer-Attributes
-operation). This attribute specifies which attribute values can vary by
-document-format. If an attribute's name "xxx" is a member of this
-attribute and the value of attribute "xxx" is changed with the Set-
-Printer-Attributes operation that included the "document-format"
-operation attribute, then the Printer MUST change the value for the
-specified document format and no other document formats (see section
-
-
-Hastings, Herriot, Kugler, Lewis [Page 24]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-4.1.2). If an attribute's name "xxx" is not a member of this attribute
-and the value of attribute "xxx" is changed with the Set-Printer-
-Attributes operation, then the attribute is changed for all document
-formats (whether or not the client supplied the "document-format"
-operation attribute).
-
-
-6.4 printer-message-time (integer(MIN:MAX))
-
-
-This OPTIONAL READ-ONLY Printer Description attribute contains the time
-that the Printer's "printer-message-from-operator" was changed by the
-operator using any operation where the client supplied the "printer-
-message-from-operator" operation attribute (see section 5.1) or was
-explicitly set using the Set-Printer-Attributes operation (see section
-4.1). This attribute allows the users to know when the "printer-
-message-from-operator" attribute was last set.
-
-The Printer sets the value of this attribute by copying the value of the
-Printer's "printer-up-time" attribute (see [ipp-mod] section 4.3.14).
-If the Printer resets its "printer-up-time" attribute to 1 on power-up,
-then it MUST change the value of the "printer-message-time" to 0 or a
-negative number as specified in [ipp-mod] section 4.3.14.
-
-Note: This attribute helps users better understand the context for the
-"printer-message-from-operator" message.
-
-
-6.5 printer-message-date-time (dateTime)
-
-
-This OPTIONAL READ-ONLY Printer Description attribute contains the date
-and time that the Printer's "printer-message-from-operator" was changed
-by the operator using any operation where the client supplied the
-"printer-message-from-operator" operation attribute (see section 5.1) or
-was explicitly set using the Set-Printer-Attributes operation (see
-section 4.1). This attribute allows the users to know when the
-"printer-message-from-operator" attribute was last set.
-
-This attribute MUST be supported if the Printer supports both the
-"printer-message-time" and the "printer-current-time" (dateTime)
-attributes (see [ipp-mod] section 4.4.30).
-
-Note: This attribute helps users better understand the context for the
-"printer-message-from-operator" message.
-
-
-6.6 printer-xri-supported (1setOf collection)
-
-
-This OPTIONAL Printer Description attribute is a multi-valued attribute
-where each value has the 'collection' attribute syntax (see [ipp-coll])
-containing member attributes with the same semantics as the following
-IPP/1.1 READ-ONLY Printer Description attributes, except for
-cardinality:
-
- printer-uri-supported (1setOf uri) - see [ipp-mod] section 4.4.1
-
-
-Hastings, Herriot, Kugler, Lewis [Page 25]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- uri-authentication-supported (1setOf type2 keyword) - see [ipp-mod]
- section 4.4.2
- uri-security-supported (1setOf type2 keyword) - see [ipp-mod]
- section 4.4.3
-
-When setting the "printer-xri-supported" attribute with a Set-Printer-
-Attributes request, the Printer MUST also set these three IPP/1.1 READ-
-ONLY Printer Description attributes as a defined side effect. Thus,
-this collection attribute provides the means to set these three IPP/1.1
-READ-ONLY attributes atomically so that they are never left in a
-partially inconsistent state.
-
-An IPP Printer MUST NOT provide any other way using IPP to set these
-three IPP/1.1 READ-ONLY Printer Description attributes, since they are
-READ-ONLY and MUST have consistent values at all times. Note: The
-"xri-printer-supported" (1setOf collection) attribute can be put into a
-directory schema that requires a single text string value, such as SLP
-or LDPA, by using suitable delimiting characters to separate member
-attributes of the collection and/or terminating collection values. See
-[svrloc-printer] and [ldap-printer].
-
-The member attributes of the "printer-xri-supported" (1setOf collection)
-are given in Table 3.
-
- Table 3 - Member attributes of "printer-xri-supported" (1setOf
- collection)
-
- Member attribute client Printer
- MUST MUST
- supply support
-
- xri-uri (uri) yes yes
-
- xri-authentication (1setOf type2 keyword) yes yes
-
- xri-security (1setOf type2 keyword) yes yes
-
-Each collection value MUST contain a single unique value for the "xri-
-uri" member attribute. However, the other two member attributes are
-multi-valued, so that a single URI can support more than one
-authentication scheme and/or more than one security scheme. Other than
-the uniqueness and the cardinality requirements, the semantics of these
-three member attributes is given in [ipp-mod] sections 4.4.1, 4.4.2, and
-4.4.3, respectively.
-
-A client can query the current values using the Get-Printer-Attributes
-operation by supplying either:
-
- 1. the three IPP/1.1 attribute names: "printer-uri-supported", "uri-
- authentication-supported", "uri-security-supported" and getting
- back the parallel values OR
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 26]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- 2. the single attribute name: "printer-xri-supported" and getting back
- the 1setOf collection which contains the same information
- semantically, but in a different form.
-
-A client can query what member attribute values can be set by supplying
-the three attribute names: "xri-uri-scheme-supported", "xri-
-authentication-supported", and "xri-security-supported" in a Get-
-Printer-Supported-Values request and getting back the uriScheme and
-type2 keyword values that can be set. Since the "printer-xri-
-supported", "uri-authentication-supported", and "uri-security-supported"
-attributes are READ-ONLY, they are not queriable with the Get-Printer-
-Supported-Values operation (see section 4.3). See Table 15.
-
-When performing a Set-Printer-Attributes operation, if there are
-multiple values for the "xri-authentication" and/or "xri-security"
-member attributes, the Printer MUST set the corresponding three READ-
-ONLY attributes with all possible combinations of values. For example,
-setting the "printer-xri-supported" with the following two collection
-values where the first URI has both 'basic' and 'digest' authentication:
-
-
- "printer-xri-supported =
- { "xri-uri" = ipp://abc.com/p1
- "xri-authentication" = basic, digest
- "xri-security" = tls
- },
- { "xri-uri" = http://abc.com/pq
- "xri-authentication" = none
- "xri-security" = none
- }
-
-
-would cause the Printer to set the three corresponding IPP/1.1 READ-ONLY
-attributes, each with three parallel values as follows:
-
-
- "printer-uri-supported" = { ipp://abc.com/p1, ipp://abc.com/p1,
- http://abc.com/pq }
- "uri-authentication-supported" = { basic, digest, none }
- "uri-security-supported" = { tls, tls, none }
-
-
-Because there were two authentication values for the ipp://abc.com/p1
-URL, that URL value is repeated. Had the ipp URL had 2 authentication
-values and 3 security values, then there would have been 7 (2*3 + 1)
-parallel values for each of the three attributes, 6 with the same ipp
-URI and 1 with the http URI.
-
-
-6.7 xri-uri-scheme-supported (1setOf uriScheme)
-
-
-This OPTIONAL READ-ONLY Printer Description attribute identifies the URI
-schemes that the implementation supports for use in the "printer-uri-
-supported" (1setOf uri) Printer Description attribute (see [ipp-mod]
-section 4.4.1) and the "xri-uri" member attribute of the "xri-printer-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 27]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-supported" (1setOf collection) Printer Description attribute (see
-section 6.6).
-
-A Printer MUST support this attribute if it supports setting the
-"printer-xri-supported" (1setOf collection) with the Set-Printer-
-Attributes operation.
-
-
-6.8 xri-authentication-supported (1setOf type2 keyword)
-
-
-This OPTIONAL READ-ONLY Printer Description attribute identifies the
-Client Authentication mechanisms that the implementation supports for
-use in the "printer-authentication-supported" (1setOf type2 keyword)
-Printer Description attribute (see [ipp-mod] section 4.4.2) and the
-"xri-authentication" member attribute of the "xri-printer-supported"
-(1setOf collection) Printer Description attribute (see section 6.6).
-
-A Printer MUST support this attribute if it supports setting the
-"printer-xri-supported" (1setOf collection) with the Set-Printer-
-Attributes operation.
-
-
-6.9 xri-security-supported (1setOf type2 keyword)
-
-
-This OPTIONAL READ-ONLY Printer Description attribute identifies the URI
-schemes that the implementation supports for use in the "printer-
-security-supported" (1setOf type2 keyword) Printer Description attribute
-(see [ipp-mod] section 4.4.3) and the "xri-security" member attribute of
-the "xri-printer-supported" (1setOf collection) Printer Description
-attribute (see section 6.6).
-
-A Printer MUST support this attribute if it supports setting the
-"printer-xri-supported" (1setOf collection) with the Set-Printer-
-Attributes operation.
-
-
-
-7 Additional status codes
-
-This section defines new status codes used by the operations defined in
-this document.
-
-7.1 'client-error-attributes-not-settable' (0x0413)
-
-
-The Set-Printer-Attributes or Set-Job-Attributes operation failed
-because one or more of the specified attributes cannot be set either
-because the attribute is defined to be READ-ONLY or the attribute is not
-settable in this implementation (see sections 4.1.3 and 4.2.3), the
-Printer MUST return this error code and the attribute keyword name(s)
-and the 'not-settable' out-of-band value (see section 8.1) in the
-Unsupported Attributes Group(see [ipp-mod] section 3.1.7) for all of the
-attributes that could not be set. When the Printer returns this status,
-it MUST NOT change any of the attributes supplied in the operation.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 28]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-8 Additional out-of-band values
-
-
-This section defines additional out-of-band values. As with all out-of-
-band values, a client or a Printer MUST NOT use an out-of-band value
-unless the definition of the attribute in an operation request and/or
-response explicitly allows such usage. See the beginning of [ipp-mod]
-section 4.1.
-
-
-8.1 'not-settable' out-of-band value
-
-
-The 'not-settable' out-of-band attribute value is returned by the IPP
-Printer in the Unsupported Attributes group of a response to indicate
-that the attribute supplied by the client in the request is READ-ONLY by
-definition or is not settable in this implementation.
-
-The 'not-settable' out-of-band attribute value is defined for use with
-the Set-Job-Attributes and Set-Printer-Attributes response only. If a
-future additional "set" operation allows the 'not-settable' out-of-band
-value, its definition document MUST indicate such use explicitly,
-including with which attributes.
-
-An IPP object MUST support the 'not-settable' out-of-band value in a
-Set-Job-Attributes or Set-Printer-Attributes request if it supports
-those operations. A client MUST NOT supply the 'not-settable' out-of-
-band value in any request. An IPP object MUST NOT support the 'not-
-settable' out-of-band value in other operations, unless the operations'
-definition document explicitly defines such usage. If a Printer
-receives this out-of-band value in any operation request, the Printer
-MUST either (1) reject the entire request and return the 'client-error-
-bad-request' status code or (2) ignore the attribute and return it with
-the 'unsupported' out-of-band value.
-
-See sections 4.1.3 and 4.2.3 in this document for an example definition
-of the usage of the 'not-settable' out-of-band value in the Set-Printer-
-Attributes and Set-Job-Attributes responses.
-
-
-8.1.1Encoding of the 'not-settable' out-of-band attribute value
-
-The encoding of the 'not-settable' out-of-band value is 0x15 (see [ipp-
-pro]). The value-length MUST be 0 and the value empty.
-
-
-8.2 'delete-attribute' out-of-band value
-
-
-The 'delete-attribute' out-of-band attribute value is supplied by the
-client in a request to indicate that the Printer is to remove the
-supplied attribute and all of its values from the target object, if
-present.
-
-The 'delete-attribute' out-of-band attribute value is defined for use
-with the Set-Job-Attributes request only. If a future additional "set"
-operation allows the 'delete-attribute' out-of-band value, its
-
-Hastings, Herriot, Kugler, Lewis [Page 29]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-definition document MUST indicate such use explicitly, including with
-which attributes.
-
-An IPP Printer MUST support the 'delete-attribute' out-of-band value if
-it supports the Set-Job-Attributes operation. A client MUST NOT supply
-and an IPP object MUST NOT support the 'delete-attribute' out-of-band
-value in other operations, unless the operations' definition document
-explicitly defines such usage. For example, the 'delete-attribute' out-
-of-band value MUST NOT be used in the Set-Printer-Attributes operation,
-where the absence of an attribute from an IPP object indicates that the
-attribute is not supported. If a Printer receives this out-of-band
-value in other operation requests, the Printer MUST either (1) reject
-the entire request and return the 'client-error-bad-request' status code
-or (2) ignore the attribute and return it with the 'unsupported' out-of-
-band value.
-
-See section 4.2 in this document for the definition of the usage of the
-'delete-attribute' out-of-band value in the Set-Job-Attributes request.
-
-
-8.2.1Encoding of the 'delete-attribute' out-of-band value
-
-The encoding of the 'delete-attribute' out-of-band value is 0x16 (see
-[ipp-pro]). The value-length MUST be 0 and the value empty.
-
-
-8.3 'admin-define' out-of-band attribute value
-
-
-Section 4.3 defines the Get-Printer-Supported-Values response to contain
-the values of an "xxx-supported" attribute that are supported by the
-implementation before any additional value are defined by the
-administrator. The 'admin-define' out-of-band attribute value is
-returned as an additional value of an "xxx-supported" attribute in a
-Get-Printer-Supported-Values response to indicate that the
-implementation supports allowing an administrator to define additional
-arbitrary 'name' values for that "xxx-supported" attribute.
-
-For example, if the "media-supported" (1setOf (type3 keyword | name))
-attribute contains this value, then the Printer MUST permit an
-administrator to add new media names to the Printer's "media-supported"
-attribute. In order for an administrator to add new values to a
-Printer's "xxx-supported" attribute, the client supplies the existing
-and new values in a Set-Printer-Attributes request for that attribute.
-The client MUST supply any such administratively defined values in the
-Set-Printer-Attributes request using the 'name' attribute syntax.
-
-The 'admin-define' out-of-band attribute value is defined for use with
-the Get-Printer-Supported-Values response only. A Printer MUST NOT
-return the 'admin-define' out-of-band value in a Get-Printer-Attributes
-response, since such a response indicates what an end-user client can
-supply in a Job Creation operation. If a future additional "get"
-operation allows the 'admin-define' out-of-band value, its definition
-document MUST indicate such use explicitly, including with which
-attributes.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 30]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-An IPP Printer MUST support the 'admin-define' out-of-band value, if it
-supports a client setting arbitrary 'name' values of an "xxx-supported"
-Printer attribute using the Set-Printer-Attributes operation. A client
-MUST NOT supply the 'admin-define' out-of-band value in any request. An
-IPP object MUST NOT support the 'admin-define' out-of-band value in
-other operations, unless the operations' definition document explicitly
-defines such usage. If a Printer receives this out-of-band value in any
-operation request, the Printer MUST either (1) reject the entire request
-and return the 'client-error-bad-request' status code or (2) ignore the
-attribute and return it with the 'unsupported' out-of-band value.
-
-This document defines that the 'admin-define' out-of-band value MUST be
-used only with "xxx-supported" attributes that are defined to include
-the 'name' attribute syntax. This out-of-band value is not intended to
-be used with "xxx-supported" attributes of other attribute syntaxes,
-such as 'uri', even though the administrator defines arbitrary values
-for such attributes. If other documents extend the use of the 'admin-
-define' out-of-band value to other attribute syntaxes, such a document
-MUST define such use explicitly, including with which attributes.
-
-See section 4.3 in this document for an example definition of the usage
-of the 'admin-define' out-of-band attribute value in any "xxx-supported"
-attribute returned in a Get-Printer-Supported-Values response that is
-defined to include the 'name' attribute syntax.
-
-
-8.3.1Encoding of the 'admin-define' out-of-band attribute value
-
-The encoding of the 'admin-define' out-of-band attribute value is 0x17
-(see [ipp-pro]). The value-length MUST be 0 and the value empty.
-
-
-
-9 Conformance Requirements
-
-
-This section specifies the conformance requirements for clients and IPP
-objects.
-
-Both the Set-Job-Attributes and the Set-Printer-Attributes operations
-defined in the document are OPTIONAL for an IPP object to support.
-Either one MAY be supported without the other or both MAY be supported.
-However, if the Set-Printer-Attributes operation is supported, then the
-Get-Printer-Supported-Values operation MUST be supported if any "xxx-
-supported" attributes are settable. Otherwise, the Get-Printer-
-Supported-Values operation is OPTIONAL for an IPP Printer to support.
-
-If the Set-Printer-Attributes operation is supported, then the Printer
-MUST support the following additional items:
-
- 1.the Get-Printer-Supported-Values operation (see section 5), if
- any "xxx-supported" attributes are settable.
-
- 2.the "printer-settable-attributes-supported" Printer Description
- attribute (see section 6.1)
-
-
-Hastings, Herriot, Kugler, Lewis [Page 31]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- 3.the 'not-settable' out-of-band value in responses (see section
- 8.1)
-
- 4.the 'client-error-not-settable' status code (see section 7.1)
-
- 5.If "printer-message-from-operator" Printer Description attribute
- is supported (see [ipp-mod] section 4.4.25), then it MUST be
- settable.
-
- 6.the Get-Printer-Supported-Values operation (see section 4.3), if
- any "xxx-supported" attributes are settable.
-
- 7.If a client can set a value with the 'name' attribute syntax for
- one or more "xxx-supported" attributes, then the 'admin-define'
- out-of-band attribute value (see section 8.3) MUST be supported
- in the Get-Printer-Supported-Values response for each such
- settable attribute (see section 4.3)
-
-If the Set-Job-Attributes operation is supported, then the Printer MUST
-support the following additional items:
-
- 1.the "job-settable-attributes-supported " Printer Description
- attribute (see section 6.2)
-
- 2.the 'not-settable' out-of-band value in responses (see section
- 8.1)
-
- 3.the 'delete-attribute' out-of-band value in requests (see
- section 8.2)
-
- 4.the 'client-error-not-settable' status code (see section 7.1)
-
- 5.If the "job-message-from-operator" Printer Description attribute
- is supported (see [ipp-mod] 4.3.16), then it MUST be settable.
-
-It is OPTIONAL for the Printer object to support the "printer-message-
-time" (integer) and "printer-message-date-time" (dateTime) Printer
-Description attributes. If both the "printer-message-time" (integer)
-and the "printer-current-time" (dateTime) (see [ipp-mod] section 4.4.30)
-attributes are supported, then the "printer-message-date-time"
-(dateTime) Printer Description attribute MUST be supported.
-
-As with all out-of-band values, a client or a Printer MUST NOT use an
-out-of-band value unless the definition document for the attribute in an
-operation request and/or response explicitly allows such usage.
-
-
-
-10 IANA Considerations
-
-Since this document is intended to be a standards track document, there
-is no need to also register the operations, attributes, status codes,
-and out-of-band values defined here-in with IANA according to the
-procedures in RFC 2566 [rfc2566] section 6. However, other registration
-
-
-Hastings, Herriot, Kugler, Lewis [Page 32]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-proposals may site the out-of-band attribute values or the status codes
-defined in this document.
-
-
-11 Internationalization Considerations
-
-This document has the same localization considerations as the [ipp-mod].
-
-
-12 Security Considerations
-
-
-The IPP Model and Semantics document [ipp-mod section 8] discusses high
-level security requirements (Client Authentication, Server
-Authentication and Operation Privacy). Client Authentication is the
-mechanism by which the client proves its identity to the server in a
-secure manner. Server Authentication is the mechanism by which the
-server proves its identity to the client in a secure manner. Operation
-Privacy is defined as a mechanism for protecting operations from
-eavesdropping.
-
-In addition, the introduction of the Set-Printer-Attributes and Set-Job-
-Attributes operations creates another security threat, since the client
-is able to modify the Printer and Job attributes stored in the Printer.
-Such modifications could lead to denial of service.
-
-A malicious user could alter the policy established by the system
-administrator and stored in the Printer attributes. Such alteration
-could either grant access to more resources or deny access to resources
-that the system administrator has established. For example, the
-malicious user could remove all of the document-format values from the
-"document-format-supported" Printer attribute so that the Printer would
-refuse to accept all jobs.
-
-The general remedy for such malicious user actions against Printer
-attributes is to have strong Client Authentication coupled with Printer
-access control to limit the users who have System Administrator or
-Operator privileges.
-
-A malicious user could modify the Job Template attributes of another
-user's Job, such as the "copies" attribute. For example, setting the
-number of copies to a large number.
-
-The general remedy for such malicious user actions against another
-user's job is to have strong Client Authentication coupled with Printer
-access control to limit the users who have System Administrator or
-Operator privileges who can modify any job and, in addition, store the
-Client Authentication with each Job so that only the job owner End User
-can modify his/her own job.
-
-
-
-13 Author's Addresses
-
- Carl Kugler
-
-Hastings, Herriot, Kugler, Lewis [Page 33]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- IBM
- P.O. Box 1900
- Boulder, CO 80301-9191
-
- Phone: (303) 924-5060
- FAX:
- e-mail: kugler@us.ibm.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
- Robert Herriot
- Xerox Corp.
- 3400 Hill View Ave, Building 1
- Palo Alto, CA 94304
-
- Phone: 650-813-7696
- Fax: 650-813-6860
- e-mail: robert.herriot@pahv.xerox.com
-
- Harry Lewis
- IBM
- P.O. Box 1900
- Boulder, CO 80301-9191
-
- Phone: (303) 924-5337
- FAX:
- e-mail: harryl@us.ibm.com
-
-
-
-14 References
-
-[ipp-coll]
- deBry, R., , Hastings, T., Herriot, R., "Internet Printing Protocol
- (IPP): The Collection Attribute Syntax", <draft-ietf-ipp-
- collection-02.doc>, work in progress, March 9, 2000.
-
-[ipp-mod]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
- ipp-model-v11-06.txt>, March 1, 2000.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 05.txt, March 1, 2000.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 34]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-[ipp-set2]
- Kugler, C, Hastings, T., Lewis, H., "Internet Printing
- Protocol/1.1: Job and Printer Administrative Operations", <draft-
- ietf-ipp-ops-set2-01.txt>, December 8, 1999.
-
-[ldap-printer]
- Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing
- Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp-
- ldap-printer-schema-00.txt>, work in progress, March 8, 2000.
-
-[RFC2565]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
-
-[RFC2566]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April 1999.
-
-[svrloc-printer]
- St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the
- Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer-
- scheme-06.txt>, work in progress, March 8, 2000.
-
-
-
-15 Change History
-
-
-This section summarizes the changes. Each sub-section is in reverse
-chronological order. Adding or removing ISSUES that don't change the
-document are not listed here.
-
-
-15.1Changes to the March 21, 2000 version to make the March 23, 2000
- version
-
-
-The following changes have been made to the March 21, 2000 version to
-make the March 23, 2000 version as a result of the IPP WG telecons and
-mailing list discussion:
-
-1.Changed the name of the 'custom' out-of-band value to 'admin-define'.
-
-2.Tightened up the spec for 'admin-define' so that it cannot be used
- returned in a Get-Printer-Attributes response to allow users to
- submit arbitrary values in a Job Creation operation. If that
- functionality is needed, it will have to be done with another out of
- band value.
-
-3.Clarified that the 'admin-define' out-of-band value is only intended
- to be used with "xxx-supported" attributes in a Get-Printer-
- Supported-Values response that are defined to include the 'name'
- attribute syntax. If other documents extend this usage, they MUST
- define for which attributes and operations.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 35]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-4.Added the definitions of the xri-uri-scheme-supported (1setOf
- uriScheme), xri-authentication-supported (1setOf type2 keyword), and
- xri-security-supported (1setOf type2 keyword) READ-ONLY Printer
- attributes that were only referred to. Also made them returnable
- only in Get-Printer-Attributes, not Get-Printer-Supported-Values,
- since they are READ-ONLY and the administrator cannot change them.
-
-5.Clarified that the few "xxx-supported" attributes that are single
- valued, are made 1setOf X in the Get-Printer-Supported-Values so that
- the implementation can indicate what possible values can be set.
-
-6.Required the client to have administrator access rights in order to
- use the Get-Printer-Supported-Values operation, since its purpose is
- for administrators to use before doing a Set-Printer-Attributes
- operation.
-
-7.Clarified that if an implementation supports setting arbitrary names
- in a Set-Printer-Attributes request, then it MUST support the 'admin-
- define' out-of-band value in the Get-Printer-Supported-Values
- response.
-
-8.Copied the validation rules from the Implementer's Guide into
- Appendix A, since the IIG is not a standards track document. Still
- refer to the IIG for additional non-normative explanation.
-
-
-15.2Changes to the March 8, 2000 version to make the March 21, 2000
- version
-
-
-The following changes have been made to the March 8, 2000 version to
-make the March 21, 2000 version as a result of the IPP WG telecons and
-mailing list discussion:
-
-9.Changed the name of the 'any-value' out-of-band value to 'custom'.
- Removed the idea of encoding the attribute syntax that the 'custom'
- out-of-band value goes with. Required the value length to be zero.
- Instead, the spec for the attribute or attribute syntax defines
- whether or not the 'custom' out-of-band value can be used.
-
-10. Clarified that the 'custom' out-of-band value can be used in
- combination with other values of an "xxx-supported" Printer
- attribute.
-
-11. Clarified that an implementation is not prevented from supporting
- some 'name' attribute values for "xxx-supported" out-of-the-box, if
- desired. But these values would be returned in a Get-Printer-
- Supported-Values response, such like keywords are.
-
-
-
-
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 36]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-15.3Changes to the March 1, 2000 version to make the March 8, 2000
- version
-
-
-The following changes have been made to the March 1, 2000 version to
-make the March 8, 2000 version as a result of the IPP WG telecons and
-mailing list discussion:
-
-1.Added the "printer-xri-supported" (1setOf collection) attribute so
- that the three parallel IPP/1.1 "printer-uri-supported", "uri-
- authentication-supported", and "uri-security-supported" attributes
- could be set as one atomic attribute. Consequently, changed the
- three parallel attributes to be READ-ONLY and removed the requirement
- that three attributes MUST be set in a single request if the three
- parallel IPP/1.1 "printer-uri-supported", "uri-authentication-
- supported", and "uri-security-supported" were settable.
-
-2.Clarified Get-Printer-Supported-Values so that if an implementation
- does not support setting a settable attribute, it MUST NOT return the
- attribute in the Printer Attribute group and it NEED NOT return the
- attribute in the Unsupported Attributes group, same as in a Get-
- Printer-Attributes response for unsupported attributes. Same
- clarification when unsupported attributes are requested.
-
-3.Fixed "printer-message-date-time" (dateTime) attribute to be
- OPTIONAL.
-
-4.Added note as to why the "printer-current-time" Printer Description
- attribute is settable (to fix an incorrect time or time zone).
-
-5.Added "xri-authentication-supported" (1setOf type2 keyword) and "xri-
- security-supported" (1setOf type2 keyword) attributes to the table of
- attributes that can be queried with Get-Printer-Supported-Values.
- Added a note that these two attributes are NOT queriable with Get-
- Printer-Attributes, since the client queries either (1) the three
- "printer-uri-supported" (1setOf uri), "uri-authentication-supported"
- (1setOf type2 keyword), "uri-security-supported" (1setOf type2
- keyword) attributes, or (2) the single "printer-xri-supported"
- (1setOf collection) attribute.
-
-
-15.4Changes to the January 30, 2000 version to make the March 1, 2000
- version
-
-
-The following changes to the January 30, 2000 version to make the March
-1, 2000 version as a result of the IPP WG telecons and mailing list
-discussion:
-
-1.Clarified that this extension may be used with any IPP version,
- including 1.0, 1.1, and future versions.
-
-2.Added "READ-ONLY" and "not-settable" terms to the terminology
- section. READ-ONLY is by definition, and "not-settable" is by
- implementation.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 37]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-3.Assigned the "operation-id" values 0x0013, 0x0014, and 0x0015,
- respectively, for the Set-Printer-Attributes, Set-Job-Attributes, and
- Get-Printer-Supported-Values operations.
-
-4.Clarified that the Set-Printer-Attributes operation while a Printer
- SHOULD accept a reasonable number of attribute, the Printer need only
- support setting one attribute in a request, unless it supports
- setting the three "parallel" attributes, ("printer-uri-supported",
- "uri-authentication-supported", and "uri-security-supported" (see
- [ipp-mod] sections 4.4.1 through 4.4.3), in which case it MUST
- support setting at least three attributes in a single request.
-
-5.Clarified that for the Set-Printer-Attributes operation the Printer
- MUST validate all of the supplied attributes in combination with each
- other, as well as with all of the existing attribute of the Printer
- object Set-Printer-Attributes.
-
-6.Changed the requirements for accepting the Set-Printer-Attributes
- operation when the Printer is in the 'stopped' state from MUST to
- SHOULD, since some implementations may not be able to accept requests
- when stopped.
-
-7.Clarified that setting certain Printer attributes with Set-Printer-
- Attributes MAY require more access rights than other attributes,
- i.e., System Administrator rights to set policy and only Operator
- rights to set the configuration attributes to reflect the current
- hardware setup.
-
-8.Clarified the order of error checking and what is returned in each
- case in the Set-Printer-Attributes response.
-
-9.Changed the 'default' out-of-band value to 'delete-attribute' out-of-
- band value so that the effect is to actually remove the Job attribute
- entirely in the Set-Job-Attribute operation.
-
-10. Clarified that removing a Job attribute that is not present is not
- an error.
-
-11. Clarified the validation of the Set-Job-Attributes request and what
- is returned for each error.
-
-12. Changed the 'any-name' out-of-band attribute value to a more
- general 'any-value' out-of-band attribute value which in combination
- with an attribute syntax represents any value of that attribute
- syntax. The 'any-value' value can be used with the 'name' attribute
- syntax in a Get-Printer-Supported-Values response to indicate whether
- or not a Set-Printer-Attributes will accept any name to be set for
- particular "xxx-supported" (1setOf name | ...) Printer attributes.
-
-13. Clarified that "printer-message-from-operator" and "job-message-
- from-operator" both REQUIRE that the Printer accept zero-length
- messages and the 'no-value' out-of-band value is synonymous with
- removing any value from these Printer attributes.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 38]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-14. Clarified that the Get-Printer-Supported-Values is REQUIRED only if
- the Set-Printer-Attributes operation will accept setting some "xxx-
- supported" Printer attributes.
-
-15. Changed the IANA Considerations to indicate that the operations,
- attributes, status codes, and out-of-band-values won't be registered
- and published by IANA, since this document is intended to be
- standards track.
-
-16. Added security considerations for denial of service and sabotage
- because of the Set operations.
-
-
-15.5Changes to the January 20, 2000 version to make the January 30, 2000
- version
-
-
-The following changes to the January 20, 2000 version to make the
-January 30, 2000 version as a result of the IPP WG telecons and mailing
-list discussion:
-
-1.Deleted the "document-format-varying-scope" operation attribute from
- the Set-Printer-Attributes operation and made whether or not the
- "document-format" operation was present determine whether one or all
- document formats are affected, respectively.
-
-2.Renamed the Get-Reset-Printer-Attributes operation to Get-Printer-
- Supported-Values, so that it only returns "xxx-supported" values.
- Relegate obtaining reset values to another operation to be paired
- with the Reset-Printer operation in the Set2 [ipp-set2] document.
-
-3.Added "-supported" to the names of the "printer-settable-attributes"
- and "job-settable-attributes" Printer Description attributes, so that
- they could be returned in Get-Printer-Supported-Values and could be
- set by Set-Printer-Attributes.
-
-4.Deleted "authentication-methods-supported" (1setOf type2 keyword) and
- "security-methods-supported" (1setOf type2 keyword) and clarified
- that "uri-authentication-supported" (1setOf type2 keyword) and "uri-
- security-supported" (1setOf type2 keyword) can return multiple
- keywords of the same value in a Get-Printer-Supported-Values
- operation.
-
-
-15.6Changes to the January 4, 2000 version to make the January 20, 2000
- version
-
-
-The following changes to the January 4, 2000 version to make the January
-4, 2000 version as a result of the IPP WG telecons and mailing list
-discussion:
-
-1.Replaced the "factory-settings" operation attribute proposed to be
- added to the Get-Printer-Attributes operation with the Get-Rest-
- Printer-Attributes operation which returns the reset values and the
- possible "xxx-supported" values.
-
-Hastings, Herriot, Kugler, Lewis [Page 39]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-2.Added the out-of-band 'any-name' value to be used with "xxx-
- supported" attributes with attribute syntax 'type3 keyword | name' to
- indicate that any name will be accepted in a Job Creation operation
- for configurations that support such a concept.
-
-3.Added authentication-methods-supported (1setOf type2 keyword) and
- security-methods-supported (1setOf type2 keyword) Printer Description
- attributes so that clients can discover the possible values for use
- in Set-Printer-Attributes to set "uri-authentication-supported" and
- "uri-security-supported" attributes, since the Reset-Printer
- operation doesn't change them.
-
-4.Added validation rules that the Printer MUST use to validate a Set-
- Printer-Attributes request.
-
-5.Clarified that the Set-Printer-Attributes operation MUST NOT have any
- side effects on other attributes, unless explicitly specified in this
- document.
-
-6.Moved the specification of the attributes that MUST be READ-ONLY to
- Appendix A.
-
-7.Added the "document-format-varying-attributes" (1setOf type2 keyword)
-
-8.Added the REQUIRED "document-format-varying-scope" operation
- attribute to Set-Printer-Attributes in order to control whether one
- or all document formats are affected for those attributes that vary
- by document format.
-
-9.Clarified that the Printer returns the 'client-error-attributes-not-
- settable' status code in a Set-Printer-Attributes response whether
- the attribute is READ-ONLY, the attribute is not supported, or the
- value is not supported.
-
-10. Added the out-of-band 'default' value for use with Set-Job-
- Attributes and Job Creation operations.
-
-11. Deleted the "printer-message-operation" Printer Description
- attribute.
-
-12. Made the "Get-Reset-Printer-Attributes" operation, along with the
- "authentication-methods-supported" and the "security-methods-
- supported" Printer Description attributes REQUIRED, if the Set-
- Printer-Attributes operation is supported.
-
-13. Made the 'not-settable' out-of-band value and the 'client-error-
- not-settable' status code REQUIRED, if the Set-Printer-Attributes
- operation is supported.
-
-14. Made the 'default' out-of-band value REQUIRED, if the Set-Job-
- Attributes operation is supported.
-
-15. Removed the requirement that "xxx-supported" Printer Description
- attributes that contain only one value be read-only.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 40]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-15.7Changes to the December 8, 1999 version to make the January 4, 2000
- version
-
-
-The following changes to the December 8, 1999 version to make the
-January 4, 2000 version as a result of the IPP WG telecons and mailing
-list discussion:
-
-1.Removed the Set operations and related items from the Set2
- specification [ipp-set2] to create this Set specification.
-
-2.Added that an attribute that can only be set to one fixed value
- SHOULD NOT be included in the "printer-settable-attributes" or "job-
- settable-attributes" attributes.
-
-3.Indicated that the encoding of the 'not-settable' out-of-band value
- is TBD.
-
-4.Added that Set-Job-Attributes operation adds an attribute to the Job
- object if it wasn't already there
-
-5.Added the conformance section to make it easy to understand the
- conformance requirements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 41]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-16 Appendix A: Allowed Values for Set-Printer-Attributes and Set-Job-
- Attributes requests
-
-
-This appendix is a normative part of this document and contains a table
-of all IPP/1.1 attributes. Each row contains:
-
- @ an attribute and
-
- @ the values allowed in the Set-Printer-Attributes or Set-Job-
- Attributes request for the attribute. The entry in each cell is
- the name (first few words) of each item below 1, 2, 3, 4a-g, and
- 5.
-
-The allowed values include the following cases:
-
- 1. READ-ONLY: the Set-Printer-Attributes or Set-Job-Attributes
- operation MUST NOT change this attribute and MUST reject the entire
- operation (see section 7.1).
-
- 2. Any of "xxx-supported": the Set-Printer-Attributes or Set-Job-
- Attributes operation accepts values that are allowed according to
- the IPP/1.1 rules for validating the value(s) of an "xxx" Printer
- or Job attribute against the value(s) of the corresponding "xxx-
- supported" Printer attribute. Table 4 summarizes those validation
- rules depending on each attribute syntax and value of an "xxx"
- attribute supplied in the request and that of the corresponding
- "xxx-supported" Printer attribute. The "xxx-supported" attribute
- syntax type and value(s) are obtained from a Get-Printer-Supported-
- Values response (see the tables in this Appendix).
-
- Table 4 - Validation rules for 'Any of "xxx-supported" '
-
- Type of "xxx" value Type of "xxx- Validates if:
- to be set supported" value
-
- integer rangeOfInteger each value is in one of
- the "xxx-supported"
- ranges
- uri uriScheme each uri scheme matches
- one of the "xxx-
- supported" schemes
- any boolean if the boolean "xxx-
- supported" is 'true'
- any same type each value matches an
- "xxx-supported" value
- of the same type
-
-
- For additional non-normative explanatory information see section
- 3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's
- Guide" [ipp-iig]).
-
- 3. From Get-Printer-Supported-Values: the Set-Printer-Attributes
- operation accepts values that are allowed according to the IPP/1.1
- rules for validating the value(s) of an "xxx" Printer attribute
- against the value(s) of the corresponding "xxx-supported" Printer
- attribute. Table 5 summarizes those validation rules depending on
-
-Hastings, Herriot, Kugler, Lewis [Page 42]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- each attribute syntax and value of an "xxx" attribute supplied in
- the request and that of the corresponding "xxx-supported" Printer
- attribute. The "xxx-supported" attribute syntax type and attribute
- value(s) are obtained from a Get-Printer-Supported-Values response
- (see Appendix B: Attributes returned from Get-Printer-Supported-
- Values below).
-
- Table 5 - Validation rules for 'From Get-Printer-Supported-Values'
-
- Type of "xxx" value Type of "xxx- Validates if:
- to be set supported" value
-
- integer rangeOfInteger each 'integer' value is
- in one of the "xxx-
- supported" ranges
- uri uriScheme the uri scheme of each
- value matches one of
- the "xxx-supported"
- schemes
- any boolean if the boolean "xxx-
- supported" is 'true'
- name 'admin-define' out- any 'name' value
- of-band value matches
- any same type each value matches an
- "xxx-supported" value
- of the same type
-
-
- For additional non-normative explanatory information see section
- 3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's
- Guide" [ipp-iig]).
-
- 4. Any value of the proper attribute syntax: the Set-Printer-
- Attributes or Set-Job-Attributes operation accepts any value of the
- specified attribute syntax. The attribute syntaxes supported are
- enumerated below.
-
- a.Any text(127)
- b.Any name(127)
- c.Any uri
- d.Any boolean
- e.Any positive integer
- f.Any dateTime
- g.1setOf any uri
-
- 5. Combination of 'Any of "xxx-supported"' or 'Any name'.
-
-If a Printer implementation doesn't want to allow setting values
-indicated in this Appendix as "any xxx", it can make the value be not-
-settable.
-
- Table 6 - Values allowed for Job Template Attributes in the Set-Job-
- Attributes Operation
-
-Job Template Attributes Values allowed for Set
-
-job-priority (integer(1:100)) Any of "xxx-supported"
-
-
-Hastings, Herriot, Kugler, Lewis [Page 43]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Job Template Attributes Values allowed for Set
-
-job-hold-until (type3 keyword | name (MAX)) Any of "xxx-supported"
-job-sheets (type3 keyword | name(MAX)) Any of "xxx-supported"
-multiple-document-handling (type2 keyword) Any of "xxx-supported"
-copies (integer(1:MAX)) Any of "xxx-supported"
-finishings (1setOf type2 enum) Any of "xxx-supported"
-page-ranges (1setOf rangeOfInteger (1:MAX)) Any of "xxx-supported"
-sides (type2 keyword) Any of "xxx-supported"
-number-up (integer(1:MAX)) Any of "xxx-supported"
-orientation-requested (type2 enum) Any of "xxx-supported"
-media (type3 keyword | name(MAX)) Any of "xxx-supported"
-printer-resolution (resolution) Any of "xxx-supported"
-print-quality (type2 enum) Any of "xxx-supported"
-
-
-Table 7 - Values allowed for Job Description Attributes in the Set-Job-
- Attributes Operation
-
-Job Description Attributes Values allowed
- for Set
-job-uri (uri) READ-ONLY
-job-id (integer(1:MAX)) READ-ONLY
-job-printer-uri (uri) READ-ONLY
-job-more-info (uri) READ-ONLY
-job-name (name(MAX)) Any name(MAX)
-job-originating-user-name (name(MAX)) READ-ONLY
-job-state (type1 enum) READ-ONLY
-job-state-reasons (1setOf type2 keyword) READ-ONLY
-job-state-message (text(MAX)) READ-ONLY
-job-detailed-status-messages (1setOf text(MAX)) READ-ONLY
-job-document-access-errors (1setOf text(MAX)) READ-ONLY
-number-of-documents (integer(0:MAX)) READ-ONLY
-output-device-assigned (name(127)) READ-ONLY
-time-at-creation (integer(MIN:MAX)) READ-ONLY
-time-at-processing (integer(MIN:MAX)) READ-ONLY
-time-at-completed (integer(MIN:MAX)) READ-ONLY
-job-printer-up-time (integer(1:MAX)) READ-ONLY
-date-time-at-creation (dateTime) READ-ONLY
-date-time-at-processing (dateTime) READ-ONLY
-date-time-at-completed (dateTime) READ-ONLY
-number-of-intervening-jobs (integer(0:MAX)) READ-ONLY
-job-message-from-operator (text(127)) Any text(127)
-job-k-octets (integer(0:MAX)) READ-ONLY
-job-impressions (integer(0:MAX)) READ-ONLY
-job-media-sheets (integer(0:MAX)) READ-ONLY
-job-k-octets-processed (integer(0:MAX)) READ-ONLY
-job-impressions-completed (integer(0:MAX)) READ-ONLY
-job-media-sheets-completed (integer(0:MAX)) READ-ONLY
-attributes-charset (charset) READ-ONLY
-attributes-natural-language (naturalLanguage) READ-ONLY
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 44]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Table 8 - Values allowed for Printer Job Template Attributes in the Set-
- Printer-Attributes Operation
-
-Printer Job Template Attributes Values allowed for Set
-
-job-priority-default (integer(1:100)) Any of "xxx-supported"
-job-hold-until-default (type3 keyword | Any of "xxx-supported"
-name (MAX))
-job-sheets-default (type3 keyword | Any of "xxx-supported"
-name(MAX))
-multiple-document-handling-default (type2 Any of "xxx-supported"
-keyword)
-copies-default (integer(1:MAX)) Any of "xxx-supported"
-finishings-default (1setOf type2 enum) Any of "xxx-supported"
-sides-default (type2 keyword) Any of "xxx-supported"
-number-up-default (integer(1:MAX)) Any of "xxx-supported"
-orientation-requested-default (type2 enum) Any of "xxx-supported"
-media-default (type3 keyword | name(MAX)) Any of "xxx-supported"
-printer-resolution-default (resolution) Any of "xxx-supported"
-print-quality-default (type2 enum) Any of "xxx-supported"
-job-priority-supported (integer(1:100)) From Get-Printer-
- Supported-Values
-job-hold-until-supported (1setOf(type3 From Get-Printer-
-keyword | name (MAX))) Supported-Values
-job-sheets-supported (1setOf(type3 keyword From Get-Printer-
-| name(MAX))) Supported-Values
-multiple-document-handling-supported From Get-Printer-
-(1setOf type2 keyword) Supported-Values
-copies-supported (rangeOfInteger(1:MAX)) From Get-Printer-
- Supported-Values
-finishings-supported (1setOf type2 enum) From Get-Printer-
- Supported-Values
-page-ranges-supported (boolean) From Get-Printer-
- Supported-Values
-sides-supported (1setOf type2 keyword) From Get-Printer-
- Supported-Values
-number-up-supported (1setOf (integer(1:MAX) From Get-Printer-
-| rangeOfInteger(1:MAX))) Supported-Values
-orientation-requested-supported (1setOf From Get-Printer-
-type2 enum) Supported-Values
-media-supported (1setOf (type3 keyword | From Get-Printer-
-name(MAX))) Supported-Values
-printer-resolution-supported (1setOf From Get-Printer-
-resolution) Supported-Values
-print-quality-supported (1setOf type2 enum) From Get-Printer-
- Supported-Values
-media-ready (type3 keyword | name(MAX)) From Get-Printer-
- Supported-Values
-
-
-Table 9 - Values allowed for Printer Description Attributes in the Set-
- Printer-Attributes Operation
-
-Printer Description Attributes Values allowed for
- Set
-
-
-Hastings, Herriot, Kugler, Lewis [Page 45]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Printer Description Attributes Values allowed for
- Set
-printer-uri-supported (1setOf uri) READ-ONLY
-uri-authentication-supported (1setOf type2 READ-ONLY
-keyword)
-uri-security-supported (1setOf type2 keyword) READ-ONLY
-printer-xri-supported (1setOf collection)
-member attributes:
- xri-uri (uri) any uriScheme of
- "xri-uri-scheme-
- supported" from Get-
- Printer-Attributes
- xri-authentication (1setOf type2 keyword) any keyword of "xri-
- authentication-
- supported" from Get-
- Printer-Attributes
- xri-security (1setOf type2 keyword) any keyword of "xri-
- security-supported"
- from Get-Printer-
- Attributes
-xri-uri-scheme-supported (1setOf uriScheme) READ-ONLY
-xri-authentication-supported (1setOf type2 READ-ONLY
-keyword)
-xri-security-supported (1setOf type2 keyword) READ-ONLY
-printer-name (name(127)) Any name(127)
-printer-location (text(127)) Any text(127)
-printer-info (text(127)) Any text(127)
-printer-more-info (uri) Any uri
-printer-driver-installer (uri) Any uri
-printer-make-and-model (text(127)) Any text(127)
-printer-more-info-manufacturer (uri) Any uri
-printer-state (type1 enum) READ-ONLY
-printer-state-reasons (1setOf type2 keyword) READ-ONLY
-printer-state-message (text(MAX)) READ-ONLY
-ipp-versions-supported (1setOf type2 keyword) From Get-Printer-
- Supported-Values
-operations-supported (1setOf type2 enum) From Get-Printer-
- Supported-Values
-multiple-document-jobs-supported (boolean) From Get-Printer-
- Supported-Values
-charset-configured (charset) Any of "xxx-
- supported", use
- "charset-supported"
-charset-supported (1setOf charset) From Get-Printer-
- Supported-Values
-natural-language-configured (naturalLanguage) Any of "xxx-
- supported", use
- "generated-natural-
- language-supported"
-generated-natural-language-supported (1setOf From Get-Printer-
-naturalLanguage) Supported-Values
-document-format-default (mimeMediaType) Any of "xxx-
- supported"
-document-format-supported (1setOf From Get-Printer-
-
-Hastings, Herriot, Kugler, Lewis [Page 46]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Printer Description Attributes Values allowed for
- Set
-mimeMediaType) Supported-Values
-printer-is-accepting-jobs (boolean) READ-ONLY
-queued-job-count (integer(0:MAX)) READ-ONLY
-printer-message-from-operator (text(127)) Any text(127)
-color-supported (boolean) From Get-Printer-
- Supported-Values
-reference-uri-schemes-supported (1setOf From Get-Printer-
-uriScheme) Supported-Values
-pdl-override-supported (type2 keyword) From Get-Printer-
- Supported-Values
-printer-up-time (integer(1:MAX)) READ-ONLY
-printer-current-time (dateTime) Any dateTime **
-multiple-operation-time-out (integer(1:MAX)) any positive integer
-compression-supported (1setOf type3 keyword) From Get-Printer-
- Supported-Values
-job-k-octets-supported (rangeOfInteger(0:MAX)) From Get-Printer-
- Supported-Values
-job-impressions-supported From Get-Printer-
-(rangeOfInteger(0:MAX)) Supported-Values
-job-media-sheets-supported From Get-Printer-
-(rangeOfInteger(0:MAX)) Supported-Values
-pages-per-minute (integer(0:MAX)) READ-ONLY
-pages-per-minute-color (integer(0:MAX)) READ-ONLY
-printer-settable-attributes-supported (1setOf From Get-Printer-
-type2 keyword) Supported-Values
-job-settable-attributes-supported (1setOf type2 From Get-Printer-
-keyword) Supported-Values
-document-format-varying-attributes (1setOf READ-ONLY
-type2 keyword)
-printer-message-time (integer(MIN:MAX)) READ-ONLY
-printer-message-date-time(dateTime) READ-ONLY
-
-** - The "printer-current-time" (dateTime) attribute is settable in
-order to allow an administrator to correct an incorrect dateTime or time
-zone.
-
-
-17 Appendix B: Attributes returned from Get-Printer-Supported-Values
-
-
-This Appendix is a normative part of this document and lists all the
-attributes that are possible for an implementation to return in a Get-
-Printer-Supported-Values response, i.e., all the "xxx-supported"
-attributes that can be supplied in a Set-Printer-Attributes request.
-READ-ONLY attributes MUST NOT be returned in a Get-Printer-Supported-
-Values response and are indicated in the tables as "READ-ONLY - MUST NOT
-be returned."
-
-For the following attributes, the value allowed by the Set-Printer-
-Attributes operation MUST be a single integer value in the range
-specified by the value returned by the Get-Printer-Supported-Values
-operation.
-
-
-Hastings, Herriot, Kugler, Lewis [Page 47]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
- Table 10 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values
-
-Printer Job Template Attributes Values Returned
-
-job-priority-supported (integer(1:100)) rangeOfInteger(1:100)
-
-
-For the following attributes, the value allowed by the Set-Printer-
-Attributes operation MUST be a single rangeOfInteger value whose bounds
-do not exceed those of the range specified by the value returned by the
-Get-Printer-Supported-Values operation.
-
- Table 11 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values
-
-Printer Job Template Attributes Values Returned
-
-copies-supported (rangeOfInteger(1:MAX)) rangeOfInteger(1:MAX)
-
-
-
-The following table has the same criteria as the last, but is for
-Printer Description attributes.
-
- Table 12 - Printer Description Attributes returned from Get-Printer-
- Supported-Values
-
-Printer Description Attributes Values allowed for Set
-
-job-k-octets-supported rangeOfInteger(0:MAX)
-(rangeOfInteger(0:MAX))
-job-impressions-supported rangeOfInteger(0:MAX)
-(rangeOfInteger(0:MAX))
-job-media-sheets-supported rangeOfInteger(0:MAX)
-(rangeOfInteger(0:MAX))
-
-
-For the following attributes, the value allowed by the Set-Printer-
-Attributes operation MUST be one or more integers and rangeOfInteger
-values, such that the integer values described by these integers and
-rangeOfInteger is the same as or a subset of the integers described by
-the integers and rangeOf Integer of value returned by the Get-Printer-
-Supported-Values operation.
-
- Table 13 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values
-
-Printer Job Template Attributes Values Returned
-
-number-up-supported (1setOf (integer(1:MAX) 1setOf (integer(1:MAX) |
-| rangeOfInteger(1:MAX))) rangeOfInteger(1:MAX))
-
-
-For the following attributes, the value allowed by the Set-Printer-
-Attributes operation MUST be one or more values, where each such value
-matches a value returned by the Get-Printer-Supported-Values operation.
-A keyword, enum, boolean, charset, naturalLanguage, uriScheme,
-
-Hastings, Herriot, Kugler, Lewis [Page 48]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-mimeMediaType or resolution value matches if it is equal. For Job
-Template attributes with the attribute syntax 'type3 keyword | name',
-any 'name' attribute syntax value matches the 'admin-define' out-of-band
-value, if the implementation allows the administrator to set any name
-values for the attribute.
-
- Table 14 - Printer Job Template Attributes returned from Get-Printer-
- Supported-Values
-
-Printer Job Template Attributes Values Returned
-
-job-hold-until-supported (1setOf(type3 1setOf (type3 keyword |
-keyword | name (MAX))) 'admin-define')
-job-sheets-supported (1setOf(type3 keyword 1setOf (type3 keyword |
-| name(MAX))) 'admin-define')
-multiple-document-handling-supported 1setOf type2 keyword
-(1setOf type2 keyword)
-finishings-supported (1setOf type2 enum) 1setOf type2 enum
-page-ranges-supported (boolean) 1setOf boolean **
-sides-supported (1setOf type2 keyword) 1setOf type2 keyword
-orientation-requested-supported (1setOf 1setOf type2 enum
-type2 enum)
-media-supported (1setOf (type3 keyword | 1setOf (type3 keyword |
-name(MAX))) 'admin-define')
-printer-resolution-supported (1setOf 1setOf resolution
-resolution)
-print-quality-supported (1setOf type2 enum) 1setOf type2 enum
-
-** Note: the Get-Printer-Supported-Values returns a '1setOf boolean' so
-that all possible values are indicated, while Get-Printer-Attributes
-returns only a single 'boolean' value.
-
-The following table has the same criteria as the last, but is for
-Printer Description attributes.
-
- Table 15 - Printer Description Attributes returned from Get-Printer-
- Supported-Values
-
-Printer Description Attributes Values allowed for Set
-
-printer-uri-supported (1setOf uri) READ-ONLY - MUST NOT be
- returned
-uri-authentication-supported (1setOf type2 READ-ONLY - MUST NOT be
-keyword) returned
-uri-security-supported (1setOf type2 READ-ONLY - MUST NOT be
-keyword) returned
-xri-printer-supported (1setOf collection) MUST NOT be returned;
- see next three
- attributes returned with
- Get-Printer-Attributes:
-xri-uri-scheme-supported (1setOf uriScheme) READ-ONLY - MUST NOT be
- returned
-xri-authentication-supported (1setOf type2 READ-ONLY - MUST NOT be
-keyword) returned
-xri-security-supported (1setOf type2 READ-ONLY - MUST NOT be
-
-
-Hastings, Herriot, Kugler, Lewis [Page 49]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-Printer Description Attributes Values allowed for Set
-
-keyword) returned
-ipp-versions-supported (1setOf type2 1setOf type2 keyword
-keyword)
-operations-supported (1setOf type2 enum) 1setOf type2 keyword
-multiple-document-jobs-supported (boolean) 1setOf boolean **
-charset-supported (1setOf charset) 1setOf charset
-generated-natural-language-supported 1setOf naturalLanguage
-(1setOf naturalLanguage)
-document-format-supported (1setOf 1setOf mimeMediaType
-mimeMediaType)
-color-supported (boolean) 1setOf boolean **
-reference-uri-schemes-supported (1setOf 1setOf uriScheme
-uriScheme)
-pdl-override-supported (type2 keyword) 1setOf type2 keyword **
-compression-supported (1setOf type3 1setOf type3 keyword
-keyword)
-printer-settable-attributes-supported 1setOf type2 keyword
-(1setOf type2 keyword)
-job-settable-attributes-supported (1setOf 1setOf type2 keyword
-type2 keyword)
-
-** Note: the Get-Printer-Supported-Values returns a '1setOf X' so that
-all possible values are indicated, while Get-Printer-Attributes returns
-only a single 'X' value.
-
-
-
-
-18 Appendix C: Full Copyright Statement
-
-
-Copyright (C) The Internet Society (1998,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
-
-
-Hastings, Herriot, Kugler, Lewis [Page 50]
- Expires: September 23, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Job and Printer Set Operations March 23, 2000
-
-
-INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, Herriot, Kugler, Lewis [Page 51]
- Expires: September 23, 2000
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT T. Hastings
+<draft-ietf-ipp-job-printer-set-ops-03.txt> R. Herriot
+Category: standards track Xerox Corporation
+ Carl Kugler
+ H. Lewis
+ IBM Corporation
+ January 22, 2001
+
+ Internet Printing Protocol (IPP):
+ Job and Printer Set Operations
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+
+Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+
+ This document specifies 3 additional OPTIONAL operations for use with
+ the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], IPP/1.1
+ [RFC2911, RFC2910], and future versions. The end user, operator, and
+ administrator Set-Job-Attributes and Set-Printer-Attributes
+ operations are used to modify IPP Job objects and Printer objects,
+ respectively. The third administrator Get-Printer-Supported-Values
+ operation returns values that the IPP Printer will accept for setting
+ its "xxx-supported" attributes.
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 1]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Three out-of-band values are defined for use with these operations:
+ 'delete-attribute', 'admin-define', and 'not-settable', along with a
+ 'client-error-attributes-not-settable' status code.
+
+
+ Two operation attributes: "printer-message-from-operator" (text) and
+ "job-message-from-operator" (text) are defined to set the
+ corresponding IPP/1.1 Printer and Job Description attributes with the
+ same names.
+
+ Nine Printer Description attributes are defined:
+ printer-settable-attributes-supported (1setOf type2 keyword)
+ job-settable-attributes-supported (1setOf type2 keyword)
+ document-format-varying-attributes (1setOf type2 keyword)
+ printer-message-time (integer(MIN:MAX))
+ printer-message-date-time (dateTime)
+ printer-xri-supported (1setOf collection)
+ xri-uri-scheme-supported (1setOf uriScheme)
+ xri-authentication-supported (1setOf type2 keyword)
+ xri-security-supported (1setOf type2 keyword)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 2]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
+ Mapping between LPD and IPP Protocols [RFC2569]
+
+
+ The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that
+ are satisfied in IPP/1.0. A few OPTIONAL operator operations have
+ been added to IPP/1.1.
+
+
+ The "Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol" document describes IPP from a high level
+ view, defines a roadmap for the various documents that form the suite
+ of IPP specification documents, and gives background and rationale
+ for the IETF working group's major decisions.
+
+
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1 [RFC2616]. It defines the
+ encoding rules for a new Internet MIME media type called
+ "application/ipp". This document also defines the rules for
+ transporting over HTTP a message body whose Content-Type is
+ "application/ipp". This document defines a new scheme named 'ipp'
+ for identifying IPP printers and jobs.
+
+
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 3]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 4]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+Table of Contents
+
+
+ 1 Introduction....................................................8
+
+ 2 Terminology.....................................................8
+ 2.1 Conformance Terminology......................................9
+ 2.2 Other terminology............................................9
+
+ 3 Requirements and Use Cases......................................9
+
+ 4 Definition of the Set operations...............................10
+ 4.1 Set-Printer-Attributes Operation............................11
+ 4.1.1 Settable and READ-ONLY Printer Description attributes.....13
+ 4.1.2 Set-Printer-Attributes Request............................15
+ 4.1.3 Set-Printer-Attributes Response...........................16
+ 4.2 Set-Job-Attributes Operation................................18
+ 4.2.1 Settable and READ-ONLY Job Description attributes.........21
+ 4.2.2 Set-Job-Attributes Request................................21
+ 4.2.3 Set-Job-Attributes Response...............................22
+ 4.3 Get-Printer-Supported-Values Operation......................24
+ 4.3.1 Definition of the usage of the 'admin-define' out-of-band
+ attribute value...................................................25
+
+ 5 New Operation attributes.......................................27
+ 5.1 printer-message-from-operator (text(127))...................27
+ 5.2 job-message-from-operator (text(127)).......................28
+
+ 6 New Printer Description Attributes.............................29
+ 6.1 printer-settable-attributes-supported (1setOf type2 keyword)29
+ 6.2 job-settable-attributes-supported (1setOf type2 keyword)....30
+ 6.3 document-format-varying-attributes (1setOf type2 keyword)...30
+ 6.4 printer-message-time (integer(MIN:MAX)).....................31
+ 6.5 printer-message-date-time (dateTime)........................31
+ 6.6 printer-xri-supported (1setOf collection)...................32
+ 6.7 xri-uri-scheme-supported (1setOf uriScheme).................34
+ 6.8 xri-authentication-supported (1setOf type2 keyword).........35
+ 6.9 xri-security-supported (1setOf type2 keyword)...............35
+
+ 7 Additional status codes........................................35
+ 7.1 'client-error-attributes-not-settable' (0x0413).............35
+
+ 8 Additional out-of-band values..................................36
+ 8.1 'not-settable' out-of-band value............................36
+ 8.1.1 Encoding of the 'not-settable' out-of-band attribute value37
+ 8.2 'delete-attribute' out-of-band value........................37
+ 8.2.1 Encoding of the 'delete-attribute' out-of-band value......37
+ 8.3 'admin-define' out-of-band attribute value..................38
+ 8.3.1 Encoding of the 'admin-define' out-of-band attribute value39
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 5]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ 9 Conformance Requirements.......................................39
+
+ 10 IANA Considerations............................................41
+ 10.1 Operation Registrations.....................................41
+ 10.2 Attribute Registrations.....................................41
+ 10.3 Status code Registrations...................................42
+ 10.4 Out-of-band Attribute Value Registrations...................42
+
+ 11 Internationalization Considerations............................43
+
+ 12 Security Considerations........................................43
+
+ 13 Author's Addresses.............................................44
+
+ 14 References.....................................................45
+
+ 15 Appendix A: Allowed Values for Set-Printer-Attributes and Set-Job-
+ Attributes requests...............................................46
+
+ 16 Appendix B: Attributes returned from Get-Printer-Supported-Values
+ 60
+
+ 17 Appendix C: Full Copyright Statement...........................65
+
+
+ Table of Tables
+
+ Table 1 - Operation-Id assignments................................11
+ Table 2 - Job State Transition Table for the Set-Job-Attributes
+ operation .....................................................20
+ Table 3 - Member attributes of "printer-xri-supported" (1setOf
+ collection) ...................................................33
+ Table 4 - Validation rules for 'Any of "xxx-supported" '..........47
+ Table 5 - Validation rules for 'From Get-Printer-Supported-Values'48
+ Table 6 - Values allowed for Job Template Attributes in the Set-Job-
+ Attributes Operation ..........................................50
+ Table 7 - Values allowed for Job Description Attributes in the Set-
+ Job-Attributes Operation ......................................52
+ Table 8 - Values allowed for Printer Job Template Attributes in the
+ Set-Printer-Attributes Operation ..............................54
+ Table 9 - Values allowed for Printer Description Attributes in the
+ Set-Printer-Attributes Operation ..............................57
+ Table 10 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values ..............................................61
+ Table 11 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values ..............................................61
+ Table 12 - Printer Description Attributes returned from Get-Printer-
+ Supported-Values ..............................................62
+ Table 13 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values ..............................................62
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 6]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 14 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values ..............................................63
+ Table 15 - Printer Description Attributes returned from Get-Printer-
+ Supported-Values ..............................................64
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 7]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+1 Introduction
+
+
+ The Internet Printing Protocol (IPP) is an application level protocol
+ that can be used for distributed printing using Internet tools and
+ technologies. IPP version 1.1 [RFC2911, RFC2910] focuses on end user
+ functionality with a few administrative operations included. This
+ document defines additional OPTIONAL end user, operator, and
+ administrator Set-Job-Attributes and Set-Printer-Attributes
+ operations used to modify IPP Job objects and Printer objects,
+ respectively. It also defines a third administrator Get-Printer-
+ Supported-Values operation that returns values that the IPP Printer
+ will accept for setting its "xxx-supported" attributes. The Get-
+ Printer-Supported-Values operation MUST be supported, if the
+ implementation supports setting any "xxx-supported" Printer
+ attributes using the Set-Printer-Attributes operation.
+
+
+ Three out-of-band values are defined for use with these three
+ operations: 'delete-attribute' for deleting Job attributes with the
+ Set-Job-Attributes request, 'not-settable' for use in either the Set-
+ Job-Attributes or Set-Printer-Attributes responses, and 'admin-
+ define' for use in the Get-Printer-Supported-Values response.
+
+
+ Two operation attributes: "printer-message-from-operator" (text) and
+ "job-message-from-operator" (text) are defined to set the
+ corresponding IPP/1.1 Printer and Job Description attributes with the
+ same names. These operation attributes may be used with any
+ operation that affect the Printer or Job object for which an
+ operation might want to indicate a message. For the Set-Job-
+ Attributes and Set-Printer-Attributes operations, the client MUST
+ explicitly set them, rather than using these operation attributes.
+
+
+ A Printer implementation can make the value of some attributes
+ dependent on the document-format, e.g. "resolution-supported".
+
+
+ This document is an extension to IPP/1.0 [RFC2565, RFC2566] and
+ IPP/1.1 [RFC2911, RFC2910], and future versions.
+
+
+
+2 Terminology
+
+ This section defines terminology used throughout this document.
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 8]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+2.1 Conformance Terminology
+
+
+ Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+ NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+ conformance. These terms are defined in [RFC2911] section 12.1 on
+ conformance terminology, most of which is taken from RFC 2119
+ [RFC2119].
+
+
+ The following specialization of these terms apply to this document:
+
+ REQUIRED: if an implementation supports the extensions described in
+ this document, it MUST support a REQUIRED feature.
+ OPTIONAL: if an implementation supports the extensions described in
+ this document, it MAY support an OPTIONAL feature.
+
+2.2 Other terminology
+
+
+ This document uses terms such as Job object (or Job), IPP Printer
+ object (or Printer), "operation", "request", response", "attributes",
+ "keywords", and "support". These terms have special meaning and are
+ defined in the model terminology [RFC2911] section 12.2. The
+ following additional terms are introduced in this document:
+
+ READ-ONLY: used in an attribute definition document to indicate that
+ the attribute MUST NOT be settable using an IPP protocol Set
+ operation. In other words, the attribute is not settable by
+ definition.
+ not-settable: an implementation does not support setting an
+ attribute (whether or not the attribute's definition is READ-ONLY).
+
+
+3 Requirements and Use Cases
+
+
+ The following requirements and usage are intended to be met by the
+ specification in this document.
+
+
+ 1. The end-user and the operator need a way to modify a Job that is in
+ the 'pending' or 'pending-held' state.
+
+
+ Usage: The end-user discovers that he/she forgot to include a
+ print instruction, such as "finishings" = 'staple' after submitting
+ a job. Rather than canceling the job and resubmitting it to the
+ same IPP Printer, the end-user is able to modify the job on the IPP
+ Printer.
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 9]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ The operator needs to modify a job because it is requesting a
+ particular kind of media for which there is no more, but the policy
+ is to print the job on a comparable medium.
+
+
+ 2. The system administrator needs a way to re-configure or change the
+ policy of the IPP Printer remotely.
+
+
+ Usage: The system administrator is adding additional named media
+ to the supported media list (setting 'name' values to the "media-
+ supported" Printer attribute).
+
+
+ The system administrator is reducing the capability of the IPP
+ Printer by removing one of the operations from the supported
+ operations list, such as Cancel-Job, because the policy is to run
+ the IPP Printer like a public facsimile machine. After having
+ removed Cancel-Job from the list of supported operations, an
+ administrative client needs to be able to display to an
+ administrator that the implementation is capable of being
+ reconfigured to support Cancel-Job once again.
+
+
+ The system administrator is remotely configuring the IPP Printer
+ after installing it, and so is replacing the Printer Description
+ attributes that have the out-of-band 'no-value' value (see
+ [RFC2911] section 4.1) with the proper values.
+
+
+ The operator is changing the media loaded in the input tray and so
+ is replacing the "media-ready" Job Template Printer attribute value
+ with the proper values
+
+
+
+4 Definition of the Set operations
+
+
+ The Set-Printer-Attributes operation (as are all Printer operations)
+ are directed at Printer objects. A client MUST always supply the
+ "printer-uri" operation attribute in order to identify the correct
+ target of the operation. These descriptions assume all of the common
+ semantics of IPP/1.1 Model and Semantics document [RFC2911] section
+ 3.1.
+
+
+ The Set-Job-Attributes operation (as are all Job operations) are
+ directed at Job objects. A client MUST always supply some means of
+ identifying the Job object in order to identify the correct target of
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 10]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ the operation. That job identification MAY either be a single Job
+ URI or a combination of a Printer URI with a Job ID as defined in
+ [RFC2911]. The IPP object implementation MUST support both forms of
+ identification for every job. If possible, a client SHOULD use the
+ Printer URI with a Job ID rather than a Job URI, since the 32-bit
+ "job-id" is more readily translated to and from other print protocols
+ that MAY be serving as gateways into or out of the IPP
+ implementation.
+
+
+ The Set Printer operations are summarized in Table 1:
+
+ Table 1 - Operation-Id assignments
+
+
+
+ Operation Name Operation Brief description
+ -Id
+
+
+ Set-Printer- 0x0013 Sets attribute values of the target
+ Attributes Printer object
+
+ Set-Job-Attributes 0x0014 Sets attribute values of the target
+ Job object
+
+ Get-Printer- 0x0015 Gets values that are valid for
+ Supported-Values setting "xxx-supported" attributes
+ using the Set-Printer-Attributes
+ operation
+
+
+4.1 Set-Printer-Attributes Operation
+
+
+ This OPTIONAL operation allows a client to set the values of the
+ attributes of a Printer object. In the request, the client supplies
+ the set of Printer keyword attribute names and values that are to be
+ set. In the response, the Printer object returns success or rejects
+ the entire request with indications of which attribute or attributes
+ could not be set.
+
+
+ The Printer object validates the client-supplied attributes in the
+ Set-Printer-Attributes request. For an attribute to validate it MUST
+ meet all of the following rules:
+
+
+ 1. The number of attributes supplied by the client MUST NOT exceed the
+ maximum number that the Printer supports in a Set-Printer-
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 11]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Attributes request. A Printer MUST accept at least one attribute,
+ but SHOULD accept a reasonable number in a single Set-Printer-
+ Attributes request.
+
+
+ Note: There is no way for the client to determine the maximum
+ number of attributes that the Printer supports in a Set-Printer-
+ Attributes request, except to try a reasonable number.
+
+
+ 2. The Printer MUST support the attribute.
+
+
+ 3. The attribute MUST NOT be READ-ONLY, i.e., the definition of the
+ attribute MUST NOT indicate that the attribute is READ-ONLY (see
+ Appendix A for an indication of which IPP/1.1 attributes are READ-
+ ONLY).
+
+
+ 4. The attribute MUST be settable in this implementation.
+
+
+ 5. The Printer MUST support the value according to the rules defined
+ in Appendix A, i.e., each value of each supplied "xxx" attribute
+ MUST be validated against a value of a corresponding "xxx-
+ supported" Printer attribute. One of those rules permits an
+ administrator to set arbitrary 'name' values to those "xxx-
+ supported" Printer attributes that include the 'name' attribute
+ syntax if the implementation supports the 'admin-define' out-of-
+ band value for that "xxx-supported" attribute (see section 15 and
+ 8.3).
+
+
+ 6. The attribute's values MUST NOT conflict with the values of other
+ Printer attributes, including ones being set in this same
+ operation.
+
+
+ If any of the supplied attributes does not validate, the Printer
+ object MUST reject the entire operation; the Printer object MUST NOT
+ partially set some of the supplied attributes. In other words, after
+ the operation, all the supplied attributes MUST be set or none of
+ them MUST be set, thus making the Set-Printer-Attributes an atomic
+ operation.
+
+
+ The Printer MUST accept this operation when its READ-ONLY "printer-
+ state" attribute (see RFC2911] section 4.4.11) is 'idle' or
+ 'stopped', and SHOULD accept it when the value is 'processing'. The
+ Printer MUST accept this operation for any of the values of the
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 12]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Printer object's READ-ONLY "printer-state-reasons" and "printer-is-
+ accepting-jobs" attributes, unless explicitly defined otherwise in
+ the definition of these attributes' values.
+
+
+ This operation MUST NOT change the value of attributes not specified
+ in the operation unless the definition of the attribute explicitly
+ specifies such side-effects. For example, this document explicitly
+ specifies that when this operation sets "printer-message-from-
+ operator", the Printer also MUST set the READ-ONLY "printer-message-
+ time" and READ-ONLY "printer-message-date-time" attributes to the
+ time of the operation as a side effect . In particular, if this
+ operation changes an "xxx-default" attribute, the new value MUST be
+ in the "xxx-supported" attribute or the request MUST contain a new
+ value for "xxx-supported" which contains the new value for the "xxx-
+ default". Otherwise, the Printer MUST reject the operation. In
+ general, Printer attribute definitions that are settable will not
+ define side-effects on other attributes that are settable, only side
+ effects on READ-ONLY attributes, if any.
+
+
+4.1.1 Settable and READ-ONLY Printer Description attributes
+
+
+ If the Printer supports the Set-Printer-Attributes operation, then it
+ SHOULD support setting of:
+
+
+ all Job Template Default ("xxx-default") attributes
+
+ all Job Template Supported ("xxx-supported") attributes
+
+ all Job Template Ready ("xxx-ready") attributes
+
+ that the implementation supports (see [RFC2911] section 4.2 and
+ extensions).
+
+
+ Some Printer Description attributes (see [RFC2911] section 4.4) MUST
+ NOT be settable, i.e., they are defined to be READ-ONLY. An
+ attribute marked as "READ-ONLY" in the Printer Description attribute
+ table in Appendix A is such an attribute. The Printer attributes
+ that are not marked as "READ-ONLY" MAY be settable using the Set-
+ Printer-Attributes operation, depending on implementation.
+
+
+ Note: From now on, all extensions that define new object attributes
+ will indicate whether or not the attributes are READ-ONLY, by
+ including the "READ-ONLY" adjective in their descriptions and/or
+ explicitly stating whether they MAY be settable.
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 13]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ The current values of each "xxx-supported" Printer attribute MUST
+ reflect the current policy for support of the corresponding "xxx"
+ attribute. If an "xxx-supported" Printer attribute is settable in an
+ implementation, then its value(s) MUST affect the behavior of the
+ implementation. If an "xxx-supported" Printer attribute is defined
+ to be READ-ONLY or is not-settable in an implementation, then its
+ values MUST NOT be settable using the Set-Printer-Attributes
+ operation. Consider the following example:
+
+
+ For example, if the "operations-supported" Printer Description
+ attribute (see [RFC2911] section 4.4.15) is settable in a
+ particular implementation, then changing its value with a Set-
+ Printer-Attributes operation MUST affect the operations that the
+ implementation accepts or rejects. Such an implementation will
+ need to be able to reject values for operations that it contains no
+ code support for (see section 4.3). If the "operations-supported"
+ Printer Description attribute is not settable in a particular
+ implementation, then that implementation MUST reject an attempt to
+ set it with a Set-Printer-Attributes operation, return the 'client-
+ error-attributes-not-settable' status code (see section 7.1), and
+ return the "operations-supported" attribute with the out-of-band
+ 'not-settable' value in the Unsupported Attributes Group.
+
+
+ As another example, consider an implementation in which the "media-
+ default" and "media-supported" are settable. If a client supplies
+ a Set-Printer-Attributes request that contains the "media-default"
+ attribute with a value that is not a member of the Printer's
+ "media-supported" attribute, the Printer MUST reject the request
+ and return the "client-error-conflicting-attributes" status code
+ with the "media-default" and "media-supported" attributes and their
+ values (see [RFC2911] section 3.1.7).
+
+
+ As a third example, if a client supplies a Set-Printer-Attributes
+ request that contains both the "media-default" and the "media-
+ supported" attributes, but includes a value in the "media-default"
+ that is not a member of the supplied "media-supported" attribute,
+ the Printer MUST reject the request and return the "client-error-
+ conflicting-attributes" status code with the "media-default" and
+ "media-supported" attributes and their values (see [RFC2911]
+ section 3.1.7).
+
+
+ Access Rights: The authenticated user (see [RFC2911] section 8.3)
+ performing this operation must be an operator or administrator of the
+ Printer object (see [RFC2911] Sections 1 and 8.5). Most Printer
+ attributes will require administrator access rights to set, such as
+ "xxx-supported", while some will require operator access rights only,
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 14]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ such as "media-ready" and "printer-message-from-operator". Which
+ attributes require which access rights depends on implementation and
+ MAY depend on site policy.
+
+
+4.1.2 Set-Printer-Attributes Request
+
+
+ The following sets of attributes are part of the Set-Printer-
+ Attributes Request:
+
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.1.
+
+ Target:
+ The "printer-uri" (uri) operation attribute which is the target
+ for this operation as described in [RFC2911] section 3.1.5.
+
+ Requesting User Name:
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be
+ supplied by the client as described in [RFC2911] section 8.3.
+
+ "document-format" (mimeMediaType):
+ The client OPTIONALLY supplies this attribute. The Printer
+ object MUST support this attribute. This attribute is useful
+ for a client to select the document-format to which the
+ attribute modification should be applied. A Printer
+ implementation MAY allow some attributes to have different
+ values for each document format that it supports. See [RFC2911]
+ section 3.2.5.1 "Get-Printer-Attributes Request".
+
+ If the client includes this attribute, the Printer MUST change
+ the supplied attributes for the document format specified by
+ this attribute. If a supplied attribute is a member of the
+ "document-format-varying-attributes" (i.e., the attribute
+ varies by document format, see section 6.3), the Printer MUST
+ change the supplied attribute for the document format specified
+ by this attribute, but not for other document formats. If a
+ supplied attribute isn't a member of the "document-format-
+ varying-attributes" (i.e. it doesn't vary by document format),
+ the Printer MUST change the supplied attribute for all document
+ formats.
+
+ If the client omits this attribute, the Printer MUST change the
+ supplied attributes for all document formats whether or not
+ they vary by document-format.
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 15]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+ If the client supplies a value for the "document-format"
+ Operation attribute that is either 'application/octet-stream'
+ or not supported by the Printer, i.e., is not among the values
+ of the Printer object's "document-format-supported" attribute,
+ the Printer object MUST reject the operation and return the
+ 'client-error-document-format-not-supported' status code.
+ Note: the document-format 'application/octet-stream' is the
+ union of several document-formats (see [RFC2911] section
+ 3.2.5.1, Get-Printer-Attributes) and is not a true document-
+ format.
+
+
+ Group 2: Printer Attributes
+
+ The client MUST supply a set of Printer attributes with one or
+ more values (including explicitly allowed out-of-band values)
+ as defined in [RFC2911] section 4.2 Job Template Attributes
+ ("xxx-default", "xxx-supported", and "xxx-ready" attributes),
+ section 4.4 Printer Description Attributes, and any attribute
+ extensions supported by the Printer. The value(s) of each
+ Printer attribute supplied in Group 2 replaces the value(s) of
+ the corresponding Printer attribute on the target Printer
+ object. For attributes that can have multiple values (1setOf),
+ all values supplied by the client replace all values of the
+ corresponding Printer object attribute. If a Printer object
+ attribute had not been configured yet and so had the 'no-value'
+ out-of-band value (see [RFC2911] section 4.1), the supplied
+ value(s) replace the 'no-value' value.
+
+
+4.1.3 Set-Printer-Attributes Response
+
+
+ The Printer object returns the following sets of attributes as part
+ of the Get-Printer-Attributes Response:
+
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ In addition to the REQUIRED status code returned in every
+ response, the response OPTIONALLY includes a "status-message"
+ (text(255)) and/or a "detailed-status-message" (text(MAX))
+ operation attribute as described in [RFC2911] sections 13 and
+ 3.1.6.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2.
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 16]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes.
+
+ If some of the attributes in the operation fail to validate,
+ the Printer MUST reject the operation, MUST NOT change any
+ Printer attributes, and MUST return the indicated status code
+ below. In this group, the Printer MUST also return all
+ attributes that fail to validate. The following are the
+ reasons that an attribute fails to validate and the value
+ returned for the attribute, along with the indicated status
+ code and order of detection:
+
+ 1.The number of attributes supplied by the client exceeds the
+ maximum number that the Printer supports in a Set-Printer-
+ Attributes request: return the 'client-error-request-
+ entity-too-large' (see [RFC2911] section 13.1.4.9).
+
+
+ 2.The Printer doesn't support the attribute: return the
+ attribute with the "out-of-band" value 'unsupported' (see
+ [RFC2911] section 3.1.7 and [RFC2910]) and the 'client-
+ error-attributes-or-values-not-supported (see [RFC2911]
+ section 13.1.4.12).
+
+
+ 3.The attribute is either READ-ONLY (in its definition) or is
+ not-settable in this implementation: return the attribute
+ with the "out-of-band" value 'not-settable' (see section
+ 8.1) and the 'client-error-attributes-not-settable' status
+ code (see section 7.1).
+
+
+ 4.The Printer doesn't support the value: if the attribute in
+ the operation has a single value return it. If the
+ attribute in the operation is multi-valued, return only
+ those values in a 1setOf that are not supported. Return the
+ 'client-error-attributes-or-values-not-supported' status
+ code (see [RFC2911] section 13.1.4.12).
+
+
+ 5.The values of some of the supplied attributes conflict with
+ one another and/or other Printer attribute values not being
+ set: if the conflicting attribute in the operation has a
+ single value return the attribute and the value. If the
+ attribute in the operation is multi-valued, return only the
+ attribute and those values in a 1setOf that are conflicting
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 17]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ with other attributes. Return the 'client-error-
+ conflicting-attributes' status code (see [RFC2911] section
+ 13.1.4.15).
+
+
+4.2 Set-Job-Attributes Operation
+
+
+ This OPTIONAL operation allows a client to set the values of the
+ attributes of a Job object. In the request, the client supplies the
+ set of Job keyword attribute names and values that are to be set. In
+ the response, the IPP object returns success or rejects the entire
+ request with indications of which attribute or attributes could not
+ be set.
+
+
+ This operation is almost identical to the Set-Printer-Attributes
+ operation and follows the same rules for validation (see section
+ 4.1). The only differences are that the Set-Job-Attributes operation
+ is directed at a Job object rather than a Printer object, there is no
+ "document-format" operation attribute used when setting a Job object,
+ the operation can add an attribute to the (Job) object, the 'delete-
+ attributes' out-of-band value is permitted to remove an attribute,
+ and the validation is the same as the Job Creation operations (Print-
+ Job, Print-URI, and Create-Job), i.e., depends on the "xxx-supported"
+ Printer Description attributes (see [RFC2911] section 3.1). Using
+ the Set-Printer-Attributes operation, the administrator can set
+ arbitrary 'name' values to those "xxx-supported" Printer attributes
+ that include the 'name' attribute syntax if the implementation
+ supports the 'admin-define' out-of-band value for that "xxx-
+ supported" attribute (see section 15 and 8.3). However, the Set-Job-
+ Attributes cannot be used to add unsupported names to the Job object.
+
+
+ If a client supplies a job attribute in a Set-Job-Attributes request
+ that the Printer supports, and the job was originally submitted
+ without supplying that attribute, the Printer adds the attribute to
+ the Job object.
+
+
+ If the client supplies a job attribute with the "out-of-band" value
+ 'delete-attribute' (see section 8.2), then the Printer MUST remove
+ the attribute and all of its values from the Job object, if present.
+ The semantic effect of the client supplying the 'delete-attribute'
+ value in a Set-Job-Attributes operation MUST be the same as if the
+ attribute had not been supplied with the Job object in the Job
+ Creation operation, i.e., the Printer applies its default attribute
+ or behavior with lower precedence that the PDL (see the beginning of
+ [RFC2911] section 4.2 and [RFC2911] 3.2.1.1). Any subsequent query
+ of the Job object using Get-Job-Attributes or Get-Jobs MUST NOT
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 18]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ return any attribute that has been deleted using the 'delete-
+ attribute' out-of-band value. However, a client can re-establish
+ such a deleted Job attribute with any supported value(s) using a
+ subsequent Set-Job-Attributes operation.
+
+
+ If the client supplies an attribute in a Set-Job-Attributes request
+ with the 'delete-attribute' value and that attribute is not present
+ on the Job object, the Printer ignores that supplied attribute in the
+ request, does not return the attribute in the Unsupported Attributes
+ group, and returns the 'successful-ok' status code, if there are no
+ other problems with the request.
+
+
+ The validation of the Set-Job-Attributes request is performed by the
+ Printer as if the job had been submitted originally with the new
+ attribute values (and the deleted attributes removed) and with "ipp-
+ attribute-fidelity" set to 'true', i.e., all modified attributes Job
+ attributes and values MUST be supported in combination with the Job
+ attributes not modified. If such a Job Creation operation would have
+ been accepted, then the Set-Job-Attributes MUST be accepted. If such
+ a Job Creation operation would have been rejected, then the Set-Job-
+ Attributes MUST be rejected and the Job MUST be unchanged. In
+ addition, if any of the supplied attributes are not supported, are
+ not settable, or the values are not supported, the Printer object
+ MUST reject the entire operation; the Printer object MUST NOT
+ partially set some of the supplied attributes. In other words, after
+ the operation, all the supplied attributes MUST be set or none of
+ them MUST be set, thus making the Set-Job-Attributes an atomic
+ operation.
+
+
+ The IPP object MUST accept or reject this operations when the Job's
+ READ-ONLY "job-state" attribute has the values shown in Table 2. The
+ job's current state MUST affect whether the IPP object accepts or
+ rejects the request. For example, in the case where the operation
+ creates a request for unavailable resources, the Job transitions to a
+ new state. Table 2 shows the allowed behaviors in each job state and
+ the transitions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 19]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 2 - Job State Transition Table for the Set-Job-Attributes
+ operation
+
+
+
+ Current "job- New "job- IPP object's response status code
+ state" state" and action:
+
+
+ 'pending' 'pending' 'successful-ok'
+
+ 'pending' 'pending-held' 'successful-ok' - needed resources
+ are not ready
+
+ 'pending-held' 'pending-held' 'successful-ok'
+
+ 'pending-held' 'pending' 'successful-ok' - needed resources
+ are ready
+
+ 'processing' 'processing' 'successful-ok' or 'client-error-
+ not-possible' depending on
+ implementation, including the
+ attributes being set, whether the
+ job has started marking media,
+ etc.
+
+ 'processing- 'processing- 'successful-ok' or 'client-error-
+ stopped' stopped' not-possible' depending on
+ implementation, including the
+ attributes being set, whether the
+ job has started marking media,
+ etc.
+
+ 'completed' 'completed' 'client-error-not-possible'
+
+ 'canceled' 'canceled' 'client-error-not-possible'
+
+ 'aborted' 'aborted' 'client-error-not-possible'
+
+
+
+
+
+ This operation MUST NOT change the value of attributes not specified
+ in the operation unless the definition of the attribute explicitly
+ specifies such side-effects. In general, Job attribute definitions
+ that are settable will not define side-effects on other attributes
+ that are settable, only side effects on READ-ONLY attributes, if any.
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 20]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+4.2.1 Settable and READ-ONLY Job Description attributes
+
+
+ If the Printer supports the "job-message-from-operator" Job
+ Description attribute (see [RFC2911] section 4.3.16) and the client
+ explicitly supplies a new value for the "job-message-from-operator"
+ in the Set-Job-Attributes request, then the Printer MUST set the
+ "job-message-from-operator" Job attribute to this new value.
+
+
+ If the Printer supports the Set-Job-Attributes operation, then it
+ SHOULD support setting of:
+
+
+ all Job Template job ("xxx") attributes
+
+ that the implementation supports (see [RFC2911] section 4.2 and
+ extensions).
+
+
+ Some Job Description attributes (see [RFC2911] section 4.3) MUST NOT
+ be settable, i.e., they are defined to be READ-ONLY. An attribute
+ marked as "READ-ONLY" in the Job Description attribute table in
+ Appendix A is such an attribute. The Job attributes not marked as
+ "READ-ONLY" MAY be settable using the Set-Job-Attributes operation,
+ depending on implementation.
+
+
+ Note: From now on, all extensions that define new object attributes
+ will indicate whether or not the attributes are READ-ONLY, by
+ including the "READ-ONLY" adjective in their descriptions and/or
+ explicitly stating whether they MAY be settable.
+
+
+ Access Rights: The authenticated user (see [RFC2911] section 8.3)
+ performing this operation must either be the job owner (as determined
+ in the Job Creation operation) or an operator or administrator of the
+ Printer object (see [RFC2911] Sections 1 and 8.5).
+
+
+4.2.2 Set-Job-Attributes Request
+
+
+ The following sets of attributes are part of the Set-Job-Attributes
+ Request:
+
+
+ Group 1: Operation Attributes
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 21]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.1.
+
+ Target:
+ Either (1) the "printer-uri" (uri) plus "job-id"
+ (integer(1:MAX)) or (2) the "job-uri" (uri) operation
+ attribute(s) which define the target for this operation as
+ described in [RFC2911] section 3.1.5.
+
+ Requesting User Name:
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be
+ supplied by the client as described in [RFC2911] section 8.3.
+
+
+ Group 2: Job Attributes
+
+ The client MUST supply a set of Job attributes with one or more
+ values (including explicitly allowed out-of-band values) as
+ defined in [RFC2911] section 4.2 Job Template Attributes ("xxx"
+ attributes), section 4.3 Job Description Attributes, and any
+ attribute extensions supported by the Printer. The value(s) of
+ each Job attribute supplied in Group 2 replaces the value(s) of
+ the corresponding Job attribute on the target Job object. For
+ attributes that can have multiple values (1setOf), all values
+ supplied by the client replace all values of the corresponding
+ Job object attribute.
+
+ If the client supplies an "xxx" attribute with the 'delete-
+ attribute' out-of-band value (see section 8.2), the Printer
+ MUST remove the "xxx" attribute from the Job object, if
+ present.
+
+
+4.2.3 Set-Job-Attributes Response
+
+
+ The IPP object returns the following sets of attributes as part of
+ the Set-Job-Attributes Response:
+
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ In addition to the REQUIRED status code returned in every
+ response, the response OPTIONALLY includes a "status-message"
+ (text(255)) and/or a "detailed-status-message" (text(MAX))
+ operation attribute as described in [RFC2911] sections 13 and
+ 3.1.6.
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 22]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2.
+
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes.
+
+ If some of the attributes in the operation fail to validate,
+ the Printer MUST reject the operation, MUST NOT change any Job
+ attributes, and MUST return the indicated status code below.
+ In this group, the Printer MUST also return all attributes that
+ fail to validate. The following are the reasons that an
+ attribute fails to validate and the value returned for the
+ attribute, along with the indicated status code and order of
+ detection:
+
+ 1.The number of attributes supplied by the client exceeds the
+ maximum number that the Printer supports in a Set-Printer-
+ Attributes request: return the 'client-error-request-
+ entity-too-large' (see [RFC2911] section 13.1.4.9).
+
+
+ 2.The Printer doesn't support the attribute: return the
+ attribute with the 'unsupported' out-of-band attribute value
+ (see [RFC2911] section 3.1.7 and [RFC2910]) and the 'client-
+ error-attributes-or-values-not-supported (see [RFC2911]
+ section 13.1.4.12).
+
+
+ 3.The attribute is READ-ONLY (in its definition) or is not-
+ settable in this implementation: return the attribute with
+ the 'not-settable' out-of-band attribute value (see section
+ 8.1) and the 'client-error-attributes-not-settable' status
+ code (see section 7.1).
+
+
+ 4.The Printer doesn't support the value: if the attribute in
+ the operation has a single value return it. If the
+ attribute in the operation is multi-valued, return only
+ those values in a 1setOf that are not supported. Return the
+ 'client-error-attributes-or-values-not-supported' status
+ code (see [RFC2911] section 13.1.4.12).
+
+
+ 5.The values of some of the supplied attributes conflict with
+ one another and/or other Job attribute values not being set:
+ if the conflicting attribute in the operation has a single
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 23]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ value return the attribute and the value. If the attribute
+ in the operation is multi-valued, return only the attribute
+ and those values in a 1setOf that are conflicting with other
+ attributes. Return the 'client-error-conflicting-
+ attributes' status code (see [RFC2911] section 13.1.4.15).
+
+
+4.3 Get-Printer-Supported-Values Operation
+
+
+ This OPTIONAL operation allows a client to request the values that
+ the Printer allows in the Set-Printer-Attributes operation for "xxx-
+ supported" attributes. If the Printer supports the Set-Printer-
+ Attributes operation AND some of its "xxx-supported" Printer
+ attributes are settable, then the Printer MUST also support this
+ operation.
+
+
+ The Printer MUST return in the Get-Printer-Supported-Values response
+ those, and only those, "xxx-supported" Printer attributes that it
+ supports setting with the Set-Printer-Attributes operation.
+ Furthermore, if a client requests the value of an attribute that is
+ not settable or is not supported (as in the Get-Printer-Attributes
+ response), the Unsupported Attributes Group of the response NEED NOT
+ contain the "requested-attributes" operation attribute with any such
+ requested (attribute keyword) values.
+
+
+ This operation has identical request/response attributes to the Get-
+ Printer-Attributes operation in IPP/1.1 [RFC2911]. The operation
+ also behaves identically to the Get-Printer-Attributes operation in
+ IPP/1.1 [RFC2911] with the following exceptions:
+
+
+ 1.The Get-Printer-Supported-Values operation supports only "xxx-
+ supported" attributes.
+
+
+ 2.The Get-Printer-Attributes operation returns the few "xxx-
+ supported" attributes that are defined to be single valued, such
+ as "page-ranges-supported" (boolean) or "pdl-override-supported"
+ (type2 keyword), as single values, while Get-Printer-Supported-
+ Values returns the possible values that can be set as a 1setOf of
+ the same attribute syntax type (See Appendix B: Attributes
+ returned from Get-Printer-Supported-Values).
+
+
+ 3.The Get-Printer-Attributes operation returns the current values of
+ requested attributes while the Get-Printer-Supported-Values
+ operation returns the values that are inherently supported by the
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 24]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ implementation code, i.e., the values that an administrative
+ client can set in a Set-Printer-Attributes request.
+
+
+ 4.The Get-Printer-Attributes operation returns the current values of
+ requested "xxx-supported" attributes that the Printer is
+ configured to accept in Job Creation operations, including
+ additional values defined by the administrator, while the Get-
+ Printer-Supported-Values operation returns only the values of
+ "xxx-supported" attributes that are inherently supported by the
+ implementation and does not return any additional values defined
+ by the administrator where the implementation supports the 'admin-
+ define' out-of-band value.
+
+
+ 5.The Get-Printer-Attributes never returns the 'admin-define' out-
+ of-band attribute value, while the Get-Printer-Supported-
+ Attributes operation does, if the implementation allows the
+ administrator to define name values by setting that "xxx-
+ supported" attribute with any 'name' value(s).
+
+
+ 6.The Get-Printer-Attributes operation only requires end-user access
+ rights, while the Get-Printer-Supported-Values requires
+ administrator access rights.
+
+
+ Access Rights: The authenticated user (see [RFC2911] section 8.3)
+ performing this operation must be an administrator of the Printer
+ object (see [RFC2911] Sections 1 and 8.5).
+
+
+4.3.1 Definition of the usage of the 'admin-define' out-of-band
+ attribute value
+
+
+ If the Set-Printer-Attributes operation allows the System
+ Administrator to define arbitrary 'name' values for an "xxx-
+ supported" attribute, then the Get-Printer-Supported-Values operation
+ MUST return the 'admin-define' out-of-band attribute value (see
+ section 8.3) as one of the values of the "xxx-supported" attribute.
+ In other words, the 'admin-define' out-of-band attribute value
+ indicates that the Printer implementation supports clients setting
+ arbitrary 'name' attribute syntax values for that "xxx-supported"
+ attribute using the Set-Printer-Attributes operation as long as the
+ attribute is defined with the 'name' attribute syntax.
+
+
+ For example, if the Get-Printer-Supported-Values operation returns
+ several keywords as the value of the "media-supported" attribute,
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 25]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ then the Set-Printer-Attributes operation MUST accept any of these
+ keywords as values for the "media-supported" attribute. If the Get-
+ Printer-Supported-Values operation returns an 'admin-define' out-of-
+ band attribute value as one of the values of the "media-supported"
+ attribute, then the Set-Printer-Attributes operation MUST accept any
+ value whose attribute syntax is 'name' as a value for the "media-
+ supported" attribute (provided that the user is properly
+ authenticated to use the Set-Printer-Attributes operation, e.g., has
+ administrative access rights).
+
+
+ The Get-Printer-Supported-Values MAY return the 'admin-define' out-
+ of-band attribute value for any IPP/1.1 or extension Job Template
+ attribute if the implementation supports allowing the System
+ Administrator to add values to the "xxx-supported" attribute using
+ the Set-Printer-Attributes operation. In this case, the Printer MUST
+ accept any 'name' value of the correct attribute syntax in a Set-
+ Printer-Attributes operation that is setting that attribute. For
+ "xxx-supported" attributes that are defined with a choice of
+ attribute syntaxes, such as 'keyword | name', it is the 'name'
+ attribute syntax that the System Administrator can use to add new
+ values, not the 'keyword' attribute syntax. For IPP/1.1 this
+ requirement includes the following Job Template attributes:
+
+ media-supported
+ job-hold-until-supported
+ job-sheets-supported
+
+ Implementations that support additional Job Template attributes that
+ include the 'name' attribute syntax, MAY use the 'admin-define' out-
+ of-band value with them.
+
+
+ If the 'admin-define' out-of-band attribute value is not one of the
+ values of an "xxx-supported" attribute returned in a Get-Printer-
+ Supported-Values response, then the Printer MUST NOT allow the Set-
+ Printer-Attributes operation for that attribute to contain a value
+ that is not one of the explicit 'keyword' or 'name' values returned
+ in a Get-Printer-Supported-Values response.
+
+
+ See Appendix B: Attributes returned from Get-Printer-Supported-Values
+ for a full list of values returned by this operation.
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 26]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+5 New Operation attributes
+
+
+ This section defines new operation attributes for use with the
+ IPP/1.1 operations indicated. As new operations are defined they
+ will also indicate explicitly whether these operation attributes are
+ defined for use with them.
+
+
+5.1 printer-message-from-operator (text(127))
+
+
+ The Printer SHOULD support this Operation attribute in following
+ operations if it supports the corresponding "printer-message-from-
+ operator" Printer Description attribute.
+
+
+ Pause-Printer
+ Resume-Printer
+ Purge-Jobs
+
+
+ The client OPTIONALLY supplies this attribute in the above
+ operations. The value of this attribute is a message from the
+ operator about the Printer object on which the operator is performing
+ the operation. If this operation attribute is supported, the Printer
+ copies the value to its "printer-message-from-operator" Printer
+ Description attribute (see [RFC2911] section 4.4.25) even if this
+ Operation attribute is a zero-length text value or consists solely of
+ white space.
+
+
+ If the Printer supports this operation attribute, it MUST support
+ both a zero-length text value and the 'no-value' out-of-band value
+ (see [RFC2911] section 4.1) to indicate that the operator has sent no
+ message. In this case, the Printer sets the value of the "printer-
+ message-from-operator" to the zero-length value or 'no-value' out-of-
+ band value, respectively. If the client queries the "printer-
+ message-from-operator" Printer attribute, the Printer returns the
+ attribute with the zero-length value or the 'no-value' value,
+ respectively.
+
+
+ In addition, the Printer automatically copies:
+
+
+ 1.the value of its "printer-up-time" attribute (see [RFC2911]
+ section 4.4.29) to its "printer-message-time" attribute,
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 27]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ 2.the value of its printer-current-time" (dateTime) attribute (see
+ [RFC2911] section 4.4.30) to its "printer-message-date-time"
+ attribute, if supported.
+
+
+ If the client omits this operation attribute, the Printer does not
+ change the value of its "printer-message-from-operator", "printer-
+ message-time" and "printer-message-date-time" Printer Description
+ attributes.
+
+
+ The "printer-message-from-operator" operation attribute MUST NOT be
+ supported as an operation attribute for the Set-Printer-Attributes
+ operation. If the operator wants to set the Printer's "printer-
+ message-from-operator" Printer Description attribute when issuing the
+ Set-Printer-Attributes operation, the client supplies the "printer-
+ message-from-operator" explicitly with its new value as one of the
+ Printer Description attributes in Group 2 in the request. The
+ Printer also updates its "printer-message-time" and "printer-message-
+ date-time" Printer Description attributes. If the client does not
+ explicitly supply the "printer-message-from-operator" with its new
+ value in the Set-Printer-Attributes request, the Printer leaves the
+ value of the Printer's "printer-message-from-operator" Printer
+ Description attribute unchanged.
+
+
+5.2 job-message-from-operator (text(127))
+
+
+ The Printer SHOULD support this Operation attribute in following
+ operations if it supports the corresponding "job-message-from-
+ operator" Job Description attribute.
+
+
+ Cancel-Job
+ Hold-Job
+ Release-Job
+ Restart-Job
+
+
+ The client OPTIONALLY supplies this attribute in the above
+ operations. The value of this attribute is a message from the
+ operator about the Job object on which the operator has just
+ performed an operation. If supported, the Printer copies the value
+ to the Job's "job-message-from-operator" Job Description attribute
+ (see [RFC2911] section 4.3.16) (even if this Operation attribute is a
+ zero-length text value or consists solely of white space).
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 28]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ If the Printer supports this operation attribute, it MUST support
+ both a zero-length text value and the 'no-value' out-of-band value
+ (see [RFC2911] section 4.1) to indicate that the operator has sent no
+ message. In this case, the Printer sets the value of the "job-
+ message-from-operator" to the zero-length value or 'no-value' out-of-
+ band value, respectively. If the client queries the "job-message-
+ from-operator" Job attribute, the IPP object returns the attribute
+ with the zero-length value or the 'no-value' value, respectively.
+
+
+ If the client omits this attribute, the Printer does not change the
+ value of its "job-message-from-operator" Job Description attribute.
+
+
+ Note: There are no corresponding 'job-message-time" and "job-
+ message-date-time" Job Description attributes, since the usual
+ lifetime of a job is limited.
+
+
+ The "job-message-from-operator" operation attribute MUST NOT be
+ supported as an operation attribute for the Set-Job-Attributes
+ operation. If the operator wants to set the Job's "job-message-from-
+ operator" Job Description attribute when issuing the Set-Job-
+ Attributes operation, the client MUST supply the "job-message-from-
+ operator" with its new value as one of the Job Description attributes
+ in Group 2 in the request. Otherwise, the Printer leaves the value
+ of the Job's "job-message-from-operator" Job Description attribute
+ unchanged by not explicitly setting the attribute. If the client
+ does not explicitly supply the "job-message-from-operator" with its
+ new value in the Set-Job-Attributes request, the Printer leaves the
+ value of the Job's "job-message-from-operator" Job Description
+ attribute unchanged.
+
+
+
+6 New Printer Description Attributes
+
+
+ The following new Printer Description attributes are needed to
+ support the new operations defined in this document.
+
+
+6.1 printer-settable-attributes-supported (1setOf type2 keyword)
+
+
+ This REQUIRED READ-ONLY Printer attribute identifies the Printer
+ object attributes that are settable in this implementation, i.e.,
+ that are settable using the Set-Printer-Attributes operations (see
+ section 4.1). This attribute MUST be supported if the Set-Printer-
+ Attributes operations is supported. The Printer MUST reject attempts
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 29]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ to set any Printer attributes that are not one of the values of this
+ attribute, returning the 'client-error-attributes-not-settable'
+ status code (see section 7.1). The value of this attribute MAY
+ depend on the value of the "document-format" operation attribute
+ supplied in the Get-Printer-Attributes operation (see [RFC2911]
+ section 3.2.5.1).
+
+
+ Standard keyword values are:
+
+ 'none': There are no settable Printer attributes.
+ 'xxx': Where 'xxx' is any of the keyword attribute names allowed
+ by section 4.1.1
+
+6.2 job-settable-attributes-supported (1setOf type2 keyword)
+
+
+ This REQUIRED READ-ONLY Printer attribute identifies the Job object
+ attributes that are settable in this implementation, i.e., that are
+ settable using the Set-Job-Attributes operation (see section 4.2).
+ This attribute MUST be supported if the Set-Job-Attributes operations
+ is supported. The Printer MUST reject attempts to set any Job
+ attributes that are not one of the values of this attribute,
+ returning the 'client-error-attributes-not-settable' status code (see
+ section 7.1).
+
+
+ Standard keyword values are:
+
+ 'none': There are no settable Job attributes.
+ 'xxx': Where 'xxx' is any of the keyword attribute names allowed
+ by section 4.2.1.
+
+6.3 document-format-varying-attributes (1setOf type2 keyword)
+
+
+ This OPTIONAL READ-ONLY Printer Description attribute contains a set
+ of attribute name keywords. This attribute SHOULD be supported by a
+ Printer object, if the Printer object has Printer attributes whose
+ value vary depending on document format (see [RFC2911] Get-Printer-
+ Attributes operation). This attribute specifies which attribute
+ values can vary by document-format. If an attribute's name "xxx" is
+ a member of this attribute and the value of attribute "xxx" is
+ changed with the Set-Printer-Attributes operation that included the
+ "document-format" operation attribute, then the Printer MUST change
+ the value for the specified document format and no other document
+ formats (see section 4.1.2). If an attribute's name "xxx" is not a
+ member of this attribute and the value of attribute "xxx" is changed
+ with the Set-Printer-Attributes operation, then the attribute is
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 30]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ changed for all document formats (whether or not the client supplied
+ the "document-format" operation attribute).
+
+
+6.4 printer-message-time (integer(MIN:MAX))
+
+
+ This OPTIONAL READ-ONLY Printer Description attribute contains the
+ time that the Printer's "printer-message-from-operator" was changed
+ by the operator using any operation where the client supplied the
+ "printer-message-from-operator" operation attribute (see section 5.1)
+ or was explicitly set using the Set-Printer-Attributes operation (see
+ section 4.1). This attribute allows the users to know when the
+ "printer-message-from-operator" attribute was last set.
+
+
+ The Printer sets the value of this attribute by copying the value of
+ the Printer's "printer-up-time" attribute (see [RFC2911] section
+ 4.3.14). If the Printer resets its "printer-up-time" attribute to 1
+ on power-up, then it MUST change the value of the "printer-message-
+ time" to 0 or a negative number as specified in [RFC2911] section
+ 4.3.14.
+
+
+ Note: This attribute helps users better understand the context for
+ the "printer-message-from-operator" message.
+
+
+6.5 printer-message-date-time (dateTime)
+
+
+ This OPTIONAL READ-ONLY Printer Description attribute contains the
+ date and time that the Printer's "printer-message-from-operator" was
+ changed by the operator using any operation where the client supplied
+ the "printer-message-from-operator" operation attribute (see section
+ 5.1) or was explicitly set using the Set-Printer-Attributes operation
+ (see section 4.1). This attribute allows the users to know when the
+ "printer-message-from-operator" attribute was last set.
+
+
+ This attribute MUST be supported if the Printer supports both the
+ "printer-message-time" and the "printer-current-time" (dateTime)
+ attributes (see [RFC2911] section 4.4.30).
+
+
+ Note: This attribute helps users better understand the context for
+ the "printer-message-from-operator" message.
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 31]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+6.6 printer-xri-supported (1setOf collection)
+
+
+ This OPTIONAL Printer Description attribute is a multi-valued
+ attribute where each value has the 'collection' attribute syntax (see
+ [ipp-coll]) containing member attributes with the same semantics as
+ the following IPP/1.1 READ-ONLY Printer Description attributes,
+ except for cardinality:
+
+ printer-uri-supported (1setOf uri) - see [RFC2911] section
+ 4.4.1
+ uri-authentication-supported (1setOf type2 keyword) - see
+ [RFC2911] section 4.4.2
+ uri-security-supported (1setOf type2 keyword) - see [RFC2911]
+ section 4.4.3
+
+ When setting the "printer-xri-supported" attribute with a Set-
+ Printer-Attributes request, the Printer MUST also set these three
+ IPP/1.1 READ-ONLY Printer Description attributes as a defined side
+ effect. Thus, this collection attribute provides the means to set
+ these three IPP/1.1 READ-ONLY attributes atomically so that they are
+ never left in a partially inconsistent state.
+
+
+ An IPP Printer MUST NOT provide any other way using IPP to set these
+ three IPP/1.1 READ-ONLY Printer Description attributes, since they
+ are READ-ONLY and MUST have consistent values at all times. Note:
+ The "xri-printer-supported" (1setOf collection) attribute can be put
+ into a directory schema that requires a single text string value,
+ such as SLP or LDPA, by using suitable delimiting characters to
+ separate member attributes of the collection and/or terminating
+ collection values. See [svrloc-printer] and [ldap-printer].
+
+
+ The member attributes of the "printer-xri-supported" (1setOf
+ collection) are given in Table 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 32]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 3 - Member attributes of "printer-xri-supported" (1setOf
+ collection)
+
+
+
+ Member attribute client Printer
+ MUST MUST
+ supply support
+
+
+ xri-uri (uri) yes yes
+
+ xri-authentication (1setOf type2 keyword) yes yes
+
+ xri-security (1setOf type2 keyword) yes yes
+
+
+ Each collection value MUST contain a single unique value for the
+ "xri-uri" member attribute. However, the other two member attributes
+ are multi-valued, so that a single URI can support more than one
+ authentication scheme and/or more than one security scheme. Other
+ than the uniqueness and the cardinality requirements, the semantics
+ of these three member attributes is given in [RFC2911] sections
+ 4.4.1, 4.4.2, and 4.4.3, respectively.
+
+
+ A client can query the current values using the Get-Printer-
+ Attributes operation by supplying either:
+
+
+ 1.the three IPP/1.1 attribute names: "printer-uri-supported", "uri-
+ authentication-supported", "uri-security-supported" and getting
+ back the parallel values OR
+
+
+ 2.the single attribute name: "printer-xri-supported" and getting
+ back the 1setOf collection which contains the same information
+ semantically, but in a different form.
+
+
+ A client can query what member attribute values can be set by
+ supplying the three attribute names: "xri-uri-scheme-supported",
+ "xri-authentication-supported", and "xri-security-supported" in a
+ Get-Printer-Supported-Values request and getting back the uriScheme
+ and type2 keyword values that can be set. Since the "printer-xri-
+ supported", "uri-authentication-supported", and "uri-security-
+ supported" attributes are READ-ONLY, they are not queriable with the
+ Get-Printer-Supported-Values operation (see section 4.3). See Table
+ 15.
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 33]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ When performing a Set-Printer-Attributes operation, if there are
+ multiple values for the "xri-authentication" and/or "xri-security"
+ member attributes, the Printer MUST set the corresponding three READ-
+ ONLY attributes with all possible combinations of values. For
+ example, setting the "printer-xri-supported" with the following two
+ collection values where the first URI has both 'basic' and 'digest'
+ authentication:
+
+
+ "printer-xri-supported =
+ { "xri-uri" = ipp://abc.com/p1
+ "xri-authentication" = basic, digest
+ "xri-security" = tls
+ },
+ { "xri-uri" = http://abc.com/pq
+ "xri-authentication" = none
+ "xri-security" = none
+ }
+
+
+ would cause the Printer to set the three corresponding IPP/1.1 READ-
+ ONLY attributes, each with three parallel values as follows:
+
+
+ "printer-uri-supported" = { ipp://abc.com/p1, ipp://abc.com/p1,
+ http://abc.com/pq }
+ "uri-authentication-supported" = { basic, digest, none }
+ "uri-security-supported" = { tls, tls, none }
+
+
+ Because there were two authentication values for the ipp://abc.com/p1
+ URL, that URL value is repeated. Had the ipp URL had 2
+ authentication values and 3 security values, then there would have
+ been 7 (2*3 + 1) parallel values for each of the three attributes, 6
+ with the same ipp URI and 1 with the http URI.
+
+
+6.7 xri-uri-scheme-supported (1setOf uriScheme)
+
+
+ This OPTIONAL READ-ONLY Printer Description attribute identifies the
+ URI schemes that the implementation supports for use in the "printer-
+ uri-supported" (1setOf uri) Printer Description attribute (see
+ [RFC2911] section 4.4.1) and the "xri-uri" member attribute of the
+ "xri-printer-supported" (1setOf collection) Printer Description
+ attribute (see section 6.6).
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 34]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ A Printer MUST support this attribute if it supports setting the
+ "printer-xri-supported" (1setOf collection) with the Set-Printer-
+ Attributes operation.
+
+
+6.8 xri-authentication-supported (1setOf type2 keyword)
+
+
+ This OPTIONAL READ-ONLY Printer Description attribute identifies the
+ Client Authentication mechanisms that the implementation supports for
+ use in the "uri-authentication-supported" (1setOf type2 keyword)
+ Printer Description attribute (see [RFC2911] section 4.4.2) and the
+ "xri-authentication" member attribute of the "xri-printer-supported"
+ (1setOf collection) Printer Description attribute (see section 6.6).
+
+
+ A Printer MUST support this attribute if it supports setting the
+ "printer-xri-supported" (1setOf collection) with the Set-Printer-
+ Attributes operation.
+
+
+6.9 xri-security-supported (1setOf type2 keyword)
+
+
+ This OPTIONAL READ-ONLY Printer Description attribute identifies the
+ URI schemes that the implementation supports for use in the "uri-
+ security-supported" (1setOf type2 keyword) Printer Description
+ attribute (see [RFC2911] section 4.4.3) and the "xri-security" member
+ attribute of the "xri-printer-supported" (1setOf collection) Printer
+ Description attribute (see section 6.6).
+
+
+ A Printer MUST support this attribute if it supports setting the
+ "printer-xri-supported" (1setOf collection) with the Set-Printer-
+ Attributes operation.
+
+
+
+7 Additional status codes
+
+ This section defines new status codes used by the operations defined
+ in this document.
+
+7.1 'client-error-attributes-not-settable' (0x0413)
+
+
+ The Set-Printer-Attributes or Set-Job-Attributes operation failed
+ because one or more of the specified attributes cannot be set either
+ because the attribute is defined to be READ-ONLY or the attribute is
+ not settable in this implementation (see sections 4.1.3 and 4.2.3),
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 35]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ the Printer MUST return this error code and the attribute keyword
+ name(s) and the 'not-settable' out-of-band value (see section 8.1) in
+ the Unsupported Attributes Group(see [RFC2911] section 3.1.7) for all
+ of the attributes that could not be set. When the Printer returns
+ this status, it MUST NOT change any of the attributes supplied in the
+ operation.
+
+
+
+8 Additional out-of-band values
+
+
+ This section defines additional out-of-band values. As with all out-
+ of-band values, a client or a Printer MUST NOT use an out-of-band
+ value unless the definition of the attribute in an operation request
+ and/or response explicitly allows such usage. See the beginning of
+ [RFC2911] section 4.1.
+
+
+8.1 'not-settable' out-of-band value
+
+
+ The 'not-settable' out-of-band attribute value is returned by the IPP
+ Printer in the Unsupported Attributes group of a response to indicate
+ that the attribute supplied by the client in the request is READ-ONLY
+ by definition or is not settable in this implementation.
+
+
+ The 'not-settable' out-of-band attribute value is defined for use
+ with the Set-Job-Attributes and Set-Printer-Attributes response only.
+ If a future additional "set" operation allows the 'not-settable' out-
+ of-band value, its definition document MUST indicate such use
+ explicitly, including with which attributes.
+
+
+ An IPP object MUST support the 'not-settable' out-of-band value in a
+ Set-Job-Attributes or Set-Printer-Attributes request if it supports
+ those operations. A client MUST NOT supply the 'not-settable' out-
+ of-band value in any request. An IPP object MUST NOT support the
+ 'not-settable' out-of-band value in other operations, unless the
+ operations' definition document explicitly defines such usage. If a
+ Printer receives this out-of-band value in any operation request, the
+ Printer MUST either (1) reject the entire request and return the
+ 'client-error-bad-request' status code or (2) ignore the attribute
+ and return it with the 'unsupported' out-of-band value.
+
+
+ See sections 4.1.3 and 4.2.3 in this document for an example
+ definition of the usage of the 'not-settable' out-of-band value in
+ the Set-Printer-Attributes and Set-Job-Attributes responses.
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 36]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+8.1.1 Encoding of the 'not-settable' out-of-band attribute value
+
+
+ The encoding of the 'not-settable' out-of-band value is 0x15 (see
+ [RFC2910]). The value-length MUST be 0 and the value empty.
+
+
+8.2 'delete-attribute' out-of-band value
+
+
+ The 'delete-attribute' out-of-band attribute value is supplied by the
+ client in a request to indicate that the Printer is to remove the
+ supplied attribute and all of its values from the target object, if
+ present.
+
+
+ The 'delete-attribute' out-of-band attribute value is defined for use
+ with the Set-Job-Attributes request only. If a future additional
+ "set" operation allows the 'delete-attribute' out-of-band value, its
+ definition document MUST indicate such use explicitly, including with
+ which attributes.
+
+
+ An IPP Printer MUST support the 'delete-attribute' out-of-band value
+ if it supports the Set-Job-Attributes operation. A client MUST NOT
+ supply and an IPP object MUST NOT support the 'delete-attribute' out-
+ of-band value in other operations, unless the operations' definition
+ document explicitly defines such usage. For example, the 'delete-
+ attribute' out-of-band value MUST NOT be used in the Set-Printer-
+ Attributes operation, where the absence of an attribute from an IPP
+ object indicates that the attribute is not supported. If a Printer
+ receives this out-of-band value in other operation requests, the
+ Printer MUST either (1) reject the entire request and return the
+ 'client-error-bad-request' status code or (2) ignore the attribute
+ and return it with the 'unsupported' out-of-band value.
+
+
+ See section 4.2 in this document for the definition of the usage of
+ the 'delete-attribute' out-of-band value in the Set-Job-Attributes
+ request.
+
+
+8.2.1 Encoding of the 'delete-attribute' out-of-band value
+
+
+ The encoding of the 'delete-attribute' out-of-band value is 0x16 (see
+ [RFC2910]). The value-length MUST be 0 and the value empty.
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 37]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+8.3 'admin-define' out-of-band attribute value
+
+
+ Section 4.3 defines the Get-Printer-Supported-Values response to
+ contain the values of an "xxx-supported" attribute that are supported
+ by the implementation before any additional value are defined by the
+ administrator. The 'admin-define' out-of-band attribute value is
+ returned as an additional value of an "xxx-supported" attribute in a
+ Get-Printer-Supported-Values response to indicate that the
+ implementation supports allowing an administrator to define
+ additional arbitrary 'name' values for that "xxx-supported"
+ attribute.
+
+
+ For example, if the "media-supported" (1setOf (type3 keyword | name))
+ attribute contains this value, then the Printer MUST permit an
+ administrator to add new media names to the Printer's "media-
+ supported" attribute. In order for an administrator to add new
+ values to a Printer's "xxx-supported" attribute, the client supplies
+ the existing and new values in a Set-Printer-Attributes request for
+ that attribute. The client MUST supply any such administratively
+ defined values in the Set-Printer-Attributes request using the 'name'
+ attribute syntax.
+
+
+ The 'admin-define' out-of-band attribute value is defined for use
+ with the Get-Printer-Supported-Values response only. A Printer MUST
+ NOT return the 'admin-define' out-of-band value in a Get-Printer-
+ Attributes response, since such a response indicates what an end-user
+ client can supply in a Job Creation operation. If a future
+ additional "get" operation allows the 'admin-define' out-of-band
+ value, its definition document MUST indicate such use explicitly,
+ including with which attributes.
+
+
+ An IPP Printer MUST support the 'admin-define' out-of-band value, if
+ it supports a client setting arbitrary 'name' values of an "xxx-
+ supported" Printer attribute using the Set-Printer-Attributes
+ operation. A client MUST NOT supply the 'admin-define' out-of-band
+ value in any request. An IPP object MUST NOT support the 'admin-
+ define' out-of-band value in other operations, unless the operations'
+ definition document explicitly defines such usage. If a Printer
+ receives this out-of-band value in any operation request, the Printer
+ MUST either (1) reject the entire request and return the 'client-
+ error-bad-request' status code or (2) ignore the attribute and return
+ it with the 'unsupported' out-of-band value.
+
+
+ This document defines that the 'admin-define' out-of-band value MUST
+ be used only with "xxx-supported" attributes that are defined to
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 38]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ include the 'name' attribute syntax. This out-of-band value is not
+ intended to be used with "xxx-supported" attributes of other
+ attribute syntaxes, such as 'uri', even though the administrator
+ defines arbitrary values for such attributes. If other documents
+ extend the use of the 'admin-define' out-of-band value to other
+ attribute syntaxes, such a document MUST define such use explicitly,
+ including with which attributes.
+
+
+ See section 4.3 in this document for an example definition of the
+ usage of the 'admin-define' out-of-band attribute value in any "xxx-
+ supported" attribute returned in a Get-Printer-Supported-Values
+ response that is defined to include the 'name' attribute syntax.
+
+
+8.3.1 Encoding of the 'admin-define' out-of-band attribute value
+
+
+ The encoding of the 'admin-define' out-of-band attribute value is
+ 0x17 (see [RFC2910]). The value-length MUST be 0 and the value
+ empty.
+
+
+
+9 Conformance Requirements
+
+
+ This section specifies the conformance requirements for clients and
+ IPP objects.
+
+
+ Both the Set-Job-Attributes and the Set-Printer-Attributes operations
+ defined in the document are OPTIONAL for an IPP object to support.
+ Either one MAY be supported without the other or both MAY be
+ supported. However, if the Set-Printer-Attributes operation is
+ supported, then the Get-Printer-Supported-Values operation MUST be
+ supported if any "xxx-supported" attributes are settable. Otherwise,
+ the Get-Printer-Supported-Values operation is OPTIONAL for an IPP
+ Printer to support.
+
+
+ If the Set-Printer-Attributes operation is supported, then the
+ Printer MUST support the following additional items:
+
+
+ 1.the Get-Printer-Supported-Values operation (see section 5), if
+ any "xxx-supported" attributes are settable.
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 39]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ 2.the "printer-settable-attributes-supported" Printer Description
+ attribute (see section 6.1)
+
+
+ 3.the 'not-settable' out-of-band value in responses (see section
+ 8.1)
+
+
+ 4.the 'client-error-not-settable' status code (see section 7.1)
+
+
+ 5.If "printer-message-from-operator" Printer Description attribute
+ is supported (see [RFC2911] section 4.4.25), then it MUST be
+ settable.
+
+
+ 6.the Get-Printer-Supported-Values operation (see section 4.3), if
+ any "xxx-supported" attributes are settable.
+
+
+ 7.If a client can set a value with the 'name' attribute syntax for
+ one or more "xxx-supported" attributes, then the 'admin-define'
+ out-of-band attribute value (see section 8.3) MUST be supported
+ in the Get-Printer-Supported-Values response for each such
+ settable attribute (see section 4.3)
+
+
+ If the Set-Job-Attributes operation is supported, then the Printer
+ MUST support the following additional items:
+
+
+ 1.the "job-settable-attributes-supported " Printer Description
+ attribute (see section 6.2)
+
+
+ 2.the 'not-settable' out-of-band value in responses (see section
+ 8.1)
+
+
+ 3.the 'delete-attribute' out-of-band value in requests (see
+ section 8.2)
+
+
+ 4.the 'client-error-not-settable' status code (see section 7.1)
+
+
+ 5.If the "job-message-from-operator" Printer Description attribute
+ is supported (see [RFC2911] 4.3.16), then it MUST be settable.
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 40]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ It is OPTIONAL for the Printer object to support the "printer-
+ message-time" (integer) and "printer-message-date-time" (dateTime)
+ Printer Description attributes. If both the "printer-message-time"
+ (integer) and the "printer-current-time" (dateTime) (see [RFC2911]
+ section 4.4.30) attributes are supported, then the "printer-message-
+ date-time" (dateTime) Printer Description attribute MUST be
+ supported.
+
+
+ As with all out-of-band values, a client or a Printer MUST NOT use an
+ out-of-band value unless the definition document for the attribute in
+ an operation request and/or response explicitly allows such usage.
+
+
+
+10 IANA Considerations
+
+ This section contains the exact information for IANA to add to the
+ IPP Registries according to the procedures defined in RFC 2911
+ [RFC2911] section 6.
+
+ Note to RFC Editors: Replace RFC NNNN below with the RFC number for
+ this document, so that it accurately reflects the content of the
+ information for the IANA Registry.
+
+10.1 Operation Registrations
+
+ The operations defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.4 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/operations/
+
+ The registry entry will contain the following information:
+
+ Operations: Ref. Section:
+ Set-Printer-Attributes RFC NNNN 4.1
+ Set-Job-Attributes RFC NNNN 4.2
+ Get-Printer-Supported-Values RFC NNNN 4.3
+
+
+10.2 Attribute Registrations
+
+ The attributes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.2 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attributes/
+
+ The registry entry will contain the following information:
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 41]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+ Operation attributes: Ref. Section:
+ printer-message-from-operator (text(127)) RFC NNNN 5.1
+ job-message-from-operator (text(127)) RFC NNNN 5.2
+
+ Printer Description attributes: Ref. Section:
+ printer-settable-attributes-supported (1setOf type2 keyword)
+ RFC NNNN 6.1
+ job-settable-attributes-supported (1setOf type2 keyword)
+ RFC NNNN 6.2
+ document-format-varying-attributes (1setOf type2 keyword)
+ RFC NNNN 6.3
+ printer-message-time (integer(MIN:MAX)) RFC NNNN 6.4
+ printer-message-date-time (dateTime) RFC NNNN 6.5
+ printer-xri-supported (1setOf collection) RFC NNNN 6.6
+ xri-uri-scheme-supported (1setOf uriScheme) RFC NNNN 6.7
+ xri-authentication-supported (1setOf type2 keyword) 6.8
+ xri-security-supported (1setOf type2 keyword) RFC NNNN 6.9
+
+
+10.3 Status code Registrations
+
+ The status codes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.6 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/status-codes/
+
+ The registry entry will contain the following information:
+
+ Status codes: Ref. Section:
+ 'client-error-attributes-not-settable' (0x0413) RFC NNNN 7.1
+
+
+10.4 Out-of-band Attribute Value Registrations
+
+ The out-of-band attribute values defined in this document will be
+ published by IANA according to the procedures in RFC 2911 [RFC2911]
+ section 6.7 with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-tags/
+
+ The registry entry will contain the following information:
+
+ Out-of-band Attribute Values: Ref. Section:
+ 'not-settable' out-of-band value RFC NNNN 8.1
+ 'delete-attribute' out-of-band value RFC NNNN 8.2
+ 'admin-define' out-of-band attribute value RFC NNNN 8.3
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 42]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+11 Internationalization Considerations
+
+ This document has the same localization considerations as the
+ [RFC2911].
+
+
+12 Security Considerations
+
+
+ The IPP Model and Semantics document [RFC2911 section 8] discusses
+ high level security requirements (Client Authentication, Server
+ Authentication and Operation Privacy). Client Authentication is the
+ mechanism by which the client proves its identity to the server in a
+ secure manner. Server Authentication is the mechanism by which the
+ server proves its identity to the client in a secure manner.
+ Operation Privacy is defined as a mechanism for protecting operations
+ from eavesdropping.
+
+
+ In addition, the introduction of the Set-Printer-Attributes and Set-
+ Job-Attributes operations creates another security threat, since the
+ client is able to modify the Printer and Job attributes stored in the
+ Printer. Such modifications could lead to denial of service.
+
+
+ A malicious user could alter the policy established by the system
+ administrator and stored in the Printer attributes. Such alteration
+ could either grant access to more resources or deny access to
+ resources that the system administrator has established. For
+ example, the malicious user could remove all of the document-format
+ values from the "document-format-supported" Printer attribute so that
+ the Printer would refuse to accept all jobs.
+
+
+ The general remedy for such malicious user actions against Printer
+ attributes is to have strong Client Authentication coupled with
+ Printer access control to limit the users who have System
+ Administrator or Operator privileges.
+
+
+ A malicious user could modify the Job Template attributes of another
+ user's Job, such as the "copies" attribute. For example, setting the
+ number of copies to a large number.
+
+
+ The general remedy for such malicious user actions against another
+ user's job is to have strong Client Authentication coupled with
+ Printer access control to limit the users who have System
+ Administrator or Operator privileges who can modify any job and, in
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 43]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ addition, store the Client Authentication with each Job so that only
+ the job owner End User can modify his/her own job.
+
+
+
+13 Author's Addresses
+
+ Carl Kugler
+ IBM
+ P.O. Box 1900
+ Boulder, CO 80301-9191
+
+ Phone: (303) 924-5060
+ FAX:
+ e-mail: kugler@us.ibm.com
+
+ Tom Hastings
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+ Robert Herriot
+ Xerox Corp.
+ 3400 Hill View Ave, Building 1
+ Palo Alto, CA 94304
+
+ Phone: 650-813-7696
+ Fax: 650-813-6860
+ e-mail: robert.herriot@pahv.xerox.com
+
+ Harry Lewis
+ IBM
+ P.O. Box 1900
+ Boulder, CO 80301-9191
+
+ Phone: (303) 924-5337
+ FAX:
+ e-mail: harryl@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 44]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+14 References
+
+ [ipp-coll]
+ deBry, R., , Hastings, T., Herriot, R., "Internet Printing Protocol
+ (IPP): The Collection Attribute Syntax", <draft-ietf-ipp-
+ collection-02.doc>, work in progress, March 9, 2000.
+
+ [ipp-set2]
+ Kugler, C, Hastings, T., Lewis, H., "Internet Printing
+ Protocol/1.1: Job and Printer Administrative Operations", <draft-
+ ietf-ipp-ops-set2-01.txt>, December 8, 1999.
+
+ [ldap-printer]
+ Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing
+ Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp-
+ ldap-printer-schema-00.txt>, work in progress, March 8, 2000.
+
+ [RFC2565]
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
+
+ [RFC2566]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
+ April 1999.
+
+ [RFC2910]
+ Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
+
+ [RFC2911]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911,
+ September 2000.
+
+ [svrloc-printer]
+ St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the
+ Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer-
+ scheme-06.txt>, work in progress, March 8, 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 45]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+15 Appendix A: Allowed Values for Set-Printer-Attributes and Set-Job-
+ Attributes requests
+
+
+ This appendix is a normative part of this document and contains a
+ table of all IPP/1.1 attributes. Each row contains:
+
+ . an attribute and
+
+ . the values allowed in the Set-Printer-Attributes or Set-Job-
+ Attributes request for the attribute. The entry in each cell is
+ the name (first few words) of each item below 1, 2, 3, 4a-g, and
+ 5.
+
+ The allowed values include the following cases:
+
+ 1.READ-ONLY: the Set-Printer-Attributes or Set-Job-Attributes
+ operation MUST NOT change this attribute and MUST reject the
+ entire operation (see section 7.1).
+
+ 2.Any of "xxx-supported": the Set-Printer-Attributes or Set-Job-
+ Attributes operation accepts values that are allowed according to
+ the IPP/1.1 rules for validating the value(s) of an "xxx" Printer
+ or Job attribute against the value(s) of the corresponding "xxx-
+ supported" Printer attribute. Table 4 summarizes those validation
+ rules depending on each attribute syntax and value of an "xxx"
+ attribute supplied in the request and that of the corresponding
+ "xxx-supported" Printer attribute. The "xxx-supported" attribute
+ syntax type and value(s) are obtained from a Get-Printer-
+ Supported-Values response (see the tables in this Appendix).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 46]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 4 - Validation rules for 'Any of "xxx-supported" '
+
+
+
+ Type of "xxx" Type of "xxx- Validates if:
+ value to be supported" value
+ set
+
+
+ integer rangeOfInteger each value is in one of the
+ "xxx-supported" ranges
+
+ uri uriScheme each uri scheme matches one
+ of the "xxx-supported"
+ schemes
+
+ any boolean if the boolean "xxx-
+ supported" is 'true'
+
+ any same type each value matches an "xxx-
+ supported" value of the same
+ type
+
+
+
+ For additional non-normative explanatory information see section
+ 3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's
+ Guide" [ipp-iig]).
+
+ 3. From Get-Printer-Supported-Values: the Set-Printer-Attributes
+ operation accepts values that are allowed according to the IPP/1.1
+ rules for validating the value(s) of an "xxx" Printer attribute
+ against the value(s) of the corresponding "xxx-supported" Printer
+ attribute. Table 5 summarizes those validation rules depending on
+ each attribute syntax and value of an "xxx" attribute supplied in
+ the request and that of the corresponding "xxx-supported" Printer
+ attribute. The "xxx-supported" attribute syntax type and attribute
+ value(s) are obtained from a Get-Printer-Supported-Values response
+ (see Appendix B: Attributes returned from Get-Printer-Supported-
+ Values below).
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 47]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 5 - Validation rules for 'From Get-Printer-Supported-Values'
+
+
+
+ Type of Type of "xxx- Validates if:
+ "xxx" supported" value
+ value to
+ be set
+
+
+ integer rangeOfInteger each 'integer' value is in one of
+ the "xxx-supported" ranges
+
+ uri uriScheme the uri scheme of each value
+ matches one of the "xxx-supported"
+ schemes
+
+ any boolean if the boolean "xxx-supported" is
+ 'true'
+
+ name 'admin-define' any 'name' value matches
+ out-of-band
+ value
+
+ any same type each value matches an "xxx-
+ supported" value of the same type
+
+
+
+ For additional non-normative explanatory information see section
+ 3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's
+ Guide" [ipp-iig]).
+
+ 4. Any value of the proper attribute syntax: the Set-Printer-
+ Attributes or Set-Job-Attributes operation accepts any value of the
+ specified attribute syntax. The attribute syntaxes supported are
+ enumerated below.
+
+ a.Any text(127)
+ b.Any name(127)
+ c.Any uri
+ d.Any boolean
+ e.Any positive integer
+ f.Any dateTime
+ g.1setOf any uri
+
+ 5. Combination of 'Any of "xxx-supported"' or 'Any name'.
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 48]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ If a Printer implementation doesn't want to allow setting values
+ indicated in this Appendix as "any xxx", it can make the value be
+ not-settable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 49]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 6 - Values allowed for Job Template Attributes in the Set-Job-
+ Attributes Operation
+
+
+
+ Job Template Attributes Values allowed for
+ Set
+
+
+
+
+ job-priority (integer(1:100)) Any of "xxx-
+ supported"
+
+ job-hold-until (type3 keyword | name (MAX)) Any of "xxx-
+ supported"
+
+ job-sheets (type3 keyword | name(MAX)) Any of "xxx-
+ supported"
+
+ multiple-document-handling (type2 keyword) Any of "xxx-
+ supported"
+
+ copies (integer(1:MAX)) Any of "xxx-
+ supported"
+
+ finishings (1setOf type2 enum) Any of "xxx-
+ supported"
+
+ page-ranges (1setOf rangeOfInteger (1:MAX)) Any of "xxx-
+ supported"
+
+ sides (type2 keyword) Any of "xxx-
+ supported"
+
+ number-up (integer(1:MAX)) Any of "xxx-
+ supported"
+
+ orientation-requested (type2 enum) Any of "xxx-
+ supported"
+
+ media (type3 keyword | name(MAX)) Any of "xxx-
+ supported"
+
+ printer-resolution (resolution) Any of "xxx-
+ supported"
+
+ print-quality (type2 enum) Any of "xxx-
+ supported"
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 50]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 51]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 7 - Values allowed for Job Description Attributes in the Set-
+ Job-Attributes Operation
+
+
+
+ Job Description Attributes Values allowed for
+ Set
+
+
+
+
+ job-uri (uri) READ-ONLY
+
+ job-id (integer(1:MAX)) READ-ONLY
+
+ job-printer-uri (uri) READ-ONLY
+
+ job-more-info (uri) READ-ONLY
+
+ job-name (name(MAX)) Any name(MAX)
+
+ job-originating-user-name (name(MAX)) READ-ONLY
+
+ job-state (type1 enum) READ-ONLY
+
+ job-state-reasons (1setOf type2 keyword) READ-ONLY
+
+ job-state-message (text(MAX)) READ-ONLY
+
+ job-detailed-status-messages (1setOf READ-ONLY
+ text(MAX))
+
+ job-document-access-errors (1setOf READ-ONLY
+ text(MAX))
+
+ number-of-documents (integer(0:MAX)) READ-ONLY
+
+ output-device-assigned (name(127)) READ-ONLY
+
+ time-at-creation (integer(MIN:MAX)) READ-ONLY
+
+ time-at-processing (integer(MIN:MAX)) READ-ONLY
+
+ time-at-completed (integer(MIN:MAX)) READ-ONLY
+
+ job-printer-up-time (integer(1:MAX)) READ-ONLY
+
+ date-time-at-creation (dateTime) READ-ONLY
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 52]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Job Description Attributes Values allowed for
+ Set
+
+
+
+
+ date-time-at-processing (dateTime) READ-ONLY
+
+ date-time-at-completed (dateTime) READ-ONLY
+
+ number-of-intervening-jobs (integer(0:MAX)) READ-ONLY
+
+ job-message-from-operator (text(127)) Any text(127)
+
+ job-k-octets (integer(0:MAX)) READ-ONLY
+
+ job-impressions (integer(0:MAX)) READ-ONLY
+
+ job-media-sheets (integer(0:MAX)) READ-ONLY
+
+ job-k-octets-processed (integer(0:MAX)) READ-ONLY
+
+ job-impressions-completed (integer(0:MAX)) READ-ONLY
+
+ job-media-sheets-completed (integer(0:MAX)) READ-ONLY
+
+ attributes-charset (charset) READ-ONLY
+
+ attributes-natural-language READ-ONLY
+ (naturalLanguage)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 53]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 8 - Values allowed for Printer Job Template Attributes in the
+ Set-Printer-Attributes Operation
+
+
+
+ Printer Job Template Attributes Values allowed
+ for Set
+
+
+ job-priority-default (integer(1:100)) Any of "xxx-
+ supported"
+
+ job-hold-until-default (type3 keyword | name Any of "xxx-
+ (MAX)) supported"
+
+ job-sheets-default (type3 keyword | name(MAX)) Any of "xxx-
+ supported"
+
+ multiple-document-handling-default (type2 Any of "xxx-
+ keyword) supported"
+
+ copies-default (integer(1:MAX)) Any of "xxx-
+ supported"
+
+ finishings-default (1setOf type2 enum) Any of "xxx-
+ supported"
+
+ sides-default (type2 keyword) Any of "xxx-
+ supported"
+
+ number-up-default (integer(1:MAX)) Any of "xxx-
+ supported"
+
+ orientation-requested-default (type2 enum) Any of "xxx-
+ supported"
+
+ media-default (type3 keyword | name(MAX)) Any of "xxx-
+ supported"
+
+ printer-resolution-default (resolution) Any of "xxx-
+ supported"
+
+ print-quality-default (type2 enum) Any of "xxx-
+ supported"
+
+ job-priority-supported (integer(1:100)) From Get-
+ Printer-
+ Supported-Values
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 54]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Printer Job Template Attributes Values allowed
+ for Set
+
+
+ job-hold-until-supported (1setOf(type3 keyword From Get-
+ | name (MAX))) Printer-
+ Supported-Values
+
+ job-sheets-supported (1setOf(type3 keyword | From Get-
+ name(MAX))) Printer-
+ Supported-Values
+
+ multiple-document-handling-supported (1setOf From Get-
+ type2 keyword) Printer-
+ Supported-Values
+
+ copies-supported (rangeOfInteger(1:MAX)) From Get-
+ Printer-
+ Supported-Values
+
+ finishings-supported (1setOf type2 enum) From Get-
+ Printer-
+ Supported-Values
+
+ page-ranges-supported (boolean) From Get-
+ Printer-
+ Supported-Values
+
+ sides-supported (1setOf type2 keyword) From Get-
+ Printer-
+ Supported-Values
+
+ number-up-supported (1setOf (integer(1:MAX) | From Get-
+ rangeOfInteger(1:MAX))) Printer-
+ Supported-Values
+
+ orientation-requested-supported (1setOf type2 From Get-
+ enum) Printer-
+ Supported-Values
+
+ media-supported (1setOf (type3 keyword | From Get-
+ name(MAX))) Printer-
+ Supported-Values
+
+ printer-resolution-supported (1setOf From Get-
+ resolution) Printer-
+ Supported-Values
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 55]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Printer Job Template Attributes Values allowed
+ for Set
+
+
+ print-quality-supported (1setOf type2 enum) From Get-
+ Printer-
+ Supported-Values
+
+ media-ready (type3 keyword | name(MAX)) From Get-
+ Printer-
+ Supported-Values
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 56]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 9 - Values allowed for Printer Description Attributes in the
+ Set-Printer-Attributes Operation
+
+
+
+ Printer Description Attributes Values allowed for
+ Set
+
+
+ printer-uri-supported (1setOf uri) READ-ONLY
+
+ uri-authentication-supported (1setOf type2 READ-ONLY
+ keyword)
+
+ uri-security-supported (1setOf type2 READ-ONLY
+ keyword)
+
+ printer-xri-supported (1setOf collection)
+ member attributes:
+
+ xri-uri (uri) any uriScheme of
+ "xri-uri-scheme-
+ supported" from
+ Get-Printer-
+ Attributes
+
+ xri-authentication (1setOf type2 keyword) any keyword of
+ "xri-
+ authentication-
+ supported" from
+ Get-Printer-
+ Attributes
+
+ xri-security (1setOf type2 keyword) any keyword of
+ "xri-security-
+ supported" from
+ Get-Printer-
+ Attributes
+
+ xri-uri-scheme-supported (1setOf uriScheme) READ-ONLY
+
+ xri-authentication-supported (1setOf type2 READ-ONLY
+ keyword)
+
+ xri-security-supported (1setOf type2 READ-ONLY
+ keyword)
+
+ printer-name (name(127)) Any name(127)
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 57]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Printer Description Attributes Values allowed for
+ Set
+
+
+ printer-location (text(127)) Any text(127)
+
+ printer-info (text(127)) Any text(127)
+
+ printer-more-info (uri) Any uri
+
+ printer-driver-installer (uri) Any uri
+
+ printer-make-and-model (text(127)) Any text(127)
+
+ printer-more-info-manufacturer (uri) Any uri
+
+ printer-state (type1 enum) READ-ONLY
+
+ printer-state-reasons (1setOf type2 READ-ONLY
+ keyword)
+
+ printer-state-message (text(MAX)) READ-ONLY
+
+ ipp-versions-supported (1setOf type2 From Get-Printer-
+ keyword) Supported-Values
+
+ operations-supported (1setOf type2 enum) From Get-Printer-
+ Supported-Values
+
+ multiple-document-jobs-supported (boolean) From Get-Printer-
+ Supported-Values
+
+ charset-configured (charset) Any of "xxx-
+ supported", use
+ "charset-supported"
+
+ charset-supported (1setOf charset) From Get-Printer-
+ Supported-Values
+
+ natural-language-configured Any of "xxx-
+ (naturalLanguage) supported", use
+ "generated-natural-
+ language-supported"
+
+ generated-natural-language-supported From Get-Printer-
+ (1setOf naturalLanguage) Supported-Values
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 58]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Printer Description Attributes Values allowed for
+ Set
+
+
+ document-format-default (mimeMediaType) Any of "xxx-
+ supported"
+
+ document-format-supported (1setOf From Get-Printer-
+ mimeMediaType) Supported-Values
+
+ printer-is-accepting-jobs (boolean) READ-ONLY
+
+ queued-job-count (integer(0:MAX)) READ-ONLY
+
+ printer-message-from-operator (text(127)) Any text(127)
+
+ color-supported (boolean) From Get-Printer-
+ Supported-Values
+
+ reference-uri-schemes-supported (1setOf From Get-Printer-
+ uriScheme) Supported-Values
+
+ pdl-override-supported (type2 keyword) From Get-Printer-
+ Supported-Values
+
+ printer-up-time (integer(1:MAX)) READ-ONLY
+
+ printer-current-time (dateTime) Any dateTime **
+
+ multiple-operation-time-out any positive
+ (integer(1:MAX)) integer
+
+ compression-supported (1setOf type3 From Get-Printer-
+ keyword) Supported-Values
+
+ job-k-octets-supported From Get-Printer-
+ (rangeOfInteger(0:MAX)) Supported-Values
+
+ job-impressions-supported From Get-Printer-
+ (rangeOfInteger(0:MAX)) Supported-Values
+
+ job-media-sheets-supported From Get-Printer-
+ (rangeOfInteger(0:MAX)) Supported-Values
+
+ pages-per-minute (integer(0:MAX)) READ-ONLY
+
+ pages-per-minute-color (integer(0:MAX)) READ-ONLY
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 59]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Printer Description Attributes Values allowed for
+ Set
+
+
+ printer-settable-attributes-supported From Get-Printer-
+ (1setOf type2 keyword) Supported-Values
+
+ job-settable-attributes-supported (1setOf From Get-Printer-
+ type2 keyword) Supported-Values
+
+ document-format-varying-attributes (1setOf READ-ONLY
+ type2 keyword)
+
+ printer-message-time (integer(MIN:MAX)) READ-ONLY
+
+ printer-message-date-time(dateTime) READ-ONLY
+
+
+ ** - The "printer-current-time" (dateTime) attribute is settable in
+ order to allow an administrator to correct an incorrect dateTime or
+ time zone.
+
+
+16 Appendix B: Attributes returned from Get-Printer-Supported-Values
+
+
+ This Appendix is a normative part of this document and lists all the
+ attributes that are possible for an implementation to return in a
+ Get-Printer-Supported-Values response, i.e., all the "xxx-supported"
+ attributes that can be supplied in a Set-Printer-Attributes request.
+ READ-ONLY attributes MUST NOT be returned in a Get-Printer-Supported-
+ Values response and are indicated in the tables as "READ-ONLY - MUST
+ NOT be returned."
+
+
+ For the following attributes, the value allowed by the Set-Printer-
+ Attributes operation MUST be a single integer value in the range
+ specified by the value returned by the Get-Printer-Supported-Values
+ operation.
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 60]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 10 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values
+
+
+
+ Printer Job Template Attributes Values Returned
+
+
+ job-priority-supported (integer(1:100)) rangeOfInteger(1:100)
+
+
+
+ For the following attributes, the value allowed by the Set-Printer-
+ Attributes operation MUST be a single rangeOfInteger value whose
+ bounds do not exceed those of the range specified by the value
+ returned by the Get-Printer-Supported-Values operation.
+
+ Table 11 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values
+
+
+
+ Printer Job Template Attributes Values Returned
+
+
+ copies-supported (rangeOfInteger(1:MAX)) rangeOfInteger(1:MAX)
+
+
+
+
+
+ The following table has the same criteria as the last, but is for
+ Printer Description attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 61]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 12 - Printer Description Attributes returned from Get-Printer-
+ Supported-Values
+
+
+
+ Printer Description Attributes Values allowed for Set
+
+
+ job-k-octets-supported rangeOfInteger(0:MAX)
+ (rangeOfInteger(0:MAX))
+
+ job-impressions-supported rangeOfInteger(0:MAX)
+ (rangeOfInteger(0:MAX))
+
+ job-media-sheets-supported rangeOfInteger(0:MAX)
+ (rangeOfInteger(0:MAX))
+
+
+
+ For the following attributes, the value allowed by the Set-Printer-
+ Attributes operation MUST be one or more integers and rangeOfInteger
+ values, such that the integer values described by these integers and
+ rangeOfInteger is the same as or a subset of the integers described
+ by the integers and rangeOf Integer of value returned by the Get-
+ Printer-Supported-Values operation.
+
+ Table 13 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values
+
+
+
+ Printer Job Template Attributes Values Returned
+
+
+ number-up-supported (1setOf (integer(1:MAX) 1setOf
+ | rangeOfInteger(1:MAX))) (integer(1:MAX) |
+ rangeOfInteger(1:MA
+ X))
+
+
+
+ For the following attributes, the value allowed by the Set-Printer-
+ Attributes operation MUST be one or more values, where each such
+ value matches a value returned by the Get-Printer-Supported-Values
+ operation. A keyword, enum, boolean, charset, naturalLanguage,
+ uriScheme, mimeMediaType or resolution value matches if it is equal.
+ For Job Template attributes with the attribute syntax 'type3 keyword
+ | name', any 'name' attribute syntax value matches the 'admin-define'
+ out-of-band value, if the implementation allows the administrator to
+ set any name values for the attribute.
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 62]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 14 - Printer Job Template Attributes returned from Get-Printer-
+ Supported-Values
+
+
+
+ Printer Job Template Attributes Values Returned
+
+
+ job-hold-until-supported (1setOf(type3 1setOf (type3
+ keyword | name (MAX))) keyword | 'admin-
+ define')
+
+ job-sheets-supported (1setOf(type3 keyword 1setOf (type3
+ | name(MAX))) keyword | 'admin-
+ define')
+
+ multiple-document-handling-supported 1setOf type2
+ (1setOf type2 keyword) keyword
+
+ finishings-supported (1setOf type2 enum) 1setOf type2 enum
+
+ page-ranges-supported (boolean) 1setOf boolean **
+
+ sides-supported (1setOf type2 keyword) 1setOf type2
+ keyword
+
+ orientation-requested-supported (1setOf 1setOf type2 enum
+ type2 enum)
+
+ media-supported (1setOf (type3 keyword | 1setOf (type3
+ name(MAX))) keyword | 'admin-
+ define')
+
+ printer-resolution-supported (1setOf 1setOf resolution
+ resolution)
+
+ print-quality-supported (1setOf type2 enum) 1setOf type2 enum
+
+
+ ** Note: the Get-Printer-Supported-Values returns a '1setOf boolean'
+ so that all possible values are indicated, while Get-Printer-
+ Attributes returns only a single 'boolean' value.
+
+
+ The following table has the same criteria as the last, but is for
+ Printer Description attributes.
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 63]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ Table 15 - Printer Description Attributes returned from Get-Printer-
+ Supported-Values
+
+
+
+ Printer Description Attributes Values allowed for
+ Set
+
+
+ printer-uri-supported (1setOf uri) READ-ONLY - MUST
+ NOT be returned
+
+ uri-authentication-supported (1setOf type2 READ-ONLY - MUST
+ keyword) NOT be returned
+
+ uri-security-supported (1setOf type2 READ-ONLY - MUST
+ keyword) NOT be returned
+
+ xri-printer-supported (1setOf collection) MUST NOT be
+ returned; see next
+ three attributes
+ returned with Get-
+ Printer-Attributes:
+
+ xri-uri-scheme-supported (1setOf uriScheme) READ-ONLY - MUST
+ NOT be returned
+
+ xri-authentication-supported (1setOf type2 READ-ONLY - MUST
+ keyword) NOT be returned
+
+ xri-security-supported (1setOf type2 READ-ONLY - MUST
+ keyword) NOT be returned
+
+ ipp-versions-supported (1setOf type2 1setOf type2
+ keyword) keyword
+
+ operations-supported (1setOf type2 enum) 1setOf type2
+ keyword
+
+ multiple-document-jobs-supported (boolean) 1setOf boolean **
+
+ charset-supported (1setOf charset) 1setOf charset
+
+ generated-natural-language-supported 1setOf
+ (1setOf naturalLanguage) naturalLanguage
+
+ document-format-supported (1setOf 1setOf
+ mimeMediaType) mimeMediaType
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 64]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+
+
+ Printer Description Attributes Values allowed for
+ Set
+
+
+ color-supported (boolean) 1setOf boolean **
+
+ reference-uri-schemes-supported (1setOf 1setOf uriScheme
+ uriScheme)
+
+ pdl-override-supported (type2 keyword) 1setOf type2
+ keyword **
+
+ compression-supported (1setOf type3 1setOf type3
+ keyword) keyword
+
+ printer-settable-attributes-supported 1setOf type2
+ (1setOf type2 keyword) keyword
+
+ job-settable-attributes-supported (1setOf 1setOf type2
+ type2 keyword) keyword
+
+
+ ** Note: the Get-Printer-Supported-Values returns a '1setOf X' so
+ that all possible values are indicated, while Get-Printer-Attributes
+ returns only a single 'X' value.
+
+
+
+
+17 Appendix C: Full Copyright Statement
+
+
+ Copyright (C) The Internet Society (1998,1999,2000,2001). 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
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 65]
+\f
+
+INTERNET-DRAFT IPP: Job and Printer Set Operations January 22, 2001
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et al. Expires: July 22, 2001 [Page 66]
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT
+<draft-ietf-ipp-job-prog-02.txt> T. Hastings
+Category: standards track Xerox Corporation
+ H. Lewis
+ IBM Printing Company
+ R. Bergman
+ Hitachi Koki Imaging Solutions
+ January 23, 2001
+
+ Internet Printing Protocol (IPP):
+ Job Progress Attributes
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Status of this Memo:
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+Abstract
+ This document defines four new Job Description attributes for
+ monitoring job progress to be registered as extensions to IPP/1.0
+ [RFC2566] and IPP/1.1 [RFC2911]. These attributes are drawn from the
+ PWG Job Monitoring MIB [rfc2707]. The new Job Description attributes
+ are:
+
+ "job-collation-type" (type2 enum)
+ "sheet-completed-copy-number" (integer(0:MAX))
+ "sheet-completed-document-number" (integer(0:MAX))
+ "impressions-completed-current-copy" (integer(0:MAX))
+
+ This document also defines a new "sheet-collate" Job Template
+ attribute to control sheet collation and to help with the
+ interpretation of the job progress attributes. These new attributes
+ may also be used by themselves in combination with the IPP/1.1 "job-
+ impressions-completed" attribute as useful job progress monitoring
+ attributes and/or may be passed in an IPP Notification (see [ipp-
+ ntfy]).
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 1]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
+ Mapping between LPD and IPP Protocols [RFC2569]
+ Internet Printing Protocol/1.0 & 1.1: Event Notification
+ Specification [ipp-ntfy]
+ The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that
+ are satisfied in IPP/1.0. A few OPTIONAL operator operations have
+ been added to IPP/1.1.
+
+ The "Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol" document describes IPP from a high level
+ view, defines a roadmap for the various documents that form the suite
+ of IPP specification documents, and gives background and rationale
+ for the IETF working group's major decisions.
+
+ The "Internet Printing Protocol/1.1: Model and Semantics" document
+ describes a simplified model with abstract objects, their attributes,
+ and their operations that are independent of encoding and transport.
+ It introduces a Printer and a Job object. The Job object optionally
+ supports multiple documents per Job. It also addresses security,
+ internationalization, and directory issues.
+
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1 [RFC2616]. It defines the
+ encoding rules for a new Internet MIME media type called
+ "application/ipp". This document also defines the rules for
+ transporting over HTTP a message body whose Content-Type is
+ "application/ipp". This document defines a new scheme named 'ipp'
+ for identifying IPP printers and jobs.
+
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them understand IPP/1.1 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.
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 2]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ The "Mapping between LPD and IPP Protocols" document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+ The "Event Notification Specification" document defines OPTIONAL
+ operations that allow a client to subscribe to printing related
+ events. Subscriptions include "Per-Job subscriptions" and "Per-
+ Printer subscriptions". Subscriptions are modeled as Subscription
+ objects. Four other operations are defined for subscription objects:
+ get attributes, get subscriptions, renew a subscription, and cancel a
+ subscription.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 3]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+
+TABLE OF CONTENTS
+
+ 1 New Job Template attribute......................................5
+ 1.1 sheet-collate (type2 keyword) ................................5
+
+ 2 IPP Job Description attributes for monitoring Job Progress......8
+ 2.1 job-collation-type (type2 enum) .............................11
+ 2.2 sheet-completed-copy-number (integer(0:MAX)) ................12
+ 2.3 sheet-completed-document-number (integer(0:MAX)) ............13
+ 2.4 impressions-completed-current-copy (integer(0:MAX)) .........13
+
+ 3 Conformance Requirements.......................................13
+
+ 4 IANA Considerations............................................13
+ 4.1 Attribute Registrations .....................................14
+
+ 5 Internationalization Considerations............................14
+
+ 6 Security Considerations........................................14
+
+ 7 References.....................................................15
+
+ 8 Author's Addresses.............................................16
+
+ 9 Full Copyright Statement.......................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 4]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+
+
+
+
+1 New Job Template attribute
+
+
+1.1 sheet-collate (type2 keyword)
+
+ +===================+======================+=====================+
+ | Job Attribute |Printer: Default Value| Printer: Supported |
+ | | Attribute | Values Attribute |
+ +===================+======================+=====================+
+ | sheet-collate | sheet-collate-default| sheet-collate- |
+ | (type2 keyword) | (type2 keyword) | supported (1setOf |
+ | | | type2 keyword) |
+ +-------------------+----------------------+---------------------+
+ This attribute specifies whether or not the media sheets of each copy
+ of each printed document in a job are to be in sequence, when
+ multiple copies of the document are specified by the 'copies'
+ attribute.
+
+ Standard keyword values are:
+
+ 'uncollated': each print-stream sheet is printed a number of times
+ in succession equal to the value of the 'copies' attribute,
+ followed by the next print-stream sheet.
+
+ 'collated': each copy of each document is printed with the print-
+ stream sheets in sequence, followed by the next document copy.
+
+ For example, suppose a document produces two media sheets as output,
+ and "copies" is equal to '6', For the 'uncollated' case, six copies
+ of the first media sheet are printed followed by six copies of the
+ second media sheet. For the 'collated' case, one copy of each of the
+ six sheets are printed followed by another copy of each of the six
+ media sheets.
+
+ Whether the effect of sheet collation is achieved by placing copies
+ of a document in multiple output bins or in the same output bin with
+ implementation defined document separation is implementation
+ dependent. Also whether it is achieved by making multiple passes
+ over the job or by using an output sorter is implementation
+ dependent.
+
+ Note: IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911] is silent on whether
+ or not sheets within documents are collated. The "sheet-collate-
+ supported" Printer attribute permits a Printer object to indicate
+ whether or not it collates sheets with each document and whether it
+ allows the client to control sheet collation. An implementation is
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 5]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ able to indicate that it supports uncollated sheets, collated sheets,
+ or both, using the 'uncollated', 'collated', or both 'uncollated' and
+ 'collated' values, respectively.
+
+ This attribute is affected by "multiple-document-handling." The
+ "multiple-document-handling" attribute describes the collation of
+ documents, and the "sheet-collate" attribute describes the semantics
+ of collating individual pages within a document. To better explain
+ the interaction between these two attributes the term "set" is
+ introduced. A "set" is a logical boundary between the delivered
+ media sheets of a printed job. For-example, in the case of a ten
+ page single document with collated pages and a request for 50 copies,
+ each of the 50 printed copies of the document constitutes a "set."
+ In the above example if the pages were uncollated, then 50 copies of
+ each of the individual pages within the document would represent each
+ "set".
+
+ The following table describes the interaction of "sheet-collate" with
+ multiple document handling.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 6]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+
+
+ "sheet- "multiple- Semantics
+ collate" document-
+ handling"
+
+
+ 'collated' 'single- Each copy of the concatenated
+ document' documents, with their pages in
+ sequence, represents a "set."
+
+ 'collated' 'single- Each copy of the concatenated
+ document-new- documents, with their pages in
+ sheet' sequence, represents a "set."
+
+ 'collated' 'separate- Each copy of each separate
+ documents- document, with its pages in
+ collated- sequence, represents a "set."
+ copies'
+
+ 'collated' 'separate- Each copy of each separate
+ documents- document, with its pages in
+ uncollated- sequence, represents a "set."
+ copies
+
+ 'uncollated' 'single- Each media sheet of the document
+ document' is printed a number of times equal
+ to the "copies" attribute; which
+ constitutes a "set."
+
+ 'uncollated' 'single- Each media sheet of the
+ document-new- concatenated documents is printed
+ sheet' a number of times equal to the
+ "copies" attribute; which
+ constitutes a "set."
+
+ 'uncollated' 'separate- This is a degenerate case, and the
+ documents- printer object MUST reject the job
+ collated- and return the status, "client-
+ copies' error-conflicting-attributes."
+
+ 'uncollated' 'separate- This is a degenerate case, and the
+ documents- printer object MUST reject the job
+ uncollated- and return the status "client-
+ copies error-conflicting-attributes."
+
+
+
+ From the above table it is obvious that the implicit value of the
+ "sheet-collate" attribute in a printer that does not support the
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 7]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ "sheet-collate" attribute, is 'collated.' The semantics of
+ "multiple-document-handling" are otherwise nonsensical in the case
+ of separate documents.
+
+
+
+2 IPP Job Description attributes for monitoring Job Progress
+
+ The following IPP Job Description attributes are proposed to be added
+ to IPP through the type2 registration procedures. They are useful
+ for monitoring the progress of a job. They are also used at
+ attributes in the notification content in a notification report [ipp-
+ ntfy].
+
+ There are a number of Job Description attributes for monitoring the
+ progress of a job. These objects and attributes count the number of
+ K octets, impressions, sheets, and pages requested or completed. For
+ impressions and sheets, "completed" means stacked, unless the
+ implementation is unable to detect when each sheet is stacked, in
+ which case stacked is approximated when processing of each sheet
+ completes. There are objects and attributes for the overall job and
+ for the current copy of the document currently being stacked. For
+ the latter, the rate at which the various objects and attributes
+ count depends on the sheet and document collation of the job.
+
+ Consider the following four Job Description attributes that are used
+ to monitor the progress of a job's impressions:
+
+ 1."job-impressions-completed" - counts the total number of
+ impressions stacked for the job (see [RFC2911] section 4.3.18.2)
+
+ 2."impressions-completed-current-copy" - counts the number of
+ impressions stacked for the current document copy
+
+ 3."sheet-completed-copy-number" - identifies the number of the
+ copy for the current document being stacked where the first copy
+ is 1.
+
+ 4."sheet-completed-document-number" - identifies the current
+ document within the job that is being stacked where the first
+ document in a job is 1. NOTE: this attribute SHOULD NOT be
+ implemented for implementations that only support one document
+ per job.
+
+ For each of the three types of job collation, a job with three copies
+ of two documents (1, 2), where each document consists of 3
+ impressions, the four variables have the following values as each
+ sheet is stacked for one-sided printing:
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 8]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+
+"job-collation-type" = 'uncollated-sheets(3)'
+
+
+"job- "impressions- "sheet- "sheet-
+impressions- completed- completed- completed-
+completed" current-copy" copy-number" document-
+ number"
+
+ 0 0 0 0
+ 1 1 1 1
+ 2 1 2 1
+ 3 1 3 1
+ 4 2 1 1
+ 5 2 2 1
+ 6 2 3 1
+ 7 3 1 1
+ 8 3 2 1
+ 9 3 3 1
+ 10 1 1 2
+ 11 1 2 2
+ 12 1 3 2
+ 13 2 1 2
+ 14 2 2 2
+ 15 2 3 2
+ 16 3 1 2
+ 17 3 2 2
+ 18 3 3 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 9]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+
+"job-collation-type" = 'collated-documents(4)'
+
+
+ "job- "impressions- "sheet- "sheet-
+ impressions- completed- completed- completed-
+ completed" current-copy" copy- document-
+ number" number"
+
+
+ 0 0 0 0
+ 1 1 1 1
+ 2 2 1 1
+ 3 3 1 1
+ 4 1 1 2
+ 5 2 1 2
+ 6 3 1 2
+ 7 1 2 1
+ 8 2 2 1
+ 9 3 2 1
+ 10 1 2 2
+ 11 2 2 2
+ 12 3 2 2
+ 13 1 3 1
+ 14 2 3 1
+ 15 3 3 1
+ 16 1 3 2
+ 17 2 3 2
+ 18 3 3 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 10]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+
+"job-collation-type" = 'uncollated-documents(5)'
+
+ "job- "impressions- "sheet- "sheet-
+ impressions- completed- completed- completed-
+ completed" current-copy" copy- document-
+ number" number"
+
+
+ 0 0 0 0
+ 1 1 1 1
+ 2 2 1 1
+ 3 3 1 1
+ 4 1 2 1
+ 5 2 2 1
+ 6 3 2 1
+ 7 1 3 1
+ 8 2 3 1
+ 9 3 3 1
+ 10 1 1 2
+ 11 2 1 2
+ 12 3 1 2
+ 13 1 2 2
+ 14 2 2 2
+ 15 3 2 2
+ 16 1 3 2
+ 17 2 3 2
+ 18 3 3 2
+
+
+
+2.1 job-collation-type (type2 enum)
+
+ Job Collation includes sheet collation and document collation. Sheet
+ collation is defined to be the ordering of sheets within a document
+ copy. Document collation is defined to be ordering of document
+ copies within a multi-document job. The value of the "job-collation-
+ type" is affected by the value of the "sheet-collate" Job Template
+ attribute (see section 1.1), if supplied and supported.
+
+ The Standard enum values are:
+
+ '1' 'other': not one of the defined values
+
+ '2' 'unknown': the collation type is unknown
+
+ '3' 'uncollated-sheets': No collation of the sheets within each
+ document copy, i.e., each sheet of a document that is
+ to produce multiple copies is replicated before the
+ next sheet in the document is processed and stacked.
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 11]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ If the device has an output bin collator, the
+ 'uncollated-sheets(3)' value may actually produce
+ collated sheets as far as the user is concerned (in
+ the output bins). However, when the job collation is
+ the 'uncollated-sheets(3)' value, job progress is
+ indistinguishable to a monitoring application between
+ a device that has an output bin collator and one that
+ does not.
+
+ '4' 'collated-documents': Collation of the sheets within each
+ document copy is performed within the printing device
+ by making multiple passes over either the source or
+ an intermediate representation of the document. In
+ addition, when there are multiple documents per job,
+ the i'th copy of each document is stacked before the
+ j'th copy of each document, i.e., the documents are
+ collated within each job copy. For example, if a job
+ is submitted with documents, A and B, the job is made
+ available to the end user as: A, B, A, B, .... The
+ 'collated-documents(4)' value corresponds to the IPP
+ [RFC2911] 'separate-documents-collated-copies'
+ keyword value of the "multiple-document-handling"
+ attribute.
+
+ If the job's "copies" attribute is '1' (or not
+ supplied), then the "job-collation-type" attribute is
+ defined to be '4'.
+
+
+ '5' 'uncollated-documents': Collation of the sheets within each
+ document copy is performed within the printing device
+ by making multiple passes over either the source or
+ an intermediate representation of the document. In
+ addition, when there are multiple documents per job,
+ all copies of the first document in the job are
+ stacked before the any copied of the next document in
+ the job, i.e., the documents are uncollated within
+ the job. For example, if a job is submitted with
+ documents, A and B, the job is mad available to the
+ end user as: A, A, ..., B, B, .... The 'uncollated-
+ documents(5)' value corresponds to the IPP [RFC2911]
+ 'separate-documents-uncollated-copies' keyword value
+ of the "multiple-document-handling" attribute.
+
+2.2 sheet-completed-copy-number (integer(0:MAX))
+
+ The number of the copy being stacked for the current document. This
+ number starts at 0, is set to 1 when the first sheet of the first
+ copy for each document is being stacked and is equal to n where n is
+ the nth sheet stacked in the current document copy. If the value is
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 12]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ unknown, the Printer MUST return the 'unknown' out-of-band value (see
+ [RFC2911] section 4.1), rather than the -2 value used in some MIBs
+ [rfc2707].
+
+
+2.3 sheet-completed-document-number (integer(0:MAX))
+
+ The ordinal number of the document in the job that is currently being
+ stacked. This number starts at 0, increments to 1 when the first
+ sheet of the first document in the job is being stacked, and is equal
+ to n where n is the nth document in the job, starting with 1. If the
+ value is unknown, the Printer MUST return the 'unknown' out-of-band
+ value (see [RFC2911] section 4.1), rather than the -2 value used in
+ some MIBs [rfc2707].
+
+ Implementations that only support one document jobs SHOULD NOT
+ implement this attribute.
+
+
+2.4 impressions-completed-current-copy (integer(0:MAX))
+
+ The number of impressions completed by the device for the current
+ copy of the current document so far. For printing, the impressions
+ completed includes interpreting, marking, and stacking the output.
+ For other types of job services, the number of impressions completed
+ includes the number of impressions processed. If the value is
+ unknown, the Printer MUST return the 'unknown' out-of-band value (see
+ [RFC2911] section 4.1), rather than the -2 value used in some MIBs
+ [rfc2707].
+
+ This value SHALL be reset to 0 for each document in the job and for
+ each document copy.
+
+
+
+3 Conformance Requirements
+
+ This section summarizes the Conformance Requirements detailed in the
+ definitions in this document. In general each of the attributes
+ defined in this document are OPTIONAL for a Printer to support, so
+ that Printer implementers MAY implement any combination of
+ attributes.
+
+
+
+4 IANA Considerations
+
+ This section contains the exact information for IANA to add to the
+ IPP Registries according to the procedures defined in RFC 2911
+ [RFC2911] section 6.
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 13]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ Note to RFC Editors: Replace RFC NNNN below with the RFC number for
+ this document, so that it accurately reflects the content of the
+ information for the IANA Registry.
+
+
+4.1 Attribute Registrations
+
+ The attributes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.2 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attributes/
+
+ The registry entry will contain the following information:
+
+ Job Template attributes: Ref. Section:
+ sheet-collate (type2 keyword) RFC NNNN 1.1
+
+ Job Description attributes: Ref. Section:
+ job-collation-type (type2 enum) RFC NNNN 2.1
+ sheet-completed-copy-number (integer(0:MAX)) RFC NNNN 2.2
+ sheet-completed-document-number (integer(0:MAX))RFC NNNN 2.3
+ impressions-completed-current-copy (integer(0:MAX))
+ RFC NNNN 2.4
+
+
+
+
+5 Internationalization Considerations
+
+ The IPP extensions defined in this document require the same
+ internationalization considerations as any of the Job Template and
+ Job Descriptions attributes defined in IPP/1.1 [RFC2911].
+
+
+
+6 Security Considerations
+
+ The IPP extensions defined in this document require the same security
+ considerations as any of the Job Template attributes and Job
+ Descriptions attributes defined in IPP/1.1 [RFC2911].
+
+
+
+
+
+
+
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 14]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+7 References
+
+ [ipp-iig]
+
+ Hastings, T., Manros, C., "Internet Printing Protocol/1.1: draft-
+ ietf-ipp-implementers-guide-v11-01.txt, work in progress, May 9,
+ 2000.
+
+ [ipp-ntfy]
+
+ Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
+ Bergman, R., " IPP Event Notification Specification", <draft-ietf-
+ ipp-not-spec-04.txt>, work in progress, August 30, 2000.
+
+ [RFC2565]
+
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
+
+ [RFC2566]
+
+ deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
+ April 1999.
+
+ [RFC2567]
+
+ Wright, D., "Design Goals for an Internet Printing Protocol", RFC
+ 2567, April 1999.
+
+ [RFC2568]
+
+ Zilles, S., "Rationale for the Structure and Model and Protocol for
+ the Internet Printing Protocol", RFC 2568, April 1999.
+
+ [RFC2569]
+
+ Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
+ LPD and IPP Protocols", RFC 2569, April 1999.
+
+ [RFC2707]
+
+ Bergman, R., Hastings, T., Isaacson, S., Lewis, H. "PWG Job
+ Monitoring MIB - V1", RFC 2707, November, 1999.
+
+ [RFC2910]
+
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", RFC 2910, September, 2000.
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 15]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ [RFC2911]
+
+ deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
+ "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911,
+ September, 2000.
+
+
+
+8 Author's Addresses
+
+
+ Tom Hastings
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+
+
+ Harry Lewis
+ IBM
+ P.O. Box 1900
+ Boulder, CO 80301-9191
+
+ Phone: (303) 924-5337
+ FAX:
+ e-mail: harryl@us.ibm.com
+
+
+ Ron Bergman (Editor)
+ Hitachi Koki Imaging Solutions
+ 1757 Tapo Canyon Road
+ Simi Valley, CA 93063-3394
+
+ Phone: 805-578-4421
+ Fax: 805-578-4001
+ Email: rbergma@hitachi-hkis.com
+
+
+
+9 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). 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
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 16]
+\f
+
+INTERNET-DRAFT IPP: Job Progress Attributes January 23, 2001
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, Lewis, Bergman Expires July 23, 2001 [page 17]
+
Internet Printing Protocol Working Group Pat Fleming
INTERNET DRAFT IBM
-Expires 27 October 2000 Ken Jones
- Sun Microsystems
- Harry Lewis
+Expires 20 June 2001 Ken Jones
+ eStarCom
+[Target Category: Standards Track] Harry Lewis
IBM
Ira McDonald
High North Inc
- 27 April 2000
+ 20 December 2000
Internet Printing Protocol (IPP):
LDAP Schema for Printer Services
- <draft-ietf-ipp-ldap-printer-schema-01.txt>
+ <draft-ietf-ipp-ldap-printer-schema-04.txt>
Copyright (C) The Internet Society (2000). All Rights Reserved.
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
+ To view the list of Internet-Draft Shadow Directories, see
+ http://www.ietf.org/shadow.html.
Abstract
- This document defines a common printer schema for use with LDAP
- directories (a directory service supporting the Lightweight Directory
- Access Protocol (LDAP)). Using this common printer schema enables
- client applications to use LDAP to search for printers using
- application or user specified search criteria. Searches are defined
- based on the entry's type and attributes independent of the LDAP
- directory being used.
+ This document is a product of the Internet Printing Protocol Working
+ Group, chartered by the IETF. Comments should be sent to the
+ ipp@pwg.org mailing list and the principal editor
+ flemingp@us.ibm.com.
+
+ This document defines a common printer schema for use with directory
+ services that support the Lightweight Directory Access Protocol
+ (LDAP) [RFC 2251]. Using this common printer schema enables client
+ applications to use LDAP to search for printers using application or
+ user specified search criteria. Searches are defined based on the
+ entry's type and attributes independent of the LDAP directory being
+ used.
This document describes the LDAP schema, object classes and
attributes, for printers and printer services. This document uses
- the printer attributes defined in Appendix E. of [IPPMOD], the
+ the printer attributes defined in Appendix E of [RFC 2911], the
'printer:' service template defined in [SLPPRT], and the mapping
between SLP service advertisements and LDAP descriptions of services
- defined in [SLPLDAP] to define an LDAP printer schema.
+
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 1]
+\f
+Internet Draft LDAP Schema for Printer Services 20 December 2000
+
+ defined in [RFC 2926] to define an LDAP printer schema.
The goal of this document is to define a consistent schema to be used
by printers and print servers. The LDAP printer schema described in
this document MAY be used in part or whole.
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 1]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 2]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
Table of Contents
-1. Introduction ............................................... 4
-2. Terminology ................................................ 4
-3. Definition of Object Classes ............................... 5
- 3.1. slpServicePrinter ...................................... 6
- 3.2. printerAbstract ........................................ 6
- 3.3. printerService ......................................... 7
- 3.4. printerServiceAuxClass ................................. 7
- 3.5. printerIPP ............................................. 8
- 3.6. printerLPR ............................................. 8
-4. Definition of Attribute Types .............................. 9
- 4.1. printer-uri ............................................ 10
- 4.2. printer-xri-supported .................................. 10
- 4.3. printer-name ........................................... 11
- 4.4. printer-natural-language-configured .................... 12
- 4.5. printer-location ....................................... 12
- 4.6. printer-info ........................................... 12
- 4.7. printer-more-info ...................................... 13
- 4.8. printer-make-and-model ................................. 13
- 4.9. printer-ipp-versions-supported ......................... 13
- 4.10. printer-multiple-document-jobs-supported .............. 14
- 4.11. printer-charset-configured ............................ 14
- 4.12. printer-charset-supported ............................. 14
- 4.13. printer-generated-natural-language-supported .......... 15
- 4.14. printer-document-format-supported ..................... 15
- 4.15. printer-color-supported ............................... 15
- 4.16. printer-compression-supported ......................... 15
- 4.17. printer-pages-per-minute .............................. 16
- 4.18. printer-pages-per-minute-color ........................ 16
- 4.19. printer-finishings-supported .......................... 16
- 4.20. printer-number-up-supported ........................... 17
- 4.21. printer-sides-supported ............................... 17
- 4.22. printer-media-supported ............................... 17
- 4.23. printer-media-local-supported ......................... 17
- 4.24. printer-resolution-supported .......................... 18
- 4.25. printer-print-quality-supported ....................... 18
- 4.26. printer-job-priority-supported ........................ 18
- 4.27. printer-copies-supported .............................. 19
- 4.28. printer-job-k-octets-supported ........................ 19
- 4.29. printer-current-operator .............................. 19
+
+1. Introduction ............................................... 5
+2. Terminology ................................................ 5
+3. Definition of Object Classes ............................... 6
+ 3.1. slpServicePrinter ...................................... 7
+ 3.2. printerAbstract ........................................ 7
+ 3.3. printerService ......................................... 8
+ 3.4. printerServiceAuxClass ................................. 8
+ 3.5. printerIPP ............................................. 9
+ 3.6. printerLPR ............................................. 9
+4. Definition of Attribute Types .............................. 10
+ 4.1. printer-uri ............................................ 11
+ 4.2. printer-xri-supported .................................. 11
+ 4.3. printer-name ........................................... 12
+ 4.4. printer-natural-language-configured .................... 13
+ 4.5. printer-location ....................................... 13
+ 4.6. printer-info ........................................... 13
+ 4.7. printer-more-info ...................................... 14
+ 4.8. printer-make-and-model ................................. 14
+ 4.9. printer-ipp-versions-supported ......................... 14
+ 4.10. printer-multiple-document-jobs-supported .............. 15
+ 4.11. printer-charset-configured ............................ 15
+ 4.12. printer-charset-supported ............................. 15
+ 4.13. printer-generated-natural-language-supported .......... 16
+ 4.14. printer-document-format-supported ..................... 16
+ 4.15. printer-color-supported ............................... 16
+ 4.16. printer-compression-supported ......................... 16
+ 4.17. printer-pages-per-minute .............................. 17
+ 4.18. printer-pages-per-minute-color ........................ 17
+ 4.19. printer-finishings-supported .......................... 17
+ 4.20. printer-number-up-supported ........................... 18
+ 4.21. printer-sides-supported ............................... 18
+ 4.22. printer-media-supported ............................... 18
+ 4.23. printer-media-local-supported ......................... 18
+ 4.24. printer-resolution-supported .......................... 19
+ 4.25. printer-print-quality-supported ....................... 19
+ 4.26. printer-job-priority-supported ........................ 19
+ 4.27. printer-copies-supported .............................. 20
+ 4.28. printer-job-k-octets-supported ........................ 20
+ 4.29. printer-current-operator .............................. 20
4.30. printer-service-person ................................ 20
- 4.31. printer-delivery-orientation-supported ................ 20
- 4.32. printer-stacking-order-supported ...................... 20
- 4.33. printer-output-features-supported ..................... 20
-5. Definition of Syntaxes ..................................... 22
-6. IANA Considerations ........................................ 22
-7. Internationalization Considerations ........................ 22
-8. Security Considerations .................................... 22
-9. References ................................................. 22
-10. Acknowledgments ........................................... 23
-11. Author's Addresses ........................................ 24
-
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 2]
+ 4.31. printer-delivery-orientation-supported ................ 21
+ 4.32. printer-stacking-order-supported ...................... 21
+ 4.33. printer-output-features-supported ..................... 21
+ 4.34. printer-aliases ....................................... 22
+5. Definition of Syntaxes ..................................... 23
+6. IANA Considerations ........................................ 23
+7. Internationalization Considerations ........................ 23
+8. Security Considerations .................................... 23
+9. References ................................................. 23
+
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 3]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
-12. Full Copyright Statement .................................. 25
+10. Acknowledgments ........................................... 24
+11. Authors' Addresses ........................................ 25
+12. Full Copyright Statement .................................. 26
-
-
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 3]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 4]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
being developed to bring a standards based printing solution to the
Internet.
- Section 16 of [IPPMOD] describes a list of attributes which should be
- included in a general directory schema describing IPP print services.
- The syntax for each of these attributes is described in detail in
- [IPPMOD] and [SLPPRT]. This document will take these attributes and
- map them to LDAP attributes and object classes.
+ Section 16 of [RFC 2911] describes a list of attributes which should
+ be included in a general directory schema describing IPP print
+ services. The syntax for each of these attributes is described in
+ detail in [RFC 2911] and [SLPPRT]. This document will take these
+ attributes and map them to LDAP attributes and object classes.
This document defines several object classes to provide LDAP
applications with multiple options in defining printer information
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 4]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 5]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
Refer to section 4 for definition of attribute types referenced by
these object classes. We use names instead of OIDs in MUST and MAY
- for clarity. Some attribute names described in [IPPMOD] have been
- prefixed with 'printer-' as recommended in [SLPPRT] and [SLPLDAP].
+ for clarity. Some attribute names described in [RFC 2911] have been
+ prefixed with 'printer-' as recommended in [SLPPRT] and [RFC 2926].
For the object classes defined in this section, schema developers MAY
add to the list of MAY OIDs, but MUST NOT modify the list of MUST
definition SHOULD NOT be changed without having a new name and OID
assigned to it.
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 5]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 6]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
directory entries with SLP 'service:printer' abstract service type
information as defined in [SLPPRT]. This object class is derived
from 'slpService', the parent class for all SLP services, defined in
- [SLPLDAP].
+ [RFC 2926].
- ( <id-oc>.8
+ ( 1.3.18.0.2.6.254
NAME 'slpServicePrinter'
DESC 'Service Location Protocol (SLP) information.'
- SUP slpService
AUXILIARY
+ SUP slpService
)
printer attributes that are not specific to any one type of service,
protocol or operating system.
- ( <id-oc>.9
+ ( 1.3.18.0.2.6.258
NAME 'printerAbstract'
DESC 'Printer related information.'
ABSTRACT
printer-job-priority-supported $ printer-copies-supported $
printer-job-k-octets-supported $ printer-current-operator $
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 6]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 7]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
printer-service-person $
printer-delivery-orientation-supported $
for a given printer. Note that if the printer service changes
domains, printer-uri must be updated with the new domain name.
- ( <id-oc>.10
+ ( 1.3.18.0.2.6.255
NAME 'printerService'
DESC 'Printer information.'
+ STRUCTURAL
SUP printerAbstract
MAY ( printer-uri $ printer-xri-supported )
- STRUCTURAL
)
This class MUST be used with a structural class.
LDAP applications SHOULD use printer-uri as the naming attribute.
- That is, when using printerService, printer-uri SHOULD be used as the
- attribute type of the directory entry's relative distinguished name
- (RDN). printer-uri uniquely identifies each of the printer services
- for a given printer. Note that if the printer service changes
- domains, printer-uri must be updated with the new domain name.
+ That is, when using printerServiceAuxClass, printer-uri SHOULD be
+ used as the attribute type of the directory entry's relative
+ distinguished name (RDN). printer-uri uniquely identifies each of
+ the printer services for a given printer. Note that if the printer
+ service changes domains, printer-uri must be updated with the new
+ domain name.
- ( <id-oc>.11
+ ( 1.3.18.0.2.6.257
NAME 'printerServiceAuxClass'
DESC 'Printer information.'
- SUP printerAbstract
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 7]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 8]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
- MAY ( printer-uri $ printer-xri-supported )
AUXILIARY
+ SUP printerAbstract
+ MAY ( printer-uri $ printer-xri-supported )
)
printerService. It is used to extend structural classes with IPP
specific printer information.
- ( <id-oc>.12
+ ( 1.3.18.0.2.6.256
NAME 'printerIPP'
DESC 'Internet Printing Protocol (IPP) information.'
- SUP top
AUXILIARY
+ SUP top
MAY ( printer-ipp-versions-supported $
printer-multiple-document-jobs-supported )
)
structural class such as printerService. It is used to identify
directory entries that support LPR.
- ( <id-oc>.13
+ ( 1.3.18.0.2.6.253
NAME 'printerLPR'
DESC 'LPR information.'
- SUP top
AUXILIARY
+ SUP top
+ MUST ( printer-name )
+ MAY ( printer-aliases)
)
-
-
-
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 8]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 9]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
defined in section 3.
The following table is a summary of the attribute names referenced by
- this document and their corresponding names from [IPPMOD]. Some
- attribute names described in [IPPMOD] have been prefixed with
- 'printer-' as recommended in [SLPLDAP], to address the flat namespace
- for LDAP identifiers.
+ this document and their corresponding names from [RFC 2911]. Some
+ attribute names described in [RFC 2911] have been prefixed with
+ 'printer-' as recommended in [RFC 2926], to address the flat
+ namespace for LDAP identifiers.
- LDAP & SLP Printer Schema IPP Model [IPPMOD]
+ LDAP & SLP Printer Schema IPP Model [RFC 2911]
------------------------------ -------------------------------------
printer-uri
printer-xri-supported
printer-job-k-octets-supported job-k-octets-supported
printer-current-operator
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 9]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 10]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
printer-service-person
printer-delivery-orientation-supported
printer-stacking-order-supported
printer-output-features-supported
+ printer-aliases
In the following definitions, we use matching rule names instead of
OIDs for clarity. Note that if the printer information is not known,
attribute should set to the value of the registered URL of the
printer.
- ( <id-at>.1
+ ( 1.3.18.0.2.4.1140
NAME 'printer-uri'
DESC 'The URI supported by this printer.'
EQUALITY caseIgnoreMatch
Legal values of the 'auth' metaparameter include
'none' (no authentication for this URI)
'requesting-user-name' (from operation request)
- 'basic' (HTTP/1.1 Basic [RFC 2617])
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 10]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 11]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
+ 'basic' (HTTP/1.1 Basic [RFC 2617])
'digest' (HTTP/1.1 Basic, [RFC 2617])
'certificate' (from certificate)
per IPP Model [3] (extensions MAY also be used). A missing 'auth'
following example:
'uri=ipp://foo.com< auth=basic,digest< sec=tls,ssl3<'
- ( <id-at>.2
+ ( 1.3.18.0.2.4.1107
NAME 'printer-xri-supported'
DESC 'The unordered list of XRI (extended resource identifiers)
supported by this printer. Each member of the list consists of
contain characters that are not allowed in a conventional URI (which
conforms to [RFC 2396]).
- ( <id-at>.3
+ ( 1.3.18.0.2.4.1135
NAME 'printer-name'
DESC 'The site-specific administrative name of this printer, more
end-user friendly than a URI.'
SINGLE-VALUE
)
-
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 11]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 12]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
4.4. printer-natural-language-configured
- ( <id-at>.4
- NAME 'printer-generated-natural-language-configured'
+ ( 1.3.18.0.2.4.1119
+ NAME 'printer-natural-language-configured'
DESC 'The configured language in which error and status messages will
be generated (by default) by this printer. Also, a possible
language for printer string attributes set by operator, system
4.5. printer-location
- ( <id-at>.5
+ ( 1.3.18.0.2.4.1136
NAME 'printer-location'
DESC 'Identifies the location of the printer. This could include
things like: "in Room 123A", "second floor of building XYZ".'
4.6. printer-info
- ( <id-at>.6
+ ( 1.3.18.0.2.4.1139
NAME 'printer-info'
DESC 'Identifies the descriptive information about this printer.
This could include things like: "This printer can be used for
SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 12]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 13]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
SINGLE-VALUE
)
4.7. printer-more-info
- ( <id-at>.7
+ ( 1.3.18.0.2.4.1134
NAME 'printer-more-info'
DESC 'A URI used to obtain more information about this specific
printer. For example, this could be an HTTP type URI
4.8. printer-make-and-model
- ( <id-at>.8
+ ( 1.3.18.0.2.4.1138
NAME 'printer-make-and-model'
DESC 'Identifies the make and model of the device. The device
manufacturer may initially populate this attribute.'
4.9. printer-ipp-versions-supported
- ( <id-at>.9
+ ( 1.3.18.0.2.4.1133
NAME 'printer-ipp-versions-supported'
DESC 'Identifies the IPP protocol version(s) that this printer
supports, including major and minor versions, i.e., the version
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 13]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 14]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
4.10. printer-multiple-document-jobs-supported
- ( <id-at>.10
+ ( 1.3.18.0.2.4.1132
NAME 'printer-multiple-document-jobs-supported'
DESC 'Indicates whether or not the printer supports more than one
document per job, i.e., more than one Send-Document or
4.11. printer-charset-configured
- ( <id-at>.11
+ ( 1.3.18.0.2.4.1109
NAME 'printer-charset-configured'
DESC 'The configured charset in which error and status messages will
be generated (by default) by this printer. Also, a possible
of registration) and SHOULD NOT be dynamically refreshed
(subsequently).'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
SINGLE-VALUE
)
4.12. printer-charset-supported
- ( <id-at>.12
+ ( 1.3.18.0.2.4.1131
NAME 'printer-charset-supported'
DESC 'Identifies the set of charsets supported for attribute type
values of type Directory String for this directory entry. For
Legal values are defined by the IANA Registry of Coded
Character Sets and the preferred MIME name.'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
)
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 14]
+
+
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 15]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
4.13. printer-generated-natural-language-supported
- ( <id-at>.13
+ ( 1.3.18.0.2.4.1137
NAME 'printer-generated-natural-language-supported'
DESC 'Identifies the natural language(s) supported for this directory
entry. For example: "en-us" (US English) or "fr-fr" (French in
4.14. printer-document-format-supported
- ( <id-at>.14
+ ( 1.3.18.0.2.4.1130
NAME 'printer-document-format-supported'
DESC 'The possible document formats in which data may be interpreted
and printed by this printer. Legal values are MIME types come
from the IANA Registry of Internet Media Types.'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
)
4.15. printer-color-supported
- ( <id-at>.15
+ ( 1.3.18.0.2.4.1129
NAME 'printer-color-supported'
DESC 'Indicates whether this printer is capable of any type of color
printing at all, including highlight color.'
4.16. printer-compression-supported
- ( <id-at>.16
+ ( 1.3.18.0.2.4.1128
NAME 'printer-compression-supported'
DESC 'Compression algorithms supported by this printer. For example:
"deflate, gzip". Legal values include; "none", "deflate"
(public domain ZIP), "gzip" (GNU ZIP), "compress" (UNIX).'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 15]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 16]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
- )
4.17. printer-pages-per-minute
- ( <id-at>.17
+ ( 1.3.18.0.2.4.1127
NAME 'printer-pages-per-minute'
DESC 'The nominal number of pages per minute which may be output by
this printer (e.g., a simplex or black-and-white printer).
4.18. printer-pages-per-minute-color
- ( <id-at>.18
+ ( 1.3.18.0.2.4.1126
NAME 'printer-pages-per-minute-color'
DESC 'The nominal number of color pages per minute which may be
output by this printer (e.g., a simplex or color printer).
4.19. printer-finishings-supported
- ( <id-at>.19
+ ( 1.3.18.0.2.4.1125
NAME 'printer-finishings-supported'
DESC 'The possible finishing operations supported by this printer.
Legal values include; "none", "staple", "punch", "cover",
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
)
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 16]
+
+
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 17]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
4.20. printer-number-up-supported
- ( <id-at>.20
+ ( 1.3.18.0.2.4.1124
NAME 'printer-number-up-supported'
DESC 'The possible numbers of print-stream pages to impose upon a
single side of an instance of a selected medium. Legal values
4.21. printer-sides-supported
- ( <id-at>.21
+ ( 1.3.18.0.2.4.1123
NAME 'printer-sides-supported'
DESC 'The number of impression sides (one or two) and the two-sided
impression rotations supported by this printer. Legal values
include; "one-sided", "two-sided-long-edge",
"two-sided-short-edge".'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
)
4.22. printer-media-supported
- ( <id-at>.22
+ ( 1.3.18.0.2.4.1122
NAME 'printer-media-supported'
DESC 'The standard names/types/sizes (and optional color suffixes) of
the media supported by this printer. For example: "iso-a4",
10175, Document Printing Application (DPA), and any IANA
registered extensions.'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
)
4.23. printer-media-local-supported
- ( <id-at>.23
+ ( 1.3.18.0.2.4.1117
NAME 'printer-media-local-supported'
DESC 'Site-specific names of media supported by this printer, in the
- language in "printer-generated-natural-language-configured".
+ language in "printer-natural-language-configured".
+ For example: "purchasing-form" (site-specific name) as opposed
+ to (in "printer-media-supported"): "na-letter" (standard
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 17]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 18]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
- For example: "purchasing-form" (site-specific name) as opposed
- to (in "printer-media-supported"): "na-letter" (standard
keyword from ISO 10175).'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringMatch
4.24. printer-resolution-supported
- ( <id-at>.24
+ ( 1.3.18.0.2.4.1121
NAME 'printer-resolution-supported'
DESC 'List of resolutions supported for printing documents by this
printer. Each resolution value is a string with 3 fields:
4.25. printer-print-quality-supported
- ( <id-at>.25
+ ( 1.3.18.0.2.4.1120
NAME 'printer-print-quality-supported'
DESC 'List of print qualities supported for printing documents on
this printer. For example: "draft, normal". Legal values
include; "unknown", "draft", "normal", "high".'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
)
4.26. printer-job-priority-supported
- ( <id-at>.26
+ ( 1.3.18.0.2.4.1110
NAME 'printer-job-priority-supported'
DESC 'Indicates the number of job priority levels supported. An IPP
conformant printer which supports job priority must always
"100".'
EQUALITY integerMatch
ORDERING integerOrderingMatch
-
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 18]
-\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
-
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 19]
+\f
+Internet Draft LDAP Schema for Printer Services 20 December 2000
+
+
4.27. printer-copies-supported
- ( <id-at>.27
+ ( 1.3.18.0.2.4.1118
NAME 'printer-copies-supported'
DESC 'The maximum number of copies of a document that may be printed
as a single job. A value of "0" indicates no maximum limit. A
4.28. printer-job-k-octets-supported
- ( <id-at>.28
+ ( 1.3.18.0.2.4.1111
NAME 'printer-job-k-octets-supported'
DESC 'The maximum size in kilobytes (1,024 octets actually) incoming
print job that this printer will accept. A value of "0"
4.29. printer-current-operator
- ( <id-at>.29
+ ( 1.3.18.0.2.4.1112
NAME 'printer-current-operator'
DESC 'The name of the current human operator responsible for
operating this printer. It is suggested that this string
)
+4.30. printer-service-person
+ ( 1.3.18.0.2.4.1113
+ NAME 'printer-service-person'
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 19]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 20]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
-
+Internet Draft LDAP Schema for Printer Services 20 December 2000
-
-4.30. printer-service-person
-
- ( <id-at>.30
- NAME 'printer-service-person'
DESC 'The name of the current human service person responsible for
servicing this printer. It is suggested that this string
include information that would enable other humans to reach the
4.31. printer-delivery-orientation-supported
- ( <id-at>.31
+ ( 1.3.18.0.2.4.1114
NAME 'printer-delivery-orientation-supported'
DESC 'The possible delivery orientations of pages as they are printed
and ejected from this printer. Legal values include;
"unknown", "face-up", and "face-down".'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
)
4.32. printer-stacking-order-supported
- ( <id-at>.32
+ ( 1.3.18.0.2.4.1115
NAME 'printer-stacking-order-supported'
DESC 'The possible stacking order of pages as they are printed and
ejected from this printer. Legal values include; "unknown",
"first-to-last", "last-to-first".'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
)
4.33. printer-output-features-supported
- ( <id-at>.33
+ ( 1.3.18.0.2.4.1116
NAME 'printer-output-features-supported'
DESC 'The possible output features supported by this printer. Legal
values include; "unknown", "bursting", "decollating",
"page-collating", "offset-stacking".'
-
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 20]
-\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
-
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
)
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 21]
+\f
+Internet Draft LDAP Schema for Printer Services 20 December 2000
+
+4.34. printer-aliases
+ ( 1.3.18.0.2.4.1108
+ NAME 'printer-aliases'
+ DESC 'Site-specific administrative names of this printer in addition
+ the printer name specified for printer-name.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 21]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 22]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
particularly important that only administrators can modify entries
defined in this schema. For additional considerations of deploying
printers in an IPP environment the reader is referred to section 8 of
- [IPPMOD].
+ [RFC 2911].
By advertising the security methods for each supported printer URL
the printer may expose information useful to attackers. Suitable
9. References
- [IPPMOD] deBry, Hastings, Herriot, Isaacson, Powell. Internet
- Printing Protocol/1.1: Model and Semantics,
- <draft-ietf-ipp-model-v11-06.txt>, (work in progress), March 2000.
+ [SLPPRT] St. Pierre, Isaacson, McDonald. Definition Printer Abstract
+ Service Type v2.0, <draft-ietf-svrloc-printer-schema-06.txt>, March
+ 2000 (appoved and archived in the IANA SLP Template Registry:
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 22]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 23]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
-
- [SLPPRT] St. Pierre, Isaacson, McDonald. Definition of the Printer
- Abstract Service Type v2.0,
- <draft-ietf-svrloc-printer-schema-06.txt>, (work in progress), March
- 2000.
-
- [SLPLDAP] Kempf, Moats, St. Pierre. Conversion of LDAP Schemas to
- and from SLP Templates,
- <draft-ietf-svrloc-template-conversion-05.txt>, (work in progress),
- October 1999.
+ ftp://isi.edu/in-notes/iana/assignments/svrloc-templates/
+ in the file 'printer.2.0.en')
[RFC 1179] McLaughlin. Line Printer Daemon Protocol, RFC 1179,
August 1990.
[RFC 1766] Alvestrand. Tags for the Identification of Languages, RFC
- 1766. March 1995.
+ 1766, March 1995.
[RFC 2119] Bradner. Key words for use in RFCs to Indicate
Requirement Levels, RFC 2119, March 1997.
[RFC 2396] Berners-Lee, Fielding, Masinter. URI Generic Syntax, RFC
2396, August 1998.
+
+ [RFC 2911] deBry, Hastings, Herriot, Isaacson, Powell. Internet
+ Printing Protocol/1.1: Model and Semantics, RFC 2911, September 2000.
+
+ [RFC 2926] Kempf, Moats, St. Pierre. Conversion of LDAP Schemas to
+ and from SLP Templates, RFC 2926, September 2000.
(IBM) for their review comments and help in preparing this document.
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 23]
+
+
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 24]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
-11. Author's Addresses
+11. Authors' Addresses
+ Principal Editor:
Pat Fleming
IBM
Highway 52 N.
Rochester, MN 55901
USA
- Phone: 507-253-7583
+ Phone: +1 507-253-7583
EMail: flemingp@us.ibm.com
Ken Jones
- Sun Microsystems Inc.
- 17 Network Circle
- Menlo Park, CA 94025
+ eStarCom
+ 400 S McCaslin Blvd Suite 211
+ Louisville, CO 80027
USA
- Phone: +1 650 786 4164
- EMail: kenjones@eng.sun.com
+ Phone: +1 720-890-7507
+ EMail: kenjones@estarcom.com
Harry Lewis
IBM
6300 Diagonal Hwy
Boulder, CO 80301
USA
- Phone: 303-924-5337
+ Phone: +1 303-924-5337
EMail: harryl@us.ibm.com
Ira McDonald
221 Ridge Ave
Grand Marais, MI 49839
USA
- Phone: 906-494-2434 (or 2697)
+ Phone: +1 906-494-2434
Email: imcdonald@sharplabs.com
- Email: imcdonal@sdsp.mc.xerox.com
-
+ Email: imcdonald@crt.xerox.com
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 24]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 25]
\f
-Internet Draft LDAP Schema for Printer Services 27 April 2000
+Internet Draft LDAP Schema for Printer Services 20 December 2000
-Fleming, Jones, Lewis, McDonald Expires 27 October 2000 [Page 25]
+Fleming, Jones, Lewis, McDonald Expires 20 June 2001 [Page 26]
+++ /dev/null
-
-INTERNET-DRAFT
-draft-ietf-ipp-model-v11-07.txt
- R. deBry
- Utah Valley State College
- T. Hastings (editor)
- Xerox Corporation
- R. Herriot
- Xerox Corporation
- S. Isaacson
- Novell, Inc.
- P. Powell
- Astart Technologies
- May 22, 2000
-
- Internet Printing Protocol/1.1: Model and Semantics
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
- 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 describes a
-simplified model consisting of abstract objects, their attributes, and
-their operations that is independent of encoding and transport. The
-model consists of a Printer and a Job object. A Job optionally supports
-multiple documents. IPP 1.1 semantics allow end-users and operators to
-query printer capabilities, submit print jobs, inquire about the status
-of print jobs and printers, cancel, hold, release, and restart print
-jobs. IPP 1.1 semantics allow operators to pause, resume, and purge
-(jobs from) Printer objects. This document also addresses security,
-internationalization, and directory issues.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 1]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting over HTTP a message
-body whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 2]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- Table of Contents
-
-
-1. Introduction 9
- 1.1 Simplified Printing Model 10
-
-2. IPP Objects 12
- 2.1 Printer Object 13
- 2.2 Job Object 15
- 2.3 Object Relationships 16
- 2.4 Object Identity 17
-
-3. IPP Operations 19
- 3.1 Common Semantics 20
- 3.1.1 Required Parameters 20
- 3.1.2 Operation IDs and Request IDs 21
- 3.1.3 Attributes 21
- 3.1.4 Character Set and Natural Language Operation Attributes 23
- 3.1.4.1 Request Operation Attributes 24
- 3.1.4.2 Response Operation Attributes 27
- 3.1.5 Operation Targets 28
- 3.1.6 Operation Response Status Codes and Status Messages 29
- 3.1.6.1 "status-code" (type2 enum) 29
- 3.1.6.2 "status-message" (text(255)) 30
- 3.1.6.3 "detailed-status-message" (text(MAX)) 31
- 3.1.6.4 "document-access-error" (text(MAX)) 31
- 3.1.7 Unsupported Attributes 31
- 3.1.8 Versions 33
- 3.1.9 Job Creation Operations 35
- 3.2 Printer Operations 37
- 3.2.1 Print-Job Operation 37
- 3.2.1.1 Print-Job Request 37
- 3.2.1.2 Print-Job Response 41
- 3.2.2 Print-URI Operation 43
- 3.2.3 Validate-Job Operation 44
- 3.2.4 Create-Job Operation 45
- 3.2.5 Get-Printer-Attributes Operation 45
- 3.2.5.1 Get-Printer-Attributes Request 46
- 3.2.5.2 Get-Printer-Attributes Response 48
- 3.2.6 Get-Jobs Operation 49
- 3.2.6.1 Get-Jobs Request 49
- 3.2.6.2 Get-Jobs Response 50
- 3.2.7 Pause-Printer Operation 52
- 3.2.7.1 Pause-Printer Request 53
- 3.2.7.2 Pause-Printer Response 53
- 3.2.8 Resume-Printer Operation 54
- 3.2.9 Purge-Jobs Operation 55
- 3.3 Job Operations 55
- 3.3.1 Send-Document Operation 55
- 3.3.1.1 Send-Document Request 57
- 3.3.1.2 Send-Document Response 58
- 3.3.2 Send-URI Operation 58
- 3.3.3 Cancel-Job Operation 59
- 3.3.3.1 Cancel-Job Request 60
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 3]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 3.3.3.2 Cancel-Job Response 60
- 3.3.4 Get-Job-Attributes Operation 61
- 3.3.4.1 Get-Job-Attributes Request 62
- 3.3.4.2 Get-Job-Attributes Response 62
- 3.3.5 Hold-Job Operation 63
- 3.3.5.1 Hold-Job Request 64
- 3.3.5.2 Hold-Job Response 65
- 3.3.6 Release-Job Operation 65
- 3.3.7 Restart-Job Operation 66
- 3.3.7.1 Restart-Job Request 67
- 3.3.7.2 Restart-Job Response 68
-
-4. Object Attributes 68
- 4.1 Attribute Syntaxes 69
- 4.1.1 'text' 70
- 4.1.1.1 'textWithoutLanguage' 70
- 4.1.1.2 'textWithLanguage' 71
- 4.1.2 'name' 71
- 4.1.2.1 'nameWithoutLanguage' 72
- 4.1.2.2 'nameWithLanguage' 72
- 4.1.2.3 Matching 'name' attribute values 73
- 4.1.3 'keyword' 74
- 4.1.4 'enum' 74
- 4.1.5 'uri' 75
- 4.1.6 'uriScheme' 75
- 4.1.7 'charset' 76
- 4.1.8 'naturalLanguage' 76
- 4.1.9 'mimeMediaType' 77
- 4.1.9.1 Application/octet-stream -- Auto-Sensing the document
- format 77
- 4.1.10 'octetString' 78
- 4.1.11 'boolean' 78
- 4.1.12 'integer' 78
- 4.1.13 'rangeOfInteger' 79
- 4.1.14 'dateTime' 79
- 4.1.15 'resolution' 79
- 4.1.16 '1setOf X' 79
- 4.2 Job Template Attributes 80
- 4.2.1 job-priority (integer(1:100)) 83
- 4.2.2 job-hold-until (type3 keyword | name (MAX)) 84
- 4.2.3 job-sheets (type3 keyword | name(MAX)) 84
- 4.2.4 multiple-document-handling (type2 keyword) 85
- 4.2.5 copies (integer(1:MAX)) 86
- 4.2.6 finishings (1setOf type2 enum) 86
- 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 88
- 4.2.8 sides (type2 keyword) 89
- 4.2.9 number-up (integer(1:MAX)) 90
- 4.2.10 orientation-requested (type2 enum) 90
- 4.2.11 media (type3 keyword | name(MAX)) 92
- 4.2.12 printer-resolution (resolution) 92
- 4.2.13 print-quality (type2 enum) 92
- 4.3 Job Description Attributes 93
- 4.3.1 job-uri (uri) 95
- 4.3.2 job-id (integer(1:MAX)) 95
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 4]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 4.3.3 job-printer-uri (uri) 95
- 4.3.4 job-more-info (uri) 96
- 4.3.5 job-name (name(MAX)) 96
- 4.3.6 job-originating-user-name (name(MAX)) 96
- 4.3.7 job-state (type1 enum) 96
- 4.3.7.1 Forwarding Servers 99
- 4.3.7.2 Partitioning of Job States 99
- 4.3.8 job-state-reasons (1setOf type2 keyword) 100
- 4.3.9 job-state-message (text(MAX)) 104
- 4.3.10 job-detailed-status-messages (1setOf text(MAX)) 104
- 4.3.11 job-document-access-errors (1setOf text(MAX)) 104
- 4.3.12 number-of-documents (integer(0:MAX)) 104
- 4.3.13 output-device-assigned (name(127)) 105
- 4.3.14 Event Time Job Description Attributes 105
- 4.3.14.1 time-at-creation (integer(MIN:MAX)) 106
- 4.3.14.2 time-at-processing (integer(MIN:MAX)) 106
- 4.3.14.3 time-at-completed (integer(MIN:MAX)) 106
- 4.3.14.4 job-printer-up-time (integer(1:MAX)) 106
- 4.3.14.5 date-time-at-creation (dateTime) 106
- 4.3.14.6 date-time-at-processing (dateTime) 107
- 4.3.14.7 date-time-at-completed (dateTime) 107
- 4.3.15 number-of-intervening-jobs (integer(0:MAX)) 107
- 4.3.16 job-message-from-operator (text(127)) 107
- 4.3.17 Job Size Attributes 107
- 4.3.17.1 job-k-octets (integer(0:MAX)) 107
- 4.3.17.2 job-impressions (integer(0:MAX)) 108
- 4.3.17.3 job-media-sheets (integer(0:MAX)) 108
- 4.3.18 Job Progress Attributes 108
- 4.3.18.1 job-k-octets-processed (integer(0:MAX)) 109
- 4.3.18.2 job-impressions-completed (integer(0:MAX)) 109
- 4.3.18.3 job-media-sheets-completed (integer(0:MAX)) 109
- 4.3.19 attributes-charset (charset) 109
- 4.3.20 attributes-natural-language (naturalLanguage) 110
- 4.4 Printer Description Attributes 110
- 4.4.1 printer-uri-supported (1setOf uri) 112
- 4.4.2 uri-authentication-supported (1setOf type2 keyword) 112
- 4.4.3 uri-security-supported (1setOf type2 keyword) 113
- 4.4.4 printer-name (name(127)) 115
- 4.4.5 printer-location (text(127)) 115
- 4.4.6 printer-info (text(127)) 115
- 4.4.7 printer-more-info (uri) 115
- 4.4.8 printer-driver-installer (uri) 115
- 4.4.9 printer-make-and-model (text(127)) 115
- 4.4.10 printer-more-info-manufacturer (uri) 116
- 4.4.11 printer-state (type1 enum) 116
- 4.4.12 printer-state-reasons (1setOf type2 keyword) 116
- 4.4.13 printer-state-message (text(MAX)) 119
- 4.4.14 ipp-versions-supported (1setOf type2 keyword) 119
- 4.4.15 operations-supported (1setOf type2 enum) 119
- 4.4.16 multiple-document-jobs-supported (boolean) 120
- 4.4.17 charset-configured (charset) 120
- 4.4.18 charset-supported (1setOf charset) 121
- 4.4.19 natural-language-configured (naturalLanguage) 121
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 5]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 4.4.20 generated-natural-language-supported (1setOf naturalLanguage)
- 121
- 4.4.21 document-format-default (mimeMediaType) 122
- 4.4.22 document-format-supported (1setOf mimeMediaType) 122
- 4.4.23 printer-is-accepting-jobs (boolean) 122
- 4.4.24 queued-job-count (integer(0:MAX)) 122
- 4.4.25 printer-message-from-operator (text(127)) 122
- 4.4.26 color-supported (boolean) 122
- 4.4.27 reference-uri-schemes-supported (1setOf uriScheme) 123
- 4.4.28 pdl-override-supported (type2 keyword) 123
- 4.4.29 printer-up-time (integer(1:MAX)) 123
- 4.4.30 printer-current-time (dateTime) 124
- 4.4.31 multiple-operation-time-out (integer(1:MAX)) 124
- 4.4.32 compression-supported (1setOf type3 keyword) 125
- 4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX)) 125
- 4.4.34 job-impressions-supported (rangeOfInteger(0:MAX)) 125
- 4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX)) 125
- 4.4.36 pages-per-minute (integer(0:MAX)) 126
- 4.4.37 pages-per-minute-color (integer(0:MAX)) 126
-
-5. Conformance 126
- 5.1 Client Conformance Requirements 127
- 5.2 IPP Object Conformance Requirements 128
- 5.2.1 Objects 128
- 5.2.2 Operations 128
- 5.2.3 IPP Object Attributes 129
- 5.2.4 Versions 129
- 5.2.5 Extensions 130
- 5.2.6 Attribute Syntaxes 130
- 5.2.7 Security 130
- 5.3 Charset and Natural Language Requirements 131
-
-6. IANA Considerations 131
- 6.1 Typed 'keyword' and 'enum' Extensions 132
- 6.2 Attribute Extensibility 134
- 6.3 Attribute Syntax Extensibility 134
- 6.4 Operation Extensibility 135
- 6.5 Attribute Group Extensibility 135
- 6.6 Status Code Extensibility 135
- 6.7 Out-of-band Attribute Value Extensibility 136
- 6.8 Registration of MIME types/sub-types for document-formats 136
- 6.9 Registration of charsets for use in 'charset' attribute values
- 136
-
-7. Internationalization Considerations 137
-
-8. Security Considerations 140
- 8.1 Security Scenarios 141
- 8.1.1 Client and Server in the Same Security Domain 141
- 8.1.2 Client and Server in Different Security Domains 141
- 8.1.3 Print by Reference 141
- 8.2 URIs in Operation, Job, and Printer attributes 141
- 8.3 URIs for each authentication mechanisms 142
- 8.4 Restricted Queries 143
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 6]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 8.5 Operations performed by operators and system administrators 143
- 8.6 Queries on jobs submitted using non-IPP protocols 143
-
-9. References 144
-
-10. Author's Address 147
-
-11. Formats for IPP Registration Proposals 151
- 11.1 Type2 keyword attribute values registration 151
- 11.2 Type3 keyword attribute values registration 151
- 11.3 Type2 enum attribute values registration 151
- 11.4 Type3 enum attribute values registration 152
- 11.5 Attribute registration 152
- 11.6 Attribute Syntax registration 153
- 11.7 Operation registration 153
- 11.8 Attribute Group registration 153
- 11.9 Status code registration 154
- 11.10 Out-of-band Attribute Value registration 154
-
-12. APPENDIX A: Terminology 154
- 12.1 Conformance Terminology 154
- 12.1.1 NEED NOT 154
- 12.2 Model Terminology 155
- 12.2.1 Keyword 155
- 12.2.2 Attributes 155
- 12.2.2.1 Attribute Name 155
- 12.2.2.2 Attribute Group Name 155
- 12.2.2.3 Attribute Value 155
- 12.2.2.4 Attribute Syntax 156
- 12.2.3 Supports 156
- 12.2.4 print-stream page 158
- 12.2.5 impression 158
-
-13. APPENDIX B: Status Codes and Suggested Status Code Messages 158
- 13.1 Status Codes 159
- 13.1.1 Informational 159
- 13.1.2 Successful Status Codes 159
- 13.1.2.1 successful-ok (0x0000) 159
- 13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)
- 159
- 13.1.2.3 successful-ok-conflicting-attributes (0x0002) 160
- 13.1.3 Redirection Status Codes 160
- 13.1.4 Client Error Status Codes 160
- 13.1.4.1 client-error-bad-request (0x0400) 160
- 13.1.4.2 client-error-forbidden (0x0401) 160
- 13.1.4.3 client-error-not-authenticated (0x0402) 161
- 13.1.4.4 client-error-not-authorized (0x0403) 161
- 13.1.4.5 client-error-not-possible (0x0404) 161
- 13.1.4.6 client-error-timeout (0x0405) 161
- 13.1.4.7 client-error-not-found (0x0406) 161
- 13.1.4.8 client-error-gone (0x0407) 162
- 13.1.4.9 client-error-request-entity-too-large (0x0408) 162
- 13.1.4.10 client-error-request-value-too-long (0x0409) 162
- 13.1.4.11 client-error-document-format-not-supported (0x040A) 163
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 7]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
- 163
- 13.1.4.13 client-error-uri-scheme-not-supported (0x040C) 163
- 13.1.4.14 client-error-charset-not-supported (0x040D) 163
- 13.1.4.15 client-error-conflicting-attributes (0x040E) 164
- 13.1.4.16 client-error-compression-not-supported (0x040F) 164
- 13.1.4.17 client-error-compression-error (0x0410) 164
- 13.1.4.18 client-error-document-format-error (0x0411) 164
- 13.1.4.19 client-error-document-access-error (0x0412) 164
- 13.1.5 Server Error Status Codes 165
- 13.1.5.1 server-error-internal-error (0x0500) 165
- 13.1.5.2 server-error-operation-not-supported (0x0501) 165
- 13.1.5.3 server-error-service-unavailable (0x0502) 165
- 13.1.5.4 server-error-version-not-supported (0x0503) 165
- 13.1.5.5 server-error-device-error (0x0504) 166
- 13.1.5.6 server-error-temporary-error (0x0505) 166
- 13.1.5.7 server-error-not-accepting-jobs (0x0506) 166
- 13.1.5.8 server-error-busy (0x0507) 166
- 13.1.5.9 server-error-job-canceled (0x0508) 167
- 13.1.5.10 server-error-multiple-document-jobs-not-supported (0x0509)
- 167
- 13.2 Status Codes for IPP Operations 168
-
-14. APPENDIX C: "media" keyword values 170
-
-15. APPENDIX D: Processing IPP Attributes 191
- 15.1 Fidelity 191
- 15.2 Page Description Language (PDL) Override 192
- 15.3 Using Job Template Attributes During Document Processing. 194
-
-16. APPENDIX E: Generic Directory Schema 195
-
-17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1 "Model and
-Semantics" Documents 198
-
-18. Full Copyright Statement 204
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 8]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-1. Introduction
-
-
-The Internet Printing Protocol (IPP) is an application level protocol
-that can be used for distributed printing using Internet tools and
-technologies. IPP version 1.1 (IPP/1.1) focuses primarily on end user
-functionality with a few administrative operations included. This
-document is just one of a suite of documents that fully define IPP. 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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-
-Anyone reading these documents for the first time is strongly encouraged
-to read the IPP documents in the above order.
-
-This document is laid out as follows:
-
- - The rest of Section 1 is an introduction to the IPP simplified
- model for distributed printing.
- - Section 2 introduces the object types covered in the model with
- their basic behaviors, attributes, and interactions.
- - Section 3 defines the operations included in IPP/1.1. IPP
- operations are synchronous, therefore, for each operation, there is
- a both request and a response.
- - Section 4 defines the attributes (and their syntaxes) that are used
- in the model.
- - Sections 5 - 6 summarizes the implementation conformance
- requirements for objects that support the protocol and IANA
- considerations, respectively.
- - Sections 7 - 11 cover the Internationalization and Security
- considerations as well as References, Author contact information,
- and Formats for Registration Proposals.
- - Sections 12 - 14 are appendices that cover Terminology, Status
- Codes and Messages, and "media" keyword values.
-
- Note: This document uses terms such as "attributes",
- "keywords", and "support". These terms have special meaning
- and are defined in the model terminology section 12.2.
- Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD,
- SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning
- relating to conformance. These terms are defined in section
- 12.1 on conformance terminology, most of which is taken from
- RFC 2119 [RFC2119].
-
- - Section 15 is an appendix that helps to clarify the effects of
- interactions between related attributes and their values.
- - Section 16 is an appendix that enumerates the subset of Printer
- attributes that form a generic directory schema. These attributes
- are useful when registering a Printer so that a client can find the
- Printer not just by name, but by filtered searches as well.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 9]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- - Section 17 is an appendix summarizing the additions and changes
- from the IPP/1.0 "Model and Semantics" document [RFC2566] to make
- this IPP/1.1 document.
- - Section 18 is the full copyright notice.
-
-1.1 Simplified Printing Model
-
-
-In order to achieve its goal of realizing a workable printing protocol
-for the Internet, the Internet Printing Protocol (IPP) is based on a
-simplified printing model that abstracts the many components of real
-world printing solutions. The Internet is a distributed computing
-environment where requesters of print services (clients, applications,
-printer drivers, etc.) cooperate and interact with print service
-providers. This model and semantics document describes a simple,
-abstract model for IPP even though the underlying configurations may be
-complex "n-tier" client/server systems. An important simplifying step
-in the IPP model is to expose only the key objects and interfaces
-required for printing. The model described in this model document does
-not include features, interfaces, and relationships that are beyond the
-scope of the first version of IPP (IPP/1.1). IPP/1.1 incorporates many
-of the relevant ideas and lessons learned from other specification and
-development efforts [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179]
-[SWP]. IPP is heavily influenced by the printing model introduced in
-the Document Printing Application (DPA) [ISO10175] standard. Although
-DPA specifies both end user and administrative features, IPP version 1.1
-(IPP/1.1) focuses primarily on end user functionality with a few
-additional OPTIONAL operator operations.
-
-The IPP/1.1 model encapsulates the important components of distributed
-printing into two object types:
-
- - Printer (Section 2.1)
- - Job (Section 2.2)
-
-
-Each object type has an associated set of operations (see section 3) and
-attributes (see section 4).
-
-It is important, however, to understand that in real system
-implementations (which lie underneath the abstracted IPP/1.1 model),
-there are other components of a print service which are not explicitly
-defined in the IPP/1.1 model. The following figure illustrates where
-IPP/1.1 fits with respect to these other components.
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 10]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
- +--------------+
- | Application |
- o +. . . . . . . |
- \|/ | Spooler |
- / \ +. . . . . . . | +---------+
- End-User | Print Driver |---| File |
- +-----------+ +-----+ +------+-------+ +----+----+
- | Browser | | GUI | | |
- +-----+-----+ +--+--+ | |
- | | | |
- | +---+------------+---+ |
-N D S | | IPP Client |------------+
-O I E | +---------+----------+
-T R C | |
-I E U |
-F C R -------------- Transport ------------------
-I T I
-C O T | --+
-A R Y +--------+--------+ |
-T Y | IPP Server | |
-I +--------+--------+ |
-O | |
-N +-----------------+ | IPP Printer
- | Print Service | |
- +-----------------+ |
- | --+
- +-----------------+
- | Output Device(s)|
- +-----------------+
-
-
-An IPP Printer object encapsulates the functions normally associated
-with physical output devices along with the spooling, scheduling and
-multiple device management functions often associated with a print
-server. Printer objects are optionally registered as entries in a
-directory where end users find and select them based on some sort of
-filtered and context based searching mechanism (see section 16). The
-directory is used to store relatively static information about the
-Printer, allowing end users to search for and find Printers that match
-their search criteria, for example: name, context, printer capabilities,
-etc. The more dynamic information, such as state, currently loaded and
-ready media, number of jobs at the Printer, errors, warnings, and so
-forth, is directly associated with the Printer object itself rather than
-with the entry in the directory which only represents the Printer
-object.
-
-IPP clients implement the IPP protocol on the client side and give end
-users (or programs running on behalf of end users) the ability to query
-Printer objects and submit and manage print jobs. An IPP server is just
-that part of the Printer object that implements the server-side
-protocol. The rest of the Printer object implements (or gateways into)
-the application semantics of the print service itself. The Printer
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 11]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-objects may be embedded in an output device or may be implemented on a
-host on the network that communicates with an output device.
-
-When a job is submitted to the Printer object and the Printer object
-validates the attributes in the submission request, the Printer object
-creates a new Job object. The end user then interacts with this new Job
-object to query its status and monitor the progress of the job. An end
-user can also cancel their print jobs by using the Job object's Cancel-
-Job operation. An end-user can also hold, release, and restart their
-print jobs using the Job object's OPTIONAL Hold-Job, Release-Job, and
-Restart-Job operations, if implemented.
-
-A privileged operator or administrator of a Printer object can cancel,
-hold, release, and restart any user's job using the REQUIRED Cancel-Job
-and the OPTIONAL Hold-Job, Release-Job, and Restart-Job operations. In
-additional privileged operator or administrator of a Printer object can
-pause, resume, or purge (jobs from) a Printer object using the OPTIONAL
-Pause-Printer, Resume-Printer, and Purge-Jobs operations, if
-implemented.
-
-The notification service is out of scope for this IPP/1.1 document, but
-using such a notification service, the end user is able to register for
-and receive Printer specific and Job specific events. An end user can
-query the status of Printer objects and can follow the progress of Job
-objects by polling using the Get-Printer-Attributes, Get-Jobs, and Get-
-Job-Attributes operations.
-
-
-
-2. IPP Objects
-
-
-The IPP/1.1 model introduces objects of type Printer and Job. Each type
-of object models relevant aspects of a real-world entity such as a real
-printer or real print job. Each object type is defined as a set of
-possible attributes that may be supported by instances of that object
-type. For each object (instance), the actual set of supported
-attributes and values describe a specific implementation. The object's
-attributes and values describe its state, capabilities, realizable
-features, job processing functions, and default behaviors and
-characteristics. For example, the Printer object type is defined as a
-set of attributes that each Printer object potentially supports. In the
-same manner, the Job object type is defined as a set of attributes that
-are potentially supported by each Job object.
-
-Each attribute included in the set of attributes defining an object type
-is labeled as:
-
- - "REQUIRED": each object MUST support the attribute.
- - "RECOMMENDED": each object SHOULD support the attribute.
- - "OPTIONAL": each object MAY support the attribute.
-
-
-Some definitions of attribute values indicate that an object MUST or
-SHOULD support the value; otherwise, support of the value is OPTIONAL.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 12]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-However, if an implementation supports an attribute, it MUST support at
-least one of the possible values for that attribute.
-
-
-2.1 Printer Object
-
-
-The major component of the IPP/1.1 model is the Printer object. A
-Printer object implements the server-side of the IPP/1.1 protocol.
-Using the protocol, end users may query the attributes of the Printer
-object and submit print jobs to the Printer object. The actual
-implementation components behind the Printer abstraction may take on
-different forms and different configurations. However, the model
-abstraction allows the details of the configuration of real components
-to remain opaque to the end user. Section 3 describes each of the
-Printer operations in detail.
-
-The capabilities and state of a Printer object are described by its
-attributes. Printer attributes are divided into two groups:
-
- - "job-template" attributes: These attributes describe supported job
- processing capabilities and defaults for the Printer object. (See
- section 4.2)
- - "printer-description" attributes: These attributes describe the
- Printer object's identification, state, location, references to
- other sources of information about the Printer object, etc. (see
- section 4.4)
-
-
-Since a Printer object is an abstraction of a generic document output
-device and print service provider, a Printer object could be used to
-represent any real or virtual device with semantics consistent with the
-Printer object, such as a fax device, an imager, or even a CD writer.
-
-Some examples of configurations supporting a Printer object include:
-
- 1) An output device with no spooling capabilities
- 2) An output device with a built-in spooler
- 3) A print server supporting IPP with one or more associated output
- devices
- 3a) The associated output devices may or may not be capable of
- spooling jobs
- 3b) The associated output devices may or may not support IPP
-
-
-The following figures show some examples of how Printer objects can be
-realized on top of various distributed printing configurations. The
-embedded case below represents configurations 1 and 2. The hosted and
-fan-out figures below represent configurations 3a and 3b.
-
-In this document the term "client" refers to a software entity that
-sends IPP operation requests to an IPP Printer object and accepts IPP
-operation responses. A client MAY be:
-
- 1. contained within software controlled by an end user, e.g. activated
- by the "Print" menu item in an application or
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 13]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 2. the print server component that sends IPP requests to either an
- output device or another "downstream" print server.
-
-The term "IPP Printer" is a network entity that accepts IPP operation
-requests and returns IPP operation responses. As such, an IPP object
-MAY be:
-
- 1. an (embedded) device component that accepts IPP requests and
- controls the device or
-
- 2. a component of a print server that accepts IPP requests (where the
- print server controls one or more networked devices using IPP or
- other protocols).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 14]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Legend:
-
-##### indicates a Printer object which is
- either embedded in an output device or is
- hosted in a server. The Printer object
- might or might not be capable of queuing/spooling.
-
-any indicates any network protocol or direct
- connect, including IPP
-
-
-embedded printer:
- output device
- +---------------+
- O +--------+ | ########### |
-/|\ | client |------------IPP------------># Printer # |
-/ \ +--------+ | # Object # |
- | ########### |
- +---------------+
-
-
-hosted printer:
- +---------------+
- O +--------+ ########### | |
-/|\ | client |--IPP--># Printer #-any->| output device |
-/ \ +--------+ # Object # | |
- ########### +---------------+
-
-
-
- +---------------+
-fan out: | |
- +-->| output device |
- any/ | |
- O +--------+ ########### / +---------------+
-/|\ | client |-IPP-># Printer #--*
-/ \ +--------+ # Object # \ +---------------+
- ########### any\ | |
- +-->| output device |
- | |
- +---------------+
-
-
-
-2.2 Job Object
-
-
-A Job object is used to model a print job. A Job object contains
-documents. The information required to create a Job object is sent in a
-create request from the end user via an IPP Client to the Printer
-object. The Printer object validates the create request, and if the
-Printer object accepts the request, the Printer object creates the new
-Job object. Section 3 describes each of the Job operations in detail.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 15]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-The characteristics and state of a Job object are described by its
-attributes. Job attributes are grouped into two groups as follows:
-
- - "job-template" attributes: These attributes can be supplied by the
- client or end user and include job processing instructions which
- are intended to override any Printer object defaults and/or
- instructions embedded within the document data. (See section 4.2)
- - "job-description" attributes: These attributes describe the Job
- object's identification, state, size, etc. The client supplies some
- of these attributes, and the Printer object generates others. (See
- section 4.3)
-
-
-An implementation MUST support at least one document per Job object. An
-implementation MAY support multiple documents per Job object. A
-document is either:
-
- - a stream of document data in a format supported by the Printer
- object (typically a Page Description Language - PDL), or
- - a reference to such a stream of document data
-
-
-In IPP/1.1, a document is not modeled as an IPP object, therefore it has
-no object identifier or associated attributes. All job processing
-instructions are modeled as Job object attributes. These attributes are
-called Job Template attributes and they apply equally to all documents
-within a Job object.
-
-
-2.3 Object Relationships
-
-
-IPP objects have relationships that are maintained persistently along
-with the persistent storage of the object attributes.
-
-A Printer object can represent either one or more physical output
-devices or a logical device which "processes" jobs but never actually
-uses a physical output device to put marks on paper. Examples of
-logical devices include a Web page publisher or a gateway into an online
-document archive or repository. A Printer object contains zero or more
-Job objects.
-
-A Job object is contained by exactly one Printer object, however the
-identical document data associated with a Job object could be sent to
-either the same or a different Printer object. In this case, a second
-Job object would be created which would be almost identical to the first
-Job object, however it would have new (different) Job object identifiers
-(see section 2.4).
-
-A Job object is either empty (before any documents have been added) or
-contains one or more documents. If the contained document is a stream
-of document data, that stream can be contained in only one document.
-However, there can be identical copies of the stream in other documents
-in the same or different Job objects. If the contained document is just
-a reference to a stream of document data, other documents (in the same
-or different Job object(s)) may contain the same reference.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 16]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-2.4 Object Identity
-
-
-All Printer and Job objects are identified by a Uniform Resource
-Identifier (URI) [RFC2396] so that they can be persistently and
-unambiguously referenced. Since every URL is a specialized form of a
-URI, even though the more generic term URI is used throughout the rest
-of this document, its usage is intended to cover the more specific
-notion of URL as well.
-
-An administrator configures Printer objects to either support or not
-support authentication and/or message privacy using Transport Layer
-Security (TLS) [RFC2246] (the mechanism for security configuration is
-outside the scope of this IPP/1.1 document). In some situations, both
-types of connections (both authenticated and unauthenticated) can be
-established using a single communication channel that has some sort of
-negotiation mechanism. In other situations, multiple communication
-channels are used, one for each type of security configuration. Section
-8 provides a full description of all security considerations and
-configurations.
-
-If a Printer object supports more than one communication channel, some
-or all of those channels might support and/or require different security
-mechanisms. In such cases, an administrator could expose the
-simultaneous support for these multiple communication channels as
-multiple URIs for a single Printer object where each URI represents one
-of the communication channels to the Printer object. To support this
-flexibility, the IPP Printer object type defines a multi-valued
-identification attribute called the "printer-uri-supported" attribute.
-It MUST contain at least one URI. It MAY contain more than one URI.
-That is, every Printer object will have at least one URI that identifies
-at least one communication channel to the Printer object, but it may
-have more than one URI where each URI identifies a different
-communication channel to the Printer object. The "printer-uri-
-supported" attribute has two companion attributes, the "uri-security-
-supported" attribute and the "uri-authentication-supported". Both have
-the same cardinality as "printer-uri-supported". The purpose of the
-"uri-security-supported" attribute is to indicate the security
-mechanisms (if any) used for each URI listed in "printer-uri-supported".
-The purpose of the "uri-authentication-supported" attribute is to
-indicate the authentication mechanisms (if any) used for each URI listed
-in "printer-uri-supported". These three attributes are fully described
-in sections 4.4.1, 4.4.2, and 4.4.3.
-
-When a job is submitted to the Printer object via a create request, the
-client supplies only a single Printer object URI. The client supplied
-Printer object URI MUST be one of the values in the "printer-uri-
-supported" Printer attribute.
-
-IPP/1.1 does not specify how the client obtains the client supplied URI,
-but it is RECOMMENDED that a Printer object be registered as an entry in
-a directory service. End-users and programs can then interrogate the
-directory searching for Printers. Section 16 defines a generic schema
-for Printer object entries in the directory service and describes how
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 17]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-the entry acts as a bridge to the actual IPP Printer object. The entry
-in the directory that represents the IPP Printer object includes the
-possibly many URIs for that Printer object as values in one its
-attributes.
-
-When a client submits a create request to the Printer object, the
-Printer object validates the request and creates a new Job object. The
-Printer object assigns the new Job object a URI which is stored in the
-"job-uri" Job attribute. This URI is then used by clients as the target
-for subsequent Job operations. The Printer object generates a Job URI
-based on its configured security policy and the URI used by the client
-in the create request.
-
-For example, consider a Printer object that supports both a
-communication channel secured by the use of SSL3 (using HTTP over SSL3
-with an "https" schemed URI) and another open communication channel that
-is not secured with SSL3 (using a simple "http" schemed URI). If a
-client were to submit a job using the secure URI, the Printer object
-would assign the new Job object a secure URI as well. If a client were
-to submit a job using the open-channel URI, the Printer would assign the
-new Job object an open-channel URI.
-
-In addition, the Printer object also populates the Job object's "job-
-printer-uri" attribute. This is a reference back to the Printer object
-that created the Job object. If a client only has access to a Job
-object's "job-uri" identifier, the client can query the Job's "job-
-printer-uri" attribute in order to determine which Printer object
-created the Job object. If the Printer object supports more than one
-URI, the Printer object picks the one URI supplied by the client when
-creating the job to build the value for and to populate the Job's "job-
-printer-uri" attribute.
-
-Allowing Job objects to have URIs allows for flexibility and
-scalability. For example, in some implementations, the Printer object
-might create Jobs that are processed in the same local environment as
-the Printer object itself. In this case, the Job URI might just be a
-composition of the Printer's URI and some unique component for the Job
-object, such as the unique 32-bit positive integer mentioned later in
-this paragraph. In other implementations, the Printer object might be a
-central clearing-house for validating all Job object creation requests,
-but the Job object itself might be created in some environment that is
-remote from the Printer object. In this case, the Job object's URI may
-have no physical-location relationship at all to the Printer object's
-URI. Again, the fact that Job objects have URIs allows for flexibility
-and scalability, however, many existing printing systems have local
-models or interface constraints that force print jobs to be identified
-using only a 32-bit positive integer rather than an independent URI.
-This numeric Job ID is only unique within the context of the Printer
-object to which the create request was originally submitted. Therefore,
-in order to allow both types of client access to IPP Job objects (either
-by Job URI or by numeric Job ID), when the Printer object successfully
-processes a create request and creates a new Job object, the Printer
-object MUST generate both a Job URI and a Job ID. The Job ID (stored in
-the "job-id" attribute) only has meaning in the context of the Printer
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 18]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-object to which the create request was originally submitted. This
-requirement to support both Job URIs and Job IDs allows all types of
-clients to access Printer objects and Job objects no matter the local
-constraints imposed on the client implementation.
-
-In addition to identifiers, Printer objects and Job objects have names
-("printer-name" and "job-name"). An object name NEED NOT be unique
-across all instances of all objects. A Printer object's name is chosen
-and set by an administrator through some mechanism outside the scope of
-this IPP/1.1 document. A Job object's name is optionally chosen and
-supplied by the IPP client submitting the job. If the client does not
-supply a Job object name, the Printer object generates a name for the
-new Job object. In all cases, the name only has local meaning.
-
-To summarize:
-
- - Each Printer object is identified with one or more URIs. The
- Printer's "printer-uri-supported" attribute contains the URI(s).
- - The Printer object's "uri-security-supported" attribute identifies
- the communication channel security protocols that may or may not
- have been configured for the various Printer object URIs (e.g.,
- 'tls' or 'none').
- - The Printer object's "uri-authentication-supported" attribute
- identifies the authentication mechanisms that may or may not have
- been configured for the various Printer object URIs (e.g., 'digest'
- or 'none').
- - Each Job object is identified with a Job URI. The Job's "job-uri"
- attribute contains the URI.
- - Each Job object is also identified with Job ID which is a 32-bit,
- positive integer. The Job's "job-id" attribute contains the Job
- ID. The Job ID is only unique within the context of the Printer
- object which created the Job object.
- - Each Job object has a "job-printer-uri" attribute which contains
- the URI of the Printer object that was used to create the Job
- object. This attribute is used to determine the Printer object
- that created a Job object when given only the URI for the Job
- object. This linkage is necessary to determine the languages,
- charsets, and operations which are supported on that Job (the basis
- for such support comes from the creating Printer object).
- - Each Printer object has a name (which is not necessarily unique).
- The administrator chooses and sets this name through some mechanism
- outside the scope of this IPP/1.1 document. The Printer object's
- "printer-name" attribute contains the name.
- - Each Job object has a name (which is not necessarily unique). The
- client optionally supplies this name in the create request. If the
- client does not supply this name, the Printer object generates a
- name for the Job object. The Job object's "job-name" attribute
- contains the name.
-
-
-3. IPP Operations
-
-
-IPP objects support operations. An operation consists of a request and
-a response. When a client communicates with an IPP object, the client
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 19]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-issues an operation request to the URI for that object. Operation
-requests and responses have parameters that identify the operation.
-Operations also have attributes that affect the run-time characteristics
-of the operation (the intended target, localization information, etc.).
-These operation-specific attributes are called operation attributes (as
-compared to object attributes such as Printer object attributes or Job
-object attributes). Each request carries along with it any operation
-attributes, object attributes, and/or document data required to perform
-the operation. Each request requires a response from the object. Each
-response indicates success or failure of the operation with a status
-code as a response parameter. The response contains any operation
-attributes, object attributes, and/or status messages generated during
-the execution of the operation request.
-
-This section describes the semantics of the IPP operations, both
-requests and responses, in terms of the parameters, attributes, and
-other data associated with each operation.
-
-The IPP/1.1 Printer operations are:
-
- Print-Job (section 3.2.1)
- Print-URI (section 3.2.2)
- Validate-Job (section 3.2.3)
- Create-Job (section 3.2.4)
- Get-Printer-Attributes (section 3.2.5)
- Get-Jobs (section 3.2.6)
- Pause-Printer (section 3.3.5)
- Resume-Printer (section 3.3.6)
- Purge-Jobs (section 3.3.7)
-
-
-The Job operations are:
-
- Send-Document (section 3.3.1)
- Send-URI (section 3.3.2)
- Cancel-Job (section 3.3.3)
- Get-Job-Attributes (section 3.3.4)
- Hold-Job (section 3.3.5)
- Release-Job (section 3.3.6)
- Restart-Job (section 3.3.7)
-
-
-The Send-Document and Send-URI Job operations are used to add a new
-document to an existing multi-document Job object created using the
-Create-Job operation.
-
-
-3.1 Common Semantics
-
-All IPP operations require some common parameters and operation
-attributes. These common elements and their semantic characteristics
-are defined and described in more detail in the following sections.
-
-3.1.1 Required Parameters
-
-Every operation request contains the following REQUIRED parameters:
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 20]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- - a "version-number",
- - an "operation-id",
- - a "request-id", and
- - the attributes that are REQUIRED for that type of request.
-
-
-Every operation response contains the following REQUIRED parameters:
-
- - a "version-number",
- - a "status-code",
- - the "request-id" that was supplied in the corresponding request,
- and
- - the attributes that are REQUIRED for that type of response.
-
-The "Encoding and Transport" document [IPP-PRO] defines special rules
-for the encoding of these parameters. All other operation elements are
-represented using the more generic encoding rules for attributes and
-groups of attributes.
-
-3.1.2 Operation IDs and Request IDs
-
-Each IPP operation request includes an identifying "operation-id" value.
-Valid values are defined in the "operations-supported" Printer attribute
-section (see section 4.4.15). The client specifies which operation is
-being requested by supplying the correct "operation-id" value.
-
-In addition, every invocation of an operation is identified by a
-"request-id" value. For each request, the client chooses the "request-
-id" which MUST be an integer (possibly unique depending on client
-requirements) in the range from 1 to 2**31 - 1 (inclusive). This
-"request-id" allows clients to manage multiple outstanding requests. The
-receiving IPP object copies all 32-bits of the client-supplied "request-
-id" attribute into the response so that the client can match the
-response with the correct outstanding request, even if the "request-id"
-is out of range. If the request is terminated before the complete
-"request-id" is received, the IPP object rejects the request and returns
-a response with a "request-id" of 0.
-
-Note: In some cases, the transport protocol underneath IPP might be a
-connection oriented protocol that would make it impossible for a client
-to receive responses in any order other than the order in which the
-corresponding requests were sent. In such cases, the "request-id"
-attribute would not be essential for correct protocol operation.
-However, in other mappings, the operation responses can come back in any
-order. In these cases, the "request-id" would be essential.
-
-
-3.1.3 Attributes
-
-Operation requests and responses are both composed of groups of
-attributes and/or document data. The attributes groups are:
-
- - Operation Attributes: These attributes are passed in the operation
- and affect the IPP object's behavior while processing the operation
- request and may affect other attributes or groups of attributes.
- Some operation attributes describe the document data associated
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 21]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- with the print job and are associated with new Job objects, however
- most operation attributes do not persist beyond the life of the
- operation. The description of each operation attribute includes
- conformance statements indicating which operation attributes are
- REQUIRED and which are OPTIONAL for an IPP object to support and
- which attributes a client MUST supply in a request and an IPP
- object MUST supply in a response.
- - Job Template Attributes: These attributes affect the processing of
- a job. A client OPTIONALLY supplies Job Template Attributes in a
- create request, and the receiving object MUST be prepared to
- receive all supported attributes. The Job object can later be
- queried to find out what Job Template attributes were originally
- requested in the create request, and such attributes are returned
- in the response as Job Object Attributes. The Printer object can
- be queried about its Job Template attributes to find out what type
- of job processing capabilities are supported and/or what the
- default job processing behaviors are, though such attributes are
- returned in the response as Printer Object Attributes. The "ipp-
- attribute-fidelity" operation attribute affects processing of all
- client-supplied Job Template attributes (see sections 3.2.1.2 and
- 15 for a full description of "ipp-attribute-fidelity" and its
- relationship to other attributes).
- - Job Object Attributes: These attributes are returned in response to
- a query operation directed at a Job object.
- - Printer Object Attributes: These attributes are returned in
- response to a query operation directed at a Printer object.
- - Unsupported Attributes: In a create request, the client supplies a
- set of Operation and Job Template attributes. If any of these
- attributes or their values is unsupported by the Printer object,
- the Printer object returns the set of unsupported attributes in the
- response. Sections 3.1.7, 3.2.1.2, and 15 give a full description
- of how Job Template attributes supplied by the client in a create
- request are processed by the Printer object and how unsupported
- attributes are returned to the client. Because of extensibility,
- any IPP object might receive a request that contains new or unknown
- attributes or values for which it has no support. In such cases,
- the IPP object processes what it can and returns the unsupported
- attributes in the response. The Unsupported Attribute group is
- defined for all operation responses for returning unsupported
- attributes that the client supplied in the request.
-
-
-Later in this section, each operation is formally defined by identifying
-the allowed and expected groups of attributes for each request and
-response. The model identifies a specific order for each group in each
-request or response, but the attributes within each group may be in any
-order, unless specified otherwise.
-
-The attributes within a group MUST be unique; if an attribute with the
-same name occurs more than once, the group is mal-formed. Clients MUST
-NOT submit such malformed requests and Printers MUST NOT return such
-malformed responses. If such a malformed request is submitted to a
-Printer, the Printer MUST either (1) reject the request with the
-'client-error-bad-request' status code (see section 13.1.4.1) or (2)
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 22]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-process the request normally after selecting only one of the attribute
-instances, depending on implementation. Which attribute is selected
-when there are duplicate attributes depends on implementation. The IPP
-Printer MUST NOT use the values from more than one such duplicate
-attribute instance.
-
-Each attribute definition includes the attribute's name followed by the
-name of its attribute syntax(es) in parenthesizes. In addition, each
-'integer' attribute is followed by the allowed range in parentheses,
-(m:n), for values of that attribute. Each 'text' or 'name' attribute is
-followed by the maximum size in octets in parentheses, (size), for
-values of that attribute. For more details on attribute syntax notation,
-see the descriptions of these attributes syntaxes in section 4.1.
-
-Note: Document data included in the operation is not strictly an
-attribute, but it is treated as a special attribute group for ordering
-purposes. The only operations that support supplying the document data
-within an operation request are Print-Job and Send-Document. There are
-no operation responses that include document data.
-
-Some operations are REQUIRED for IPP objects to support; the others are
-OPTIONAL (see section 5.2.2). Therefore, before using an OPTIONAL
-operation, a client SHOULD first use the REQUIRED Get-Printer-Attributes
-operation to query the Printer's "operations-supported" attribute in
-order to determine which OPTIONAL Printer and Job operations are
-actually supported. The client SHOULD NOT use an OPTIONAL operation
-that is not supported. When an IPP object receives a request to perform
-an operation it does not support, it returns the 'server-error-
-operation-not-supported' status code (see section 13.1.5.2). An IPP
-object is non-conformant if it does not support a REQUIRED operation.
-
-
-3.1.4 Character Set and Natural Language Operation Attributes
-
-Some Job and Printer attributes have values that are text strings and
-names intended for human understanding rather than machine understanding
-(see the 'text' and 'name' attribute syntax descriptions in section
-4.1). The following sections describe two special Operation Attributes
-called "attributes-charset" and "attributes-natural-language". These
-attributes are always part of the Operation Attributes group. For most
-attribute groups, the order of the attributes within the group is not
-important. However, for these two attributes within the Operation
-Attributes group, the order is critical. The "attributes-charset"
-attribute MUST be the first attribute in the group and the "attributes-
-natural-language" attribute MUST be the second attribute in the group.
-In other words, these attributes MUST be supplied in every IPP request
-and response, they MUST come first in the group, and MUST come in the
-specified order. For job creation operations, the IPP Printer
-implementation saves these two attributes with the new Job object as Job
-Description attributes. For the sake of brevity in this document, these
-operation attribute descriptions are not repeated with every operation
-request and response, but have a reference back to this section instead.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 23]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-3.1.4.1 Request Operation Attributes
-
-The client MUST supply and the Printer object MUST support the following
-REQUIRED operation attributes in every IPP/1.1 operation request:
-
- "attributes-charset" (charset):
- This operation attribute identifies the charset (coded character
- set and encoding method) used by any 'text' and 'name' attributes
- that the client is supplying in this request. It also identifies
- the charset that the Printer object MUST use (if supported) for all
- 'text' and 'name' attributes and status messages that the Printer
- object returns in the response to this request. See Sections 4.1.1
- and 4.1.2 for the definition of the 'text' and 'name' attribute
- syntaxes.
-
- All clients and IPP objects MUST support the 'utf-8' charset
- [RFC2279] 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. The Printer NEED NOT return any attributes in the
- Unsupported Attributes Group (See sections 3.1.7 and 3.2.1.2). The
- Printer object MUST indicate the charset(s) supported as the values
- of the "charset-supported" Printer attribute (see Section 4.4.18),
- so that the client can query to determine which charset(s) are
- supported.
-
- Note to client implementers: Since IPP objects are only required to
- support the 'utf-8' charset, in order to maximize interoperability
- with multiple IPP object implementations, a client may want to
- supply 'utf-8' in the "attributes-charset" operation attribute,
- even though the client is only passing and able to present a
- simpler charset, such as US-ASCII or ISO-8859-1. Then the client
- will have to filter out (or charset convert) those characters that
- are returned in the response that it cannot present to its user.
- On the other hand, if both the client and the IPP objects also
- support a charset in common besides utf-8, the client may want to
- use that charset in order to avoid charset conversion or data loss.
-
- See the 'charset' attribute syntax description in Section 4.1.7 for
- the syntax and semantic interpretation of the values of this
- attribute and for example values.
-
- "attributes-natural-language" (naturalLanguage):
- This operation attribute identifies the natural language used by
- any 'text' and 'name' attributes that the client is supplying in
- this request. This attribute also identifies the natural language
- that the Printer object SHOULD use for all 'text' and 'name'
- attributes and status messages that the Printer object returns in
- the response to this request. See the 'naturalLanguage' attribute
- syntax description in section 4.1.8 for the syntax and semantic
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 24]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- interpretation of the values of this attribute and for example
- values.
-
- There are no REQUIRED natural languages required for the Printer
- object to support. However, the Printer object's "generated-
- natural-language-supported" attribute identifies the natural
- languages supported by the Printer object and any contained Job
- objects for all text strings generated by the IPP object. A client
- MAY query this attribute to determine which natural language(s) are
- supported for generated messages.
-
- For any of the attributes for which the Printer object generates
- text, i.e., for the "job-state-message", "printer-state-message",
- and status messages (see Section 3.1.6), the Printer object MUST be
- able to generate these text strings in any of its supported natural
- languages. If the client requests a natural language that is not
- supported, the Printer object MUST return these generated messages
- in the Printer's configured natural language as specified by the
- Printer's "natural-language-configured" attribute" (see Section
- 4.4.19).
-
- For other 'text' and 'name' attributes supplied by the client,
- authentication system, operator, system administrator, or
- manufacturer (i.e., for "job-originating-user-name", "printer-name"
- (name), "printer-location" (text), "printer-info" (text), and
- "printer-make-and-model" (text)), the Printer object is only
- required to support the configured natural language of the Printer
- identified by the Printer object's "natural-language-configured"
- attribute, though support of additional natural languages for these
- attributes is permitted.
-
- For any 'text' or 'name' attribute in the request that is in a
- different natural language than the value supplied in the
- "attributes-natural-language" operation attribute, the client MUST
- use the Natural Language Override mechanism (see sections 4.1.1.2
- and 4.1.2.2) for each such attribute value supplied. The client
- MAY use the Natural Language Override mechanism redundantly, i.e.,
- use it even when the value is in the same natural language as the
- value supplied in the "attributes-natural-language" operation
- attribute of the request.
-
- The IPP object MUST accept any natural language and any Natural
- Language Override, whether the IPP object supports that natural
- language or not (and independent of the value of the "ipp-
- attribute-fidelity" Operation attribute). That is the IPP object
- accepts all client supplied values no matter what the values are in
- the Printer object's "generated-natural-language-supported"
- attribute. That attribute, "generated-natural-language-supported",
- only applies to generated messages, not client supplied messages.
- The IPP object MUST remember that natural language for all client-
- supplied attributes, and when returning those attributes in
- response to a query, the IPP object MUST indicate that natural
- language.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 25]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- Each value whose attribute syntax type is 'text' or 'name' (see
- sections 4.1.1 and 4.1.2) has an Associated Natural-Language. This
- document does not specify how this association is stored in a
- Printer or Job object. When such a value is encoded in a request
- or response, the natural language is either implicit or explicit:
-
- @ In the implicit case, the value contains only the text/name
- value, and the language is specified by the "attributes-
- natural-language" operation attribute in the request or
- response (see sections 4.1.1.1 textWithoutLanguage and 4.1.2.1
- nameWithoutLanguage).
-
- @ In the explicit case (also known as the Natural-Language
- Override case), the value contains both the language and the
- text/name value (see sections 4.1.1.2 textWithLanguage and
- 4.1.2.2 nameWithLanguage).
-
- For example, the "job-name" attribute MAY be supplied by the client
- in a create request. The text value for this attribute will be in
- the natural language identified by the "attribute-natural-language"
- attribute, or if different, as identified by the Natural Language
- Override mechanism. If supplied, the IPP object will use the value
- of the "job-name" attribute to populate the Job object's "job-name"
- attribute. Whenever any client queries the Job object's "job-name"
- attribute, the IPP object returns the attribute as stored and uses
- the Natural Language Override mechanism to specify the natural
- language, if it is different from that reported in the "attributes-
- natural-language" operation attribute of the response. The IPP
- object MAY use the Natural Language Override mechanism redundantly,
- i.e., use it even when the value is in the same natural language
- as the value supplied in the "attributes-natural-language"
- operation attribute of the response.
-
- An IPP object MUST NOT reject a request based on a supplied natural
- language in an "attributes-natural-language" Operation attribute or
- in any attribute that uses the Natural Language Override.
-
-
-Clients SHOULD NOT supply 'text' or 'name' attributes that use an
-illegal combination of natural language and charset. For example,
-suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and
-'iso-8859-7'. Suppose also, that it supports natural languages 'en'
-(English), 'fr' (French), and 'el' (Greek). Although the Printer object
-supports the charset 'iso-8859-1' and natural language 'el', it probably
-does not support the combination of Greek text strings using the 'iso-
-8859-1' charset. The Printer object handles this apparent
-incompatibility differently depending on the context in which it occurs:
-
- - In a create request: If the client supplies a text or name
- attribute (for example, the "job-name" operation attribute) that
- uses an apparently incompatible combination, it is a client choice
- that does not affect the Printer object or its correct operation.
- Therefore, the Printer object simply accepts the client supplied
- value, stores it with the Job object, and responds back with the
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 26]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- same combination whenever the client (or any client) queries for
- that attribute.
- - In a query-type operation, like Get-Printer-Attributes: If the
- client requests an apparently incompatible combination, the Printer
- object responds (as described in section 3.1.4.2) using the
- Printer's configured natural language rather than the natural
- language requested by the client.
-
-
-In either case, the Printer object does not reject the request because
-of the apparent incompatibility. The potential incompatible combination
-of charset and natural language can occur either at the global operation
-level or at the Natural Language Override attribute-by-attribute level.
-In addition, since the response always includes explicit charset and
-natural language information, there is never any question or ambiguity
-in how the client interprets the response.
-
-
-3.1.4.2 Response Operation Attributes
-
-The Printer object MUST supply and the client MUST support the following
-REQUIRED operation attributes in every IPP/1.1 operation response:
-
- "attributes-charset" (charset):
- This operation attribute identifies the charset used by any 'text'
- and 'name' attributes that the Printer object is returning in this
- response. The value in this response MUST be the same value as the
- "attributes-charset" operation attribute supplied by the client in
- the request. If this is not possible (i.e., the charset requested
- is not supported), the request would have been rejected. See
- "attributes-charset" described in Section 3.1.4.1 above.
-
- If the Printer object supports more than just the 'utf-8' charset,
- the Printer object MUST be able to code convert between each of the
- charsets supported on a highest fidelity possible basis in order to
- return the 'text' and 'name' attributes in the charset requested by
- the client. However, some information loss MAY occur during the
- charset conversion depending on the charsets involved. For
- example, the Printer object may convert from a UTF-8 'a' to a US-
- ASCII 'a' (with no loss of information), from an ISO Latin 1
- CAPITAL LETTER A WITH ACUTE ACCENT to US-ASCII 'A' (losing the
- accent), or from a UTF-8 Japanese Kanji character to some ISO Latin
- 1 error character indication such as '?', decimal code equivalent,
- or to the absence of a character, depending on implementation.
-
- Whether an implementation that supports more than one charset
- stores the data in the charset supplied by the client or code
- converts to one of the other supported charsets, depends on
- implementation. The strategy should try to minimize loss of
- information during code conversion. On each response, such an
- implementation converts from its internal charset to that
- requested.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 27]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- "attributes-natural-language" (naturalLanguage):
- This operation attribute identifies the natural language used by
- any 'text' and 'name' attributes that the IPP object is returning
- in this response. Unlike the "attributes-charset" operation
- attribute, the IPP object NEED NOT return the same value as that
- supplied by the client in the request. The IPP object MAY return
- the natural language of the Job object or the Printer's configured
- natural language as identified by the Printer object's "natural-
- language-configured" attribute, rather than the natural language
- supplied by the client. For any 'text' or 'name' attribute or
- status message in the response that is in a different natural
- language than the value returned in the "attributes-natural-
- language" operation attribute, the IPP object MUST use the Natural
- Language Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on
- each attribute value returned. The IPP object MAY use the Natural
- Language Override mechanism redundantly, i.e., use it even when the
- value is in the same natural language as the value supplied in the
- "attributes-natural-language" operation attribute of the response.
-
-3.1.5 Operation Targets
-
-All IPP operations are directed at IPP objects. For Printer operations,
-the operation is always directed at a Printer object using one of its
-URIs (i.e., one of the values in the Printer object's "printer-uri-
-supported" attribute). Even if the Printer object supports more than
-one URI, the client supplies only one URI as the target of the
-operation. The client identifies the target object by supplying the
-correct URI in the "printer-uri (uri)" operation attribute.
-
-For Job operations, the operation is directed at either:
-
- - The Job object itself using the Job object's URI. In this case,
- the client identifies the target object by supplying the correct
- URI in the "job-uri (uri)" operation attribute.
- - The Printer object that created the Job object using both the
- Printer objects URI and the Job object's Job ID. Since the Printer
- object that created the Job object generated the Job ID, it MUST be
- able to correctly associate the client supplied Job ID with the
- correct Job object. The client supplies the Printer object's URI
- in the "printer-uri (uri)" operation attribute and the Job object's
- Job ID in the "job-id (integer(1:MAX))" operation attribute.
-
-
-If the operation is directed at the Job object directly using the Job
-object's URI, the client MUST NOT include the redundant "job-id"
-operation attribute.
-
-The operation target attributes are REQUIRED operation attributes that
-MUST be included in every operation request. Like the charset and
-natural language attributes (see section 3.1.4), the operation target
-attributes are specially ordered operation attributes. In all cases,
-the operation target attributes immediately follow the "attributes-
-charset" and "attributes-natural-language" attributes within the
-operation attribute group, however the specific ordering rules are:
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 28]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- - In the case where there is only one operation target attribute
- (i.e., either only the "printer-uri" attribute or only the "job-
- uri" attribute), that attribute MUST be the third attribute in the
- operation attributes group.
- - In the case where Job operations use two operation target
- attributes (i.e., the "printer-uri" and "job-id" attributes), the
- "printer-uri" attribute MUST be the third attribute and the "job-
- id" attribute MUST be the fourth attribute.
-
-
-In all cases, the target URIs contained within the body of IPP operation
-requests and responses must be in absolute format rather than relative
-format (a relative URL identifies a resource with the scope of the HTTP
-server, but does not include scheme, host or port).
-
-The following rules apply to the use of port numbers in URIs that
-identify IPP objects:
-
- 1. If the URI scheme allows the port number to be explicitly included
- in the URI string, and a port number is specified within the URI,
- then that port number MUST be used by the client to contact the IPP
- object.
-
- 2. If the URI scheme allows the port number to be explicitly included
- in the URI string, and a port number is not specified within the
- URI, then default port number implied by that URI scheme MUST be
- used by the client to contact the IPP object.
-
- 3. If the URI scheme does not allow an explicit port number to be
- specified within the URI, then the default port number implied by
- that URI MUST be used by the client to contact the IPP object.
-
-
-Note: The IPP "Encoding and Transport document [IPP-PRO] shows a mapping
-of IPP onto HTTP/1.1 [RFC2616] and defines a new default port number for
-using IPP over HTTP/1.1.
-
-
-3.1.6 Operation Response Status Codes and Status Messages
-
-Every operation response includes a REQUIRED "status-code" parameter and
-an OPTIONAL "status-message" operation attribute, and an OPTIONAL
-"detailed-status-message" operation attribute. The Print-URI and Send-
-URI response MAY include an OPTIONAL "document-access-error" operation
-attribute.
-
-
-3.1.6.1 "status-code" (type2 enum)
-
-The REQUIRED "status-code" parameter provides information on the
-processing of a request.
-
-The status code is intended for use by automata. A client
-implementation of IPP SHOULD convert status code values into any
-localized message that has semantic meaning to the end user.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 29]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-The "status-code" value is a numeric value that has semantic meaning.
-The "status-code" syntax is similar to a "type2 enum" (see section 4.1
-on "Attribute Syntaxes") except that values can range only from 0x0000
-to 0x7FFF. Section 13 describes the status codes, assigns the numeric
-values, and suggests a corresponding status message for each status code
-for use by the client when the user's natural language is English.
-
-If the Printer performs an operation with no errors and it encounters no
-problems, it MUST return the status code 'successful-ok' in the
-response. See section 13.
-
-If the client supplies unsupported values for the following parameters
-or Operation attributes, the Printer object MUST reject the operation,
-NEED NOT return the unsupported attribute value in the Unsupported
-Attributes group, and MUST return the indicated status code:
-
- Parameter/Attribute Status code
-
- version-number server-error-version-not-supported
- operation-id server-error-operation-not-supported
- attributes-charset client-error-charset-not-supported
- compression client-error-compression-not-supported
- document-format client-error-document-format-not-supported
- document-uri client-error-uri-scheme-not-supported,
- client-error-document-access-error
-
-
-If the client supplies unsupported values for other attributes, or
-unsupported attributes, the Printer returns the status code defined in
-section 3.1.7 on Unsupported Attributes.
-
-
-3.1.6.2 "status-message" (text(255))
-
-The OPTIONAL "status-message" operation attribute provides a short
-textual description of the status of the operation. The "status-
-message" attribute's syntax is "text(255)", so the maximum length is 255
-octets (see section 4.1.1). The status message is intended for the
-human end user. If a response does include a "status-message"
-attribute, an IPP client NEED NOT examine or display the messages,
-however it SHOULD do so in some implementation specific manner. The
-"status-message" is especially useful for a later version of a Printer
-object to return as supplemental information for the human user to
-accompany a status code that an earlier version of a client might not
-understand.
-
-If the Printer object supports the "status-message" operation attribute,
-the Printer object MUST be able to generate this message in any of the
-natural languages identified by the Printer object's "generated-natural-
-language-supported" attribute (see the "attributes-natural-language"
-operation attribute specified in section 3.1.4.1. Section 13 suggests
-the text for the status message returned by the Printer for use with the
-English natural language.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 30]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-As described in section 3.1.4.1 for any returned 'text' attribute, if
-there is a choice for generating this message, the Printer object uses
-the natural language indicated by the value of the "attributes-natural-
-language" in the client request if supported, otherwise the Printer
-object uses the value in the Printer object's own "natural-language-
-configured" attribute.
-
-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 13): '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.
-
-
-3.1.6.3 "detailed-status-message" (text(MAX))
-
-The OPTIONAL "detailed-status-message" operation attribute provides
-additional more detailed technical and implementation-specific
-information about the operation. The "detailed-status-message"
-attribute's syntax is "text(MAX)", so the maximum length is 1023 octets
-(see section 4.1.1). If the Printer objects supports the "detailed-
-status-message" operation attribute, the Printer NEED NOT localize the
-message, since it is intended for use by the system administrator or
-other experienced technical persons. Localization might obscure the
-technical meaning of such messages. Clients MUST NOT attempt to parse
-the value of this attribute. See the "document-access-error" operation
-attribute (section 3.1.6.4) for additional errors that a program can
-process.
-
-
-3.1.6.4 "document-access-error" (text(MAX))
-
-This OPTIONAL operation attribute provides additional information about
-any document access errors encountered by the Printer before it returned
-a response to the Print-URI (section 3.2.2) or Send-URI (section 3.3.1)
-operation. For errors in the protocol identified by the URI scheme in
-the "document-uri" operation attribute, such as 'http:' or 'ftp:', the
-error code is returned in parentheses, followed by the URI. For
-example:
-
- (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-
- 990510.pdf
-
-Most Internet protocols use decimal error codes (unlike IPP), so the
-ASCII error code representation is in decimal.
-
-3.1.7 Unsupported Attributes
-
-The Unsupported Attributes group contains attributes that are not
-supported by the operation. This group is primarily for the job creation
-operations, but all operations can return this group.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 31]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-A Printer object MUST include an Unsupported Attributes group in a
-response if the status code is one of the following: 'successful-ok-
-ignored-or-substituted-attributes', 'successful-ok-conflicting-
-attributes', 'client-error-attributes-or-values-not-supported' or
-'client-error-conflicting-attributes'.
-
-If the status code is one of the four specified in the preceding
-paragraph, the Unsupported Attributes group MUST contain all of those
-attributes and only those attributes that are:
-
- a. an Operation or Job Template attribute supplied in the request, and
-
- b. unsupported by the printer. See below for details on the three
- categories "unsupported" attributes.
-
-If the status code is one of those in the table in section 3.1.6.1, the
-Unsupported Attributes group NEED NOT contain the unsupported parameter
-or attribute indicated in that table.
-
-If the Printer object is not returning any Unsupported Attributes in the
-response, the Printer object SHOULD omit Group 2 rather than sending an
-empty group. However, a client MUST be able to accept an empty group.
-
-Unsupported attributes fall into three categories:
-
- 1. The Printer object does not support the supplied attribute (no
- matter what the attribute syntax or value).
-
- 2. The Printer object does support the attribute, but does not support
- some or all of the particular attribute syntaxes or values supplied
- by the client (i.e., the Printer object does not have those
- attribute syntaxes or values in its corresponding "xxx-supported"
- attribute).
-
- 3. The Printer object does support the attributes and values supplied,
- but the particular values are in conflict with one another, because
- they violate a constraint, such as not being able to staple
- transparencies.
-
-In the case of an unsupported attribute name, the Printer object returns
-the client-supplied attribute with a substituted value of 'unsupported'.
-This value's syntax type is "out-of-band" and its encoding is defined by
-special rules for "out-of-band" values in the "Encoding and Transport"
-document [IPP-PRO]. Its value indicates no support for the attribute
-itself (see the beginning of section 4.1).
-
-In the case of a supported attribute with one or more unsupported
-attribute syntaxes or values, the Printer object simply returns the
-client-supplied attribute with the unsupported attribute syntaxes or
-values as supplied by the client. This indicates support for the
-attribute, but no support for that particular attribute syntax or value.
-If the client supplies a multi-valued attribute with more than one value
-and the Printer object supports the attribute but only supports a subset
-of the client-supplied attribute syntaxes or values, the Printer object
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 32]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-MUST return only those attribute syntaxes or values that are
-unsupported.
-
-In the case of two (or more) supported attribute values that are in
-conflict with one another (although each is supported independently, the
-values conflict when requested together within the same job), the
-Printer object MUST return all the values that it ignores or substitutes
-to resolve the conflict, but not any of the values that it is still
-using. The choice for exactly how to resolve the conflict is
-implementation dependent. See sections 3.2.1.2 and 15. See The
-Implementer's Guide [IPP-IIG] for an example.
-
-
-3.1.8 Versions
-
-Each operation request and response carries with it a "version-number"
-parameter. Each value of the "version-number" is in the form "X.Y"
-where X is the major version number and Y is the minor version number.
-By including a version number in the client request, it allows the
-client to identify which version of IPP it is interested in using,
-i.e., the version whose conformance requirements the client may be
-depending upon the Printer to meet.
-
-If the IPP object does not support that major version number supplied by
-the client, i.e., the major version field of the "version-number"
-parameter does not match any of the values of the Printer's "ipp-
-versions-supported" (see section 4.4.14), the object MUST respond with a
-status code of 'server-error-version-not-supported' along with the
-closest version number that is supported (see section 13.1.5.4). If the
-major version number is supported, but the minor version number is not,
-the IPP object SHOULD accept and attempt to perform the request (or
-reject the request if the operation is not supported), else it rejects
-the request and returns the 'server-error-version-not-supported' status
-code. In all cases, the IPP object MUST return the "version-number"
-that it supports that is closest to the version number supplied by the
-client in the request.
-
-There is no version negotiation per se. However, if after receiving a
-'server-error-version-not-supported' status code from an IPP object, a
-client SHOULD try again with a different version number. A client MAY
-also determine the versions supported either from a directory that
-conforms to Appendix E (see section 16) or by querying the Printer
-object's "ipp-versions-supported" attribute (see section 4.4.14) to
-determine which versions are supported.
-
-An IPP object implementation MUST support version '1.1', i.e., meet the
-conformance requirements for IPP/1.1 as specified in this document and
-[IPP-PRO]. It is recommended that IPP object implementations accept any
-request with the major version '1' (or reject the request if the
-operation is not supported).
-
-There is only one notion of "version number" that covers both IPP Model
-and IPP Protocol changes. Thus the version number MUST change when
-introducing a new version of the Model and Semantics document (this
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 33]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-document) or a new version of the "Encoding and Transport" document
-[IPP-PRO].
-
-Changes to the major version number of the Model and Semantics document
-indicate structural or syntactic changes that make it impossible for
-older version of IPP clients and Printer objects to correctly parse and
-correctly process the new or changed attributes, operations and
-responses. If the major version number changes, the minor version
-numbers is set to zero. As an example, adding the REQUIRED "ipp-
-attribute-fidelity" attribute to version '1.1' (if it had not been part
-of version '1.0'), would have required a change to the major version
-number, since an IPP/1.0 Printer would not have processed a request with
-the correct semantics that contained the "ipp-attribute-fidelity"
-attribute that it did not know about. Items that might affect the
-changing of the major version number include any changes to the Model
-and Semantics document (this document) or the "Encoding and Transport"
-document [IPP-PRO] itself, such as:
-
- - reordering of ordered attributes or attribute sets
- - changes to the syntax of existing attributes
- - adding REQUIRED (for an IPP object to support) operation attribute
- groups
- - adding values to existing REQUIRED operation attributes
- - adding REQUIRED operations
-
-
-Changes to the minor version number indicate the addition of new
-features, attributes and attribute values that may not be understood by
-all IPP objects, but which can be ignored if not understood. Items that
-might affect the changing of the minor version number include any
-changes to the model objects and attributes but not the encoding and
-transport rules [IPP-PRO] (except adding attribute syntaxes). Examples
-of such changes are:
-
- - grouping all extensions not included in a previous version into a
- new version
- - adding new attribute values
- - adding new object attributes
- - adding OPTIONAL (for an IPP object to support) operation attributes
- (i.e., those attributes that an IPP object can ignore without
- confusing clients)
- - adding OPTIONAL (for an IPP object to support) operation attribute
- groups (i.e., those attributes that an IPP object can ignore
- without confusing clients)
- - adding new attribute syntaxes
- - adding OPTIONAL operations
- - changing Job Description attributes or Printer Description
- attributes from OPTIONAL to REQUIRED or vice versa.
- - adding OPTIONAL attribute syntaxes to an existing attribute.
-
-The encoding of the "version-number" MUST NOT change over any version
-number (either major or minor). This rule guarantees that all future
-versions will be backwards compatible with all previous versions (at
-least for checking the "version-number"). In addition, any protocol
-elements (attributes, error codes, tags, etc.) that are not carried
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 34]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-forward from one version to the next are deprecated so that they can
-never be reused with new semantics.
-
-Implementations that support a certain version NEED NOT support ALL
-previous versions. As each new version is defined (through the release
-of a new IPP specification document), that version will specify which
-previous versions MUST and which versions SHOULD be supported in
-compliant implementations.
-
-
-3.1.9 Job Creation Operations
-
-In order to "submit a print job" and create a new Job object, a client
-issues a create request. A create request is any one of following three
-operation requests:
-
- - The Print-Job Request: A client that wants to submit a print job
- with only a single document uses the Print-Job operation. The
- operation allows for the client to "push" the document data to the
- Printer object by including the document data in the request
- itself.
-
- - The Print-URI Request: A client that wants to submit a print job
- with only a single document (where the Printer object "pulls" the
- document data instead of the client "pushing" the data to the
- Printer object) uses the Print-URI operation. In this case, the
- client includes in the request only a URI reference to the document
- data (not the document data itself).
-
- - The Create-Job Request: A client that wants to submit a print job
- with multiple documents uses the Create-Job operation. This
- operation is followed by an arbitrary number (one or more) of Send-
- Document and/or Send-URI operations (each creating another document
- for the newly create Job object). The Send-Document operation
- includes the document data in the request (the client "pushes" the
- document data to the printer), and the Send-URI operation includes
- only a URI reference to the document data in the request (the
- Printer "pulls" the document data from the referenced location).
- The last Send-Document or Send-URI request for a given Job object
- includes a "last-document" operation attribute set to 'true'
- indicating that this is the last request.
-
-
-Throughout this model document, the term "create request" is used to
-refer to any of these three operation requests.
-
-A Create-Job operation followed by only one Send-Document operation is
-semantically equivalent to a Print-Job operation, however, for
-performance reasons, the client SHOULD use the Print-Job operation for
-all single document jobs. Also, Print-Job is a REQUIRED operation (all
-implementations MUST support it) whereas Create-Job is an OPTIONAL
-operation, hence some implementations might not support it.
-
-Job submission time is the point in time when a client issues a create
-request. The initial state of every Job object is the 'pending',
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 35]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-'pending-held', or 'processing' state (see section 4.3.7). When the
-Printer object begins processing the print job, the Job object's state
-moves to 'processing'. This is known as job processing time. There are
-validation checks that must be done at job submission time and others
-that must be performed at job processing time.
-
-At job submission time and at the time a Validate-Job operation is
-received, the Printer MUST do the following:
-
- 1. Process the client supplied attributes and either accept or reject
- the request
- 2. Validate the syntax of and support for the scheme of any client
- supplied URI
-
-
-At job submission time the Printer object MUST validate whether or not
-the supplied attributes, attribute syntaxes, and values are supported by
-matching them with the Printer object's corresponding "xxx-supported"
-attributes. See section 3.1.7 for details. [IPP-IIG] presents
-suggested steps for an IPP object to either accept or reject any request
-and additional steps for processing create requests.
-
-At job submission time the Printer object NEED NOT perform the
-validation checks reserved for job processing time such as:
-
- 1. Validating the document data
- 2. Validating the actual contents of any client supplied URI (resolve
- the reference and follow the link to the document data)
-
-
-At job submission time, these additional job processing time validation
-checks are essentially useless, since they require actually parsing and
-interpreting the document data, are not guaranteed to be 100% accurate,
-and MUST be done, yet again, at job processing time. Also, in the case
-of a URI, checking for availability at job submission time does not
-guarantee availability at job processing time. In addition, at job
-processing time, the Printer object might discover any of the following
-conditions that were not detectable at job submission time:
-
- - runtime errors in the document data,
- - nested document data that is in an unsupported format,
- - the URI reference is no longer valid (i.e., the server hosting the
- document might be down), or
- - any other job processing error
-
-
-At job submission time, a Printer object, especially a non-spooling
-Printer, MAY accept jobs that it does not have enough space for. In
-such a situation, a Printer object MAY stop reading data from a client
-for an indefinite period of time. A client MUST be prepared for a write
-operation to block for an indefinite period of time (see section 5.1 on
-client conformance).
-
-When a Printer object has too little space for starting a new job, it
-MAY reject a new create request. In this case, a Printer object MUST
-return a response (in reply to the rejected request) with a status-code
-of 'server-error-busy' (see section 14.1.5.8) and it MAY close the
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 36]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-connection before receiving all bytes of the operation. A Printer
-SHOULD indicate that it is temporarily unable to accept jobs by setting
-the 'spool-space-full' value in its "printer-state-reasons" attribute
-and removing the value when it can accept another job (see section
-4.4.12).
-
-When receiving a 'server-error-busy' status-code in an operation
-response, a client MUST be prepared for the Printer object to close the
-connection before the client has sent all of the data (especially for
-the Print-Job operation). A client MUST be prepared to keep submitting a
-create request until the IPP Printer object accepts the create request.
-
-At job processing time, since the Printer object has already responded
-with a successful status code in the response to the create request, if
-the Printer object detects an error, the Printer object is unable to
-inform the end user of the error with an operation status code. In
-this case, the Printer, depending on the error, can set the job object's
-"job-state", "job-state-reasons", or "job-state-message" attributes to
-the appropriate value(s) so that later queries can report the correct
-job status.
-
-Note: Asynchronous notification of events is outside the scope of this
-IPP/1.1 document.
-
-
-
-
-3.2 Printer Operations
-
-
-All Printer operations are directed at Printer objects. A client MUST
-always supply the "printer-uri" operation attribute in order to identify
-the correct target of the operation.
-
-
-3.2.1 Print-Job Operation
-
-This REQUIRED operation allows a client to submit a print job with only
-one document and supply the document data (rather than just a reference
-to the data). See Section 15 for the suggested steps for processing
-create operations and their Operation and Job Template attributes.
-
-
-3.2.1.1 Print-Job Request
-
-The following groups of attributes are supplied as part of the Print-Job
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.1. The Printer object
- MUST copy these values to the corresponding Job Description
- attributes described in sections 4.3.19 and 4.3.20.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 37]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- Target:
- The "printer-uri" (uri) operation attribute which is the target for
- this operation as described in section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in section 8.3.
-
- "job-name" (name(MAX)):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It contains the client supplied Job
- name. If this attribute is supplied by the client, its value is
- used for the "job-name" attribute of the newly created Job object.
- The client MAY automatically include any information that will help
- the end-user distinguish amongst his/her jobs, such as the name of
- the application program along with information from the document,
- such as the document name, document subject, or source file name.
- If this attribute is not supplied by the client, the Printer
- generates a name to use in the "job-name" attribute of the newly
- created Job object (see Section 4.3.5).
-
- "ipp-attribute-fidelity" (boolean):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. The value 'true' indicates that total
- fidelity to client supplied Job Template attributes and values is
- required, else the Printer object MUST reject the Print-Job
- request. The value 'false' indicates that a reasonable attempt to
- print the Job object is acceptable and the Printer object MUST
- accept the Print-Job request. If not supplied, the Printer object
- assumes the value is 'false'. All Printer objects MUST support
- both types of job processing. See section 15 for a full
- description of "ipp-attribute-fidelity" and its relationship to
- other attributes, especially the Printer object's "pdl-override-
- supported" attribute.
-
- "document-name" (name(MAX)):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It contains the client supplied
- document name. The document name MAY be different than the Job
- name. Typically, the client software automatically supplies the
- document name on behalf of the end user by using a file name or an
- application generated name. If this attribute is supplied, its
- value can be used in a manner defined by each implementation.
- Examples include: printed along with the Job (job start sheet, page
- adornments, etc.), used by accounting or resource tracking
- management tools, or even stored along with the document as a
- document level attribute. IPP/1.1 does not support the concept of
- document level attributes.
-
- "compression" (type3 keyword)
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute and the "compression-supported"
- attribute (see section 4.4.32). The client supplied "compression"
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 38]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- operation attribute identifies the compression algorithm used on
- the document data. The following cases exist:
- a)If the client omits this attribute, the Printer object MUST
- assume that the data is not compressed (i.e. the Printer
- follows the rules below as if the client supplied the
- "compression" attribute with a value of 'none').
- b)If the client supplies this attribute, but the value is not
- supported by the Printer object, i.e., the value is not one
- of the values of the Printer object's "compression-
- supported" attribute, the Printer object MUST reject the
- request, and return the 'client-error-compression-not-
- supported' status code. See section 3.1.7 for returning
- unsupported attributes and values.
- c)If the client supplies the attribute and the Printer object
- supports the attribute value, the Printer object uses the
- corresponding decompression algorithm on the document data.
- d)If the decompression algorithm fails before the Printer
- returns an operation response, the Printer object MUST
- reject the request and return the 'client-error-
- compression-error' status code.
- e)If the decompression algorithm fails after the Printer
- returns an operation response, the Printer object MUST
- abort the job and add the 'compression-error' value to the
- job's "job-state-reasons" attribute.
- f)If the decompression algorithm succeeds, the document data
- MUST then have the format specified by the job's "document-
- format" attribute, if supplied (see "document-format"
- operation attribute definition below).
-
- "document-format" (mimeMediaType) :
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. The value of this attribute
- identifies the format of the supplied document data. The following
- cases exist:
- a)If the client does not supply this attribute, the Printer
- object assumes that the document data is in the format
- defined by the Printer object's "document-format-default"
- attribute. (i.e. the Printer follows the rules below as if
- the client supplied the "document-format" attribute with a
- value equal to the printer's default value).
- b)If the client supplies this attribute, but the value is not
- supported by the Printer object, i.e., the value is not one
- of the values of the Printer object's "document-format-
- supported" attribute, the Printer object MUST reject the
- request and return the 'client-error-document-format-not-
- supported' status code.
- c)If the client supplies this attribute and its value is
- 'application/octet-stream' (i.e. to be auto-sensed, see
- Section 4.1.9.1), and the format is not one of the
- document-formats that the Printer can auto-sense, and this
- check occurs before the Printer returns an operation
- response, then the Printer MUST reject the request and
- return the 'client-error-document-format-not-supported'
- status code.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 39]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- d)If the client supplies this attribute, and the value is
- supported by the Printer object, the Printer is capable of
- interpreting the document data.
- e)If interpreting of the document data fails before the
- Printer returns an operation response, the Printer object
- MUST reject the request and return the 'client-error-
- document-format-error' status code.
- f)If interpreting of the document data fails after the
- Printer returns an operation response, the Printer object
- MUST abort the job and add the 'document-format-error'
- value to the job's "job-state-reasons" attribute.
-
- "document-natural-language" (naturalLanguage):
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. This attribute specifies the
- natural language of the document for those document-formats that
- require a specification of the natural language in order to image
- the document unambiguously. There are no particular values required
- for the Printer object to support.
-
- "job-k-octets" (integer(0:MAX))
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute and the "job-k-octets-supported"
- attribute (see section 4.4.33). The client supplied "job-k-octets"
- operation attribute identifies the total size of the document(s) in
- K octets being submitted (see section 4.3.17.1 for the complete
- semantics). If the client supplies the attribute and the Printer
- object supports the attribute, the value of the attribute is used
- to populate the Job object's "job-k-octets" Job Description
- attribute.
-
- For this attribute and the following two attributes ("job-
- impressions", and "job-media-sheets"), if the client supplies the
- attribute, but the Printer object does not support the attribute,
- the Printer object ignores the client-supplied value. If the
- client supplies the attribute and the Printer supports the
- attribute, and the value is within the range of the corresponding
- Printer object's "xxx-supported" attribute, the Printer object MUST
- use the value to populate the Job object's "xxx" attribute. If the
- client supplies the attribute and the Printer supports the
- attribute, but the value is outside the range of the corresponding
- Printer object's "xxx-supported" attribute, the Printer object MUST
- copy the attribute and its value to the Unsupported Attributes
- response group, reject the request, and return the 'client-error-
- attributes-or-values-not-supported' status code. If the client
- does not supply the attribute, the Printer object MAY choose to
- populate the corresponding Job object attribute depending on
- whether the Printer object supports the attribute and is able to
- calculate or discern the correct value.
-
- "job-impressions" (integer(0:MAX))
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute and the "job-impressions-
- supported" attribute (see section 4.4.34). The client supplied
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 40]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- "job-impressions" operation attribute identifies the total size in
- number of impressions of the document(s) being submitted (see
- section 4.3.17.2 for the complete semantics).
-
- See last paragraph under "job-k-octets".
-
- "job-media-sheets" (integer(0:MAX))
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute and the "job-media-sheets-
- supported" attribute (see section 4.4.35). The client supplied
- "job-media-sheets" operation attribute identifies the total number
- of media sheets to be produced for this job (see section 4.3.17.3
- for the complete semantics).
-
- See last paragraph under "job-k-octets".
-
-
-Group 2: Job Template Attributes
-
- The client OPTIONALLY supplies a set of Job Template attributes as
- defined in section 4.2. If the client is not supplying any Job
- Template attributes in the request, the client SHOULD omit Group 2
- rather than sending an empty group. However, a Printer object MUST
- be able to accept an empty group.
-
-
-Group 3: Document Content
-
- The client MUST supply the document data to be processed.
-
-
-In addition to the MANDATORY parameters required for every operation
-request, the simplest Print-Job Request consists of just the
-"attributes-charset" and "attributes-natural-language" operation
-attributes; the "printer-uri" target operation attribute; the Document
-Content and nothing else. In this simple case, the Printer object:
-
- - creates a new Job object (the Job object contains a single
- document),
- - stores a generated Job name in the "job-name" attribute in the
- natural language and charset requested (see Section 3.1.4.1) (if
- those are supported, otherwise using the Printer object's default
- natural language and charset), and
- - at job processing time, uses its corresponding default value
- attributes for the supported Job Template attributes that were not
- supplied by the client as IPP attribute or embedded instructions in
- the document data.
-
-
-
-3.2.1.2 Print-Job Response
-
-The Printer object MUST return to the client the following sets of
-attributes as part of the Print-Job Response:
-
-Group 1: Operation Attributes
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 41]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in sections 13 and 3.1.6. If the client supplies
- unsupported or conflicting Job Template attributes or values, the
- Printer object MUST reject or accept the Print-Job request
- depending on the whether the client supplied a 'true' or 'false'
- value for the "ipp-attribute-fidelity" operation attribute. See
- the Implementer's Guide [IPP-IIG] for a complete description of the
- suggested steps for processing a create request.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See section 3.1.7 for details on returning Unsupported Attributes.
-
- The value of the "ipp-attribute-fidelity" supplied by the client
- does not affect what attributes the Printer object returns in this
- group. The value of "ipp-attribute-fidelity" only affects whether
- the Print-Job operation is accepted or rejected. If the job is
- accepted, the client may query the job using the Get-Job-Attributes
- operation requesting the unsupported attributes that were returned
- in the create response to see which attributes were ignored (not
- stored on the Job object) and which attributes were stored with
- other (substituted) values.
-
-
-Group 3: Job Object Attributes
-
- "job-uri" (uri):
- The Printer object MUST return the Job object's URI by returning
- the contents of the REQUIRED "job-uri" Job object attribute. The
- client uses the Job object's URI when directing operations at the
- Job object. The Printer object always uses its configured security
- policy when creating the new URI. However, if the Printer object
- supports more than one URI, the Printer object also uses
- information about which URI was used in the Print-Job Request to
- generated the new URI so that the new URI references the correct
- access channel. In other words, if the Print-Job Request comes in
- over a secure channel, the Printer object MUST generate a Job URI
- that uses the secure channel as well.
-
- "job-id" (integer(1:MAX)):
- The Printer object MUST return the Job object's Job ID by returning
- the REQUIRED "job-id" Job object attribute. The client uses this
- "job-id" attribute in conjunction with the "printer-uri" attribute
- used in the Print-Job Request when directing Job operations at the
- Printer object.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 42]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- "job-state":
- The Printer object MUST return the Job object's REQUIRED "job-
- state" attribute. The value of this attribute (along with the value
- of the next attribute: "job-state-reasons") is taken from a
- "snapshot" of the new Job object at some meaningful point in time
- (implementation defined) between when the Printer object receives
- the Print-Job Request and when the Printer object returns the
- response.
-
- "job-state-reasons":
- The Printer object MUST return the Job object's REQUIRED "job-
- state-reasons" attribute.
-
- "job-state-message":
- The Printer object OPTIONALLY returns the Job object's OPTIONAL
- "job-state-message" attribute. If the Printer object supports this
- attribute then it MUST be returned in the response. If this
- attribute is not returned in the response, the client can assume
- that the "job-state-message" attribute is not supported and will
- not be returned in a subsequent Job object query.
-
- "number-of-intervening-jobs":
- The Printer object OPTIONALLY returns the Job object's OPTIONAL
- "number-of-intervening-jobs" attribute. If the Printer object
- supports this attribute then it MUST be returned in the response.
- If this attribute is not returned in the response, the client can
- assume that the "number-of-intervening-jobs" attribute is not
- supported and will not be returned in a subsequent Job object
- query.
-
- Note: Since any printer state information which affects a job's
- state is reflected in the "job-state" and "job-state-reasons"
- attributes, it is sufficient to return only these attributes and no
- specific printer status attributes.
-
-
-Note: In addition to the MANDATORY parameters required for every
-operation response, the simplest response consists of the just the
-"attributes-charset" and "attributes-natural-language" operation
-attributes and the "job-uri", "job-id", and "job-state" Job Object
-Attributes. In this simplest case, the status code is 'successful-ok'
-and there is no "status-message" or "detailed-status-message" operation
-attribute.
-
-
-3.2.2 Print-URI Operation
-
-This OPTIONAL operation is identical to the Print-Job operation (section
-3.2.1) except that a client supplies a URI reference to the document
-data using the "document-uri" (uri) operation attribute (in Group 1)
-rather than including the document data itself. Before returning the
-response, the Printer MUST validate that the Printer supports the
-retrieval method (e.g., http, ftp, etc.) implied by the URI, and MUST
-check for valid URI syntax. If the client-supplied URI scheme is not
-supported, i.e. the value is not in the Printer object's "referenced-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 43]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-uri-scheme-supported" attribute, the Printer object MUST reject the
-request and return the 'client-error-uri-scheme-not-supported' status
-code.
-
-The IPP Printer MAY validate the accessibility of the document as part
-of the operation or subsequently. If the Printer determines an
-accessibility problem before returning an operation response, it rejects
-the request and returns the 'client-error-document-access-error' status
-code. The Printer MAY also return a specific document access error code
-using the "document-access-error" operation attribute (see section
-3.1.6.4).
-
-If the Printer determines this document accessibility problem after
-accepting the request and returning an operation response with one of
-the successful status codes, the Printer adds the 'document-access-
-error' value to the job's "job-state-reasons" attribute and MAY populate
-the job's "job-document-access-errors" Job Description attribute (see
-section 4.3.11). See The Implementer's Guide [IPP-IIG] for suggested
-additional checks.
-
-If the Printer object supports this operation, it MUST support the
-"reference-uri-schemes-supported" Printer attribute (see section
-4.4.27).
-
-It is up to the IPP object to interpret the URI and subsequently "pull"
-the document from the source referenced by the URI string.
-
-
-3.2.3 Validate-Job Operation
-
-This REQUIRED operation is similar to the Print-Job operation (section
-3.2.1) except that a client supplies no document data and the Printer
-allocates no resources (i.e., it does not create a new Job object).
-This operation is used only to verify capabilities of a printer object
-against whatever attributes are supplied by the client in the Validate-
-Job request. By using the Validate-Job operation a client can validate
-that an identical Print-Job operation (with the document data) would be
-accepted. The Validate-Job operation also performs the same security
-negotiation as the Print-Job operation (see section 8), so that a client
-can check that the client and Printer object security requirements can
-be met before performing a Print-Job operation.
-
-The Validate-Job operation does not accept a "document-uri" attribute in
-order to allow a client to check that the same Print-URI operation will
-be accepted, since the client doesn't send the data with the Print-URI
-operation. The client SHOULD just issue the Print-URI request.
-
-The Printer object returns the same status codes, Operation Attributes
-(Group 1) and Unsupported Attributes (Group 2) as the Print-Job
-operation. However, no Job Object Attributes (Group 3) are returned,
-since no Job object is created.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 44]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-3.2.4 Create-Job Operation
-
-This OPTIONAL operation is similar to the Print-Job operation (section
-3.2.1) except that in the Create-Job request, a client does not supply
-document data or any reference to document data. Also, the client does
-not supply any of the "document-name", "document-format", "compression",
-or "document-natural-language" operation attributes. This operation is
-followed by one or more Send-Document or Send-URI operations. In each
-of those operation requests, the client OPTIONALLY supplies the
-"document-name", "document-format", and "document-natural-language"
-attributes for each document in the multi-document Job object.
-
-If a Printer object supports the Create-Job operation, it MUST also
-support the Send-Document operation and also MAY support the Send-URI
-operation.
-
-If the Printer object supports this operation, it MUST support the
-"multiple-operation-time-out" Printer attribute (see section 4.4.31).
-
-If the Printer object supports this operation, then it MUST support the
-"multiple-document-jobs-supported" Printer Description attribute (see
-section 4.4.16) and indicate whether or not it supports multiple-
-document jobs.
-
-If the Printer object supports this operation and supports multiple
-documents in a job, then it MUST support the "multiple-document-
-handling" Job Template job attribute with at least one value (see
-section 4.2.4) and the associated "multiple-document-handling-default"
-and "multiple-document-handling-supported" Job Template Printer
-attributes (see section 4.2).
-
-After the Create-Job operation has completed, the value of the "job-
-state" attribute is similar to the "job-state" after a Print-Job, even
-though no document-data has arrived. A Printer MAY set the 'job-data-
-insufficient' value of the job's "job-state-reason" attribute to
-indicate that processing cannot begin until sufficient data has arrived
-and set the "job-state" to either 'pending' or 'pending-held'. A non-
-spooling printer that doesn't implement the 'pending' job state may even
-set the "job-state" to 'processing', even though there is not yet any
-data to process. See sections 4.3.7 and 4.3.8.
-
-
-3.2.5 Get-Printer-Attributes Operation
-
-This REQUIRED operation allows a client to request the values of the
-attributes of a Printer object. In the request, the client supplies
-the set of Printer attribute names and/or attribute group names in which
-the requester is interested. In the response, the Printer object
-returns a corresponding attribute set with the appropriate attribute
-values filled in.
-
-For Printer objects, the possible names of attribute groups are:
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 45]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- - 'job-template': the subset of the Job Template attributes that
- apply to a Printer object (the last two columns of the table in
- Section 4.2) that the implementation supports for Printer objects.
- - 'printer-description': the subset of the attributes specified in
- Section 4.4 that the implementation supports for Printer objects.
- - 'all': the special group 'all' that includes all attributes that
- the implementation supports for Printer objects.
-
-
-Since a client MAY request specific attributes or named groups, there is
-a potential that there is some overlap. For example, if a client
-requests, 'printer-name' and 'all', the client is actually requesting
-the "printer-name" attribute twice: once by naming it explicitly, and
-once by inclusion in the 'all' group. In such cases, the Printer object
-NEED NOT return each attribute only once in the response even if it is
-requested multiple times. The client SHOULD NOT request the same
-attribute in multiple ways.
-
-It is NOT REQUIRED that a Printer object support all attributes
-belonging to a group (since some attributes are OPTIONAL). However, it
-is REQUIRED that each Printer object support all group names.
-
-
-3.2.5.1 Get-Printer-Attributes Request
-
-The following sets of attributes are part of the Get-Printer-Attributes
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.1.
-
- Target:
- The "printer-uri" (uri) operation attribute which is the target for
- this operation as described in section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in section 8.3.
-
- "requested-attributes" (1setOf keyword) :
- The client OPTIONALLY supplies a set of attribute names and/or
- attribute group names in whose values the requester is interested.
- The Printer object MUST support this attribute. If the client
- omits this attribute, the Printer MUST respond as if this attribute
- had been supplied with a value of 'all'.
-
- "document-format" (mimeMediaType) :
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. This attribute is useful for a
- Printer object to determine the set of supported attribute values
- that relate to the requested document format. The Printer object
- MUST return the attributes and values that it uses to validate a
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 46]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- job on a create or Validate-Job operation in which this document
- format is supplied. The Printer object SHOULD return only (1) those
- attributes that are supported for the specified format and (2) the
- attribute values that are supported for the specified document
- format. By specifying the document format, the client can get the
- Printer object to eliminate the attributes and values that are not
- supported for a specific document format. For example, a Printer
- object might have multiple interpreters to support both
- 'application/postscript' (for PostScript) and 'text/plain' (for
- text) documents. However, for only one of those interpreters might
- the Printer object be able to support "number-up" with values of
- '1', '2', and '4'. For the other interpreter it might be able to
- only support "number-up" with a value of '1'. Thus a client can use
- the Get-Printer-Attributes operation to obtain the attributes and
- values that will be used to accept/reject a create job operation.
-
- If the Printer object does not distinguish between different sets
- of supported values for each different document format when
- validating jobs in the create and Validate-Job operations, it MUST
- NOT distinguish between different document formats in the Get-
- Printer-Attributes operation. If the Printer object does
- distinguish between different sets of supported values for each
- different document format specified by the client, this
- specialization applies only to the following Printer object
- attributes:
-
- - Printer attributes that are Job Template attributes ("xxx-
- default" "xxx-supported", and "xxx-ready" in the Table in
- Section 4.2),
- - "pdl-override-supported",
- - "compression-supported",
- - "job-k-octets-supported",
- - "job-impressions-supported",
- - "job-media-sheets-supported",
- - "printer-driver-installer",
- - "color-supported", and
- - "reference-uri-schemes-supported"
-
- The values of all other Printer object attributes (including
- "document-format-supported") remain invariant with respect to the
- client supplied document format (except for new Printer description
- attribute as registered according to section 6.2).
-
- If the client omits this "document-format" operation attribute, the
- Printer object MUST respond as if the attribute had been supplied
- with the value of the Printer object's "document-format-default"
- attribute. It is RECOMMENDED that the client always supply a value
- for "document-format", since the Printer object's "document-format-
- default" may be 'application/octet-stream', in which case the
- returned attributes and values are for the union of the document
- formats that the Printer can automatically sense. For more
- details, see the description of the 'mimeMediaType' attribute
- syntax in section 4.1.9.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 47]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- If the client supplies a value for the "document-format" Operation
- attribute that is not supported by the Printer, i.e., is not among
- the values of the Printer object's "document-format-supported"
- attribute, the Printer object MUST reject the operation and return
- the 'client-error-document-format-not-supported' status code.
-
-
-3.2.5.2 Get-Printer-Attributes Response
-
-The Printer object returns the following sets of attributes as part of
-the Get-Printer-Attributes Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See section 3.1.7 for details on returning Unsupported Attributes.
-
- The response NEED NOT contain the "requested-attributes" operation
- attribute with any supplied values (attribute keywords) that were
- requested by the client but are not supported by the IPP object. If
- the Printer object does include unsupported attributes referenced
- in "requested-attributes" and such attributes include group names,
- such as 'all', the unsupported attributes MUST NOT include
- attributes described in the standard but not supported by the
- implementation.
-
-
-Group 3: Printer Object Attributes
-
- This is the set of requested attributes and their current values.
- The Printer object ignores (does not respond with) any requested
- attribute which is not supported. The Printer object MAY respond
- with a subset of the supported attributes and values, depending on
- the security policy in force. However, the Printer object MUST
- respond with the 'unknown' value for any supported attribute
- (including all REQUIRED attributes) for which the Printer object
- does not know the value. Also the Printer object MUST respond with
- the 'no-value' for any supported attribute (including all REQUIRED
- attributes) for which the system administrator has not configured a
- value. See the description of the "out-of-band" values in the
- beginning of Section 4.1.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 48]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-3.2.6 Get-Jobs Operation
-
-This REQUIRED operation allows a client to retrieve the list of Job
-objects belonging to the target Printer object. The client may also
-supply a list of Job attribute names and/or attribute group names. A
-group of Job object attributes will be returned for each Job object that
-is returned.
-
-This operation is similar to the Get-Job-Attributes operation, except
-that this Get-Jobs operation returns attributes from possibly more than
-one object (see the description of Job attribute group names in section
-3.3.4).
-
-
-3.2.6.1 Get-Jobs Request
-
-The client submits the Get-Jobs request to a Printer object.
-
-The following groups of attributes are part of the Get-Jobs Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.1.
-
- Target:
- The "printer-uri" (uri) operation attribute which is the target for
- this operation as described in section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in section 8.3.
-
- "limit" (integer(1:MAX)):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It is an integer value that determines
- the maximum number of jobs that a client will receive from the
- Printer even if "which-jobs" or "my-jobs" constrain which jobs are
- returned. The limit is a "stateless limit" in that if the value
- supplied by the client is 'N', then only the first 'N' jobs are
- returned in the Get-Jobs Response. There is no mechanism to allow
- for the next 'M' jobs after the first 'N' jobs. If the client does
- not supply this attribute, the Printer object responds with all
- applicable jobs.
-
- "requested-attributes" (1setOf keyword):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It is a set of Job attribute names
- and/or attribute groups names in whose values the requester is
- interested. This set of attributes is returned for each Job object
- that is returned. The allowed attribute group names are the same
- as those defined in the Get-Job-Attributes operation in section
- 3.3.4. If the client does not supply this attribute, the Printer
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 49]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- MUST respond as if the client had supplied this attribute with two
- values: 'job-uri' and 'job-id'.
-
- "which-jobs" (type2 keyword):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It indicates which Job objects MUST
- be returned by the Printer object. The values for this attribute
- are:
-
- 'completed': This includes any Job object whose state is
- 'completed', 'canceled', or 'aborted'.
- 'not-completed': This includes any Job object whose state is
- 'pending', 'processing', 'processing-stopped', or 'pending-
- held'.
-
- A Printer object MUST support both values. However, if the
- implementation does not keep jobs in the 'completed', 'canceled',
- and 'aborted' states, then it returns no jobs when the 'completed'
- value is supplied.
-
- If a client supplies some other value, the Printer object MUST copy
- the attribute and the unsupported value to the Unsupported
- Attributes response group, reject the request, and return the
- 'client-error-attributes-or-values-not-supported' status code.
-
- If the client does not supply this attribute, the Printer object
- MUST respond as if the client had supplied the attribute with a
- value of 'not-completed'.
-
- "my-jobs" (boolean):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It indicates whether jobs from all
- users or just the jobs submitted by the requesting user of this
- request MUST be returned by the Printer object. If the client does
- not supply this attribute, the Printer object MUST respond as if
- the client had supplied the attribute with a value of 'false',
- i.e., jobs from all users. The means for authenticating the
- requesting user and matching the jobs is described in section 8.
-
-3.2.6.2 Get-Jobs Response
-
-The Printer object returns all of the Job objects up to the number
-specified by the "limit" attribute that match the criteria as defined by
-the attribute values supplied by the client in the request. It is
-possible that no Job objects are returned since there may literally be
-no Job objects at the Printer, or there may be no Job objects that match
-the criteria supplied by the client. If the client requests any Job
-attributes at all, there is a set of Job Object Attributes returned for
-each Job object.
-
-It is not an error for the Printer to return 0 jobs. If the response
-returns 0 jobs because there are no jobs matching the criteria, and the
-request would have returned 1 or more jobs with a status code of
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 50]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-'successful-ok' if there had been jobs matching the criteria, then the
-status code for 0 jobs MUST be 'successful-ok'.
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See section 3.1.7 for details on returning Unsupported Attributes.
-
- The response NEED NOT contain the "requested-attributes" operation
- attribute with any supplied values (attribute keywords) that were
- requested by the client but are not supported by the IPP object. If
- the Printer object does include unsupported attributes referenced
- in "requested-attributes" and such attributes include group names,
- such as 'all', the unsupported attributes MUST NOT include
- attributes described in the standard but not supported by the
- implementation.
-
-
-Groups 3 to N: Job Object Attributes
-
- The Printer object responds with one set of Job Object Attributes
- for each returned Job object. The Printer object ignores (does not
- respond with) any requested attribute or value which is not
- supported or which is restricted by the security policy in force,
- including whether the requesting user is the user that submitted
- the job (job originating user) or not (see section 8). However,
- the Printer object MUST respond with the 'unknown' value for any
- supported attribute (including all REQUIRED attributes) for which
- the Printer object does not know the value, unless it would violate
- the security policy. See the description of the "out-of-band"
- values in the beginning of Section 4.1.
-
-
- Jobs are returned in the following order:
-
- - If the client requests all 'completed' Jobs (Jobs in the
- 'completed', 'aborted', or 'canceled' states), then the Jobs
- are returned newest to oldest (with respect to actual
- completion time)
- - If the client requests all 'not-completed' Jobs (Jobs in the
- 'pending', 'processing', 'pending-held', and 'processing-
- stopped' states), then Jobs are returned in relative
- chronological order of expected time to complete (based on
- whatever scheduling algorithm is configured for the Printer
- object).
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 51]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-3.2.7 Pause-Printer Operation
-
-This OPTIONAL operation allows a client to stop the Printer object from
-scheduling jobs on all its devices. Depending on implementation, the
-Pause-Printer operation MAY also stop the Printer from processing the
-current job or jobs. Any job that is currently being printed is either
-stopped as soon as the implementation permits or is completed, depending
-on implementation. The Printer object MUST still accept create
-operations to create new jobs, but MUST prevent any jobs from entering
-the 'processing' state.
-
-If the Pause-Printer operation is supported, then the Resume-Printer
-operation MUST be supported, and vice-versa.
-
-The IPP Printer stops the current job(s) on its device(s) that were in
-the 'processing' or 'processing-stopped' states as soon as the
-implementation permits. If the implementation will take appreciable
-time to stop, the IPP Printer adds the 'moving-to-paused' value to the
-Printer object's "printer-state-reasons" attribute (see section 4.4.12).
-When the device(s) have all stopped, the IPP Printer transitions the
-Printer object to the 'stopped' state, removes the 'moving-to-paused'
-value, if present, and adds the 'paused' value to the Printer object's
-"printer-state-reasons" attribute.
-
-When the current job(s) complete that were in the 'processing' state,
-the IPP Printer transitions them to the 'completed' state. When the
-current job(s) stop in mid processing that were in the 'processing'
-state, the IPP Printer transitions them to the 'processing-stopped'
-state and adds the 'printer-stopped' value to the job's "job-state-
-reasons" attribute.
-
-For any jobs that are 'pending' or 'pending-held', the 'printer-stopped'
-value of the jobs' "job-state-reasons" attribute also applies. However,
-the IPP Printer NEED NOT update those jobs' "job-state-reasons"
-attributes and only need return the 'printer-stopped' value when those
-jobs are queried (so-called "lazy evaluation").
-
-Whether the Pause-Printer operation affects jobs that were submitted to
-the device from other sources than the IPP Printer object in the same
-way that the Pause-Printer operation affects jobs that were submitted to
-the IPP Printer object using IPP, depends on implementation, i.e., on
-whether the IPP protocol is being used as a universal management
-protocol or just to manage IPP jobs, respectively.
-
-The IPP Printer MUST accept the request in any state and transition the
-Printer to the indicated new "printer-state" before returning as
-follows:
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 52]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
- Current New "printer IPP Printer's response status
- "printer- "printer- -state- code and action:
- state" state" reasons"
-
- 'idle' 'stopped' 'paused' 'successful-ok'
- 'processing' 'processing' 'moving- OPTION 1: 'successful-ok';
- to- Later, when all output has
- paused' stopped, the "printer-state"
- becomes 'stopped', and the
- 'paused' value replaces the
- 'moving-to-paused' value in the
- "printer-state-reasons"
- attribute
- 'processing' 'stopped' 'paused' OPTION 2: 'successful-ok';
- all device output stopped
- immediately
- 'stopped' 'stopped' 'paused' 'successful-ok'
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must be an operator or administrator of the Printer object
-(see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the
-operation and return: 'client-error-forbidden', 'client-error-not-
-authenticated', or 'client-error-not-authorized' as appropriate.
-
-
-3.2.7.1 Pause-Printer Request
-
-The following groups of attributes are part of the Pause-Printer
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.1.
-
- Target:
- The "printer-uri" (uri) operation attribute which is the target for
- this operation as described in section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in section 8.3.
-
-3.2.7.2 Pause-Printer Response
-
-The following groups of attributes are part of the Pause-Printer
-Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in sections 13 and 3.1.6.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 53]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See section 3.1.7 for details on returning Unsupported Attributes.
-
-
-3.2.8 Resume-Printer Operation
-
-This operation allows a client to resume the Printer object scheduling
-jobs on all its devices. The Printer object MUST remove the 'paused'
-and 'moving-to-paused' values from the Printer object's "printer-state-
-reasons" attribute, if present. If there are no other reasons to keep a
-device paused (such as media-jam), the IPP Printer is free to transition
-itself to the 'processing' or 'idle' states, depending on whether there
-are jobs to be processed or not, respectively, and the device(s) resume
-processing jobs.
-
-If the Pause-Printer operation is supported, then the Resume-Printer
-operation MUST be supported, and vice-versa.
-
-The IPP Printer removes the 'printer-stopped' value from any job's "job-
-state-reasons" attributes contained in that Printer.
-
-The IPP Printer MUST accept the request in any state, transition the
-Printer object to the indicated new state as follows:
-
- Current New "printer- IPP Printer's response status code and
- "printer- state" action:
- state"
-
- 'idle' 'idle' 'successful-ok'
- 'processing 'processing' 'successful-ok'
- '
- 'stopped' 'processing' 'successful-ok';
- when there are jobs to be processed
- 'stopped' 'idle' 'successful-ok';
- when there are no jobs to be processed.
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must be an operator or administrator of the Printer object
-(see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the
-operation and return: 'client-error-forbidden', 'client-error-not-
-authenticated', or 'client-error-not-authorized' as appropriate.
-
-The Resume-Printer Request and Resume-Printer Response have the same
-attribute groups and attributes as the Pause-Printer operation (see
-sections 3.2.7.1 and 3.2.7.2).
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 54]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-3.2.9 Purge-Jobs Operation
-
-This OPTIONAL operation allows a client to remove all jobs from an IPP
-Printer object, regardless of their job states, including jobs in the
-Printer object's Job History (see Section 4.3.7.2). After a Purge-Jobs
-operation has been performed, a Printer object MUST return no jobs in
-subsequent Get-Job-Attributes and Get-Jobs responses (until new jobs are
-submitted).
-
-Whether the Purge-Jobs (and Get-Jobs) operation affects jobs that were
-submitted to the device from other sources than the IPP Printer object
-in the same way that the Purge-Jobs operation affects jobs that were
-submitted to the IPP Printer object using IPP, depends on
-implementation, i.e., on whether the IPP protocol is being used as a
-universal management protocol or just to manage IPP jobs, respectively.
-
-Note: if an operator wants to cancel all jobs without clearing out the
-Job History, the operator uses the Cancel-Job operation on each job
-instead of using the Purge-Jobs operation.
-
-The Printer object MUST accept this operation in any state and
-transition the Printer object to the 'idle' state.
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must be an operator or administrator of the Printer object
-(see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the
-operation and return: client-error-forbidden, client-error-not-
-authenticated, and client-error-not-authorized as appropriate.
-
-The Purge-Jobs Request and Purge-Jobs Response have the same attribute
-groups and attributes as the Pause-Printer operation (see sections
-3.2.7.1 and 3.2.7.2).
-
-
-
-3.3 Job Operations
-
-
-All Job operations are directed at Job objects. A client MUST always
-supply some means of identifying the Job object in order to identify the
-correct target of the operation. That job identification MAY either be
-a single Job URI or a combination of a Printer URI with a Job ID. The
-IPP object implementation MUST support both forms of identification for
-every job.
-
-
-3.3.1 Send-Document Operation
-
-This OPTIONAL operation allows a client to create a multi-document Job
-object that is initially "empty" (contains no documents). In the
-Create-Job response, the Printer object returns the Job object's URI
-(the "job-uri" attribute) and the Job object's 32-bit identifier (the
-"job-id" attribute). For each new document that the client desires to
-add, the client uses a Send-Document operation. Each Send-Document
-Request contains the entire stream of document data for one document.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 55]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-If the Printer supports this operation but does not support multiple
-documents per job, the Printer MUST reject subsequent Send-Document
-operations supplied with data and return the 'server-error-multiple-
-document-jobs-not-supported'. However, the Printer MUST accept the
-first document with a 'true' or 'false' value for the "last-document"
-operation attribute (see below), so that clients MAY always submit one
-document jobs with a 'false' value for "last-document" in the first
-Send-Document and a 'true' for "last-document" in the second Send-
-Document (with no data).
-
-Since the Create-Job and the send operations (Send-Document or Send-URI
-operations) that follow could occur over an arbitrarily long period of
-time for a particular job, a client MUST send another send operation
-within an IPP Printer defined minimum time interval after the receipt of
-the previous request for the job. If a Printer object supports the
-Create-Job and Send-Document operations, the Printer object MUST support
-the "multiple-operation-time-out" attribute (see section 4.4.31). This
-attribute indicates the minimum number of seconds the Printer object
-will wait for the next send operation before taking some recovery
-action.
-
-An IPP object MUST recover from an errant client that does not supply a
-send operation, sometime after the minimum time interval specified by
-the Printer object's "multiple-operation-time-out" attribute. Such
-recovery MAY include any of the following or other recovery actions:
-
- 1. Assume that the Job is an invalid job, start the process of
- changing the job state to 'aborted', add the 'aborted-by-system'
- value to the job's "job-state-reasons" attribute (see section
- 4.3.8), and clean up all resources associated with the Job. In
- this case, if another send operation is finally received, the
- Printer responds with an "client-error-not-possible" or "client-
- error-not-found" depending on whether or not the Job object is
- still around when the send operation finally arrives.
- 2. Assume that the last send operation received was in fact the last
- document (as if the "last-document" flag had been set to 'true'),
- close the Job object, and proceed to process it (i.e., move the
- Job's state to 'pending').
- 3. Assume that the last send operation received was in fact the last
- document, close the Job, but move it to the 'pending-held' and add
- the 'submission-interrupted' value to the job's "job-state-reasons"
- attribute (see section 4.3.8). This action allows the user or an
- operator to determine whether to continue processing the Job by
- moving it back to the 'pending' state using the Release-Job
- operation (see section 3.3.6) or to cancel the job using the
- Cancel-Job operation (see section 3.3.3).
-
-
-Each implementation is free to decide the "best" action to take
-depending on local policy, whether any documents have been added,
-whether the implementation spools jobs or not, and/or any other piece
-of information available to it. If the choice is to abort the Job
-object, it is possible that the Job object may already have been
-processed to the point that some media sheet pages have been printed.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 56]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must either be the job owner (as determined in the Create-Job
-operation) or an operator or administrator of the Printer object (see
-Sections 1 and 8.5). Otherwise, the IPP object MUST reject the
-operation and return: 'client-error-forbidden', 'client-error-not-
-authenticated', or 'client-error-not-authorized' as appropriate.
-
-
-3.3.1.1 Send-Document Request
-
-The following attribute sets are part of the Send-Document Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.1.
-
- Target:
- Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))or
- (2) the "job-uri" (uri) operation attribute(s) which define the
- target for this operation as described in section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in section 8.3.
-
- "document-name" (name(MAX)):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It contains the client supplied
- document name. The document name MAY be different than the Job
- name. It might be helpful, but NEED NOT be unique across multiple
- documents in the same Job. Typically, the client software
- automatically supplies the document name on behalf of the end user
- by using a file name or an application generated name. See the
- description of the "document-name" operation attribute in the
- Print-Job Request (section 3.2.1.1) for more information about this
- attribute.
-
- "compression" (type3 keyword)
- See the description of "compression" for the Print-Job operation in
- Section 3.2.1.1.
-
- "document-format" (mimeMediaType) :
- See the description of "document-format" for the Print-Job
- operation in Section 3.2.1.1.
-
- "document-natural-language" (naturalLanguage):
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. This attribute specifies the
- natural language of the document for those document-formats that
- require a specification of the natural language in order to image
- the document unambiguously. There are no particular values
- required for the Printer object to support.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 57]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- "last-document" (boolean):
- The client MUST supply this attribute. The Printer object MUST
- support this attribute. It is a boolean flag that is set to 'true'
- if this is the last document for the Job, 'false' otherwise.
-
-
-Group 2: Document Content
-
- The client MUST supply the document data if the "last-document"
- flag is set to 'false'. However, since a client might not know
- that the previous document sent with a Send-Document (or Send-URI)
- operation was the last document (i.e., the "last-document"
- attribute was set to 'false'), it is legal to send a Send-Document
- request with no document data where the "last-document" flag is set
- to 'true'. Such a request MUST NOT increment the value of the Job
- object's "number-of-documents" attribute, since no real document
- was added to the job. It is not an error for a client to submit a
- job with no actual document data, i.e., only a single Create-Job
- and Send-Document request with a "last-document" operation
- attribute set to 'true' with no document data.
-
-3.3.1.2 Send-Document Response
-
-The following sets of attributes are part of the Send-Document Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See section 3.1.7 for details on returning Unsupported Attributes.
-
-Group 3: Job Object Attributes
-
- This is the same set of attributes as described in the Print-Job
- response (see section 3.2.1.2).
-
-
-3.3.2 Send-URI Operation
-
-This OPTIONAL operation is identical to the Send-Document operation (see
-section 3.3.1) except that a client MUST supply a URI reference
-("document-uri" operation attribute) rather than the document data
-itself. If a Printer object supports this operation, clients can use
-both Send-URI or Send-Document operations to add new documents to an
-existing multi-document Job object. However, if a client needs to
-indicate that the previous Send-URI or Send-Document was the last
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 58]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-document, the client MUST use the Send-Document operation with no
-document data and the "last-document" flag set to 'true' (rather than
-using a Send-URI operation with no "document-uri" operation attribute).
-
-If a Printer object supports this operation, it MUST also support the
-Print-URI operation (see section 3.2.2).
-
-The Printer object MUST validate the syntax and URI scheme of the
-supplied URI before returning a response, just as in the Print-URI
-operation. The IPP Printer MAY validate the accessibility of the
-document as part of the operation or subsequently (see section 3.2.2).
-
-
-3.3.3 Cancel-Job Operation
-
-This REQUIRED operation allows a client to cancel a Print Job from the
-time the job is created up to the time it is completed, canceled, or
-aborted. Since a Job might already be printing by the time a Cancel-Job
-is received, some media sheet pages might be printed before the job is
-actually terminated.
-
-The IPP object MUST accept or reject the request based on the job's
-current state and transition the job to the indicated new state as
-follows:
-
- Current "job- New "job- IPP object's response status
- state" state" code and action:
-
- 'pending' 'canceled' 'successful-ok'
- 'pending-held' 'canceled' 'successful-ok'
- 'processing' 'canceled' 'successful-ok'
- 'processing' 'processing' 'successful-ok' See Rule 1
- 'processing' 'processing' 'client-error-not-possible'
- See Rule 2
- 'processing- 'canceled' 'successful-ok'
- stopped'
- 'processing- 'processing- 'successful-ok' See Rule 1
- stopped' stopped'
- 'processing- 'processing- 'client-error-not-possible'
- stopped' stopped' See Rule 2
- 'completed' 'completed' 'client-error-not-possible'
- 'canceled' 'canceled' 'client-error-not-possible'
- 'aborted' 'aborted' 'client-error-not-possible'
-
-Rule 1: If the implementation requires some measurable time to cancel
-the job in the 'processing' or 'processing-stopped' job states, the IPP
-object MUST add the 'processing-to-stop-point' value to the job's "job-
-state-reasons" attribute and then transition the job to the 'canceled'
-state when the processing ceases (see section 4.3.8).
-
-Rule 2: If the Job object already has the 'processing-to-stop-point'
-value in its "job-state-reasons" attribute, then the Printer object MUST
-reject a Cancel-Job operation.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 59]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must either be the job owner or an operator or administrator
-of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP
-object MUST reject the operation and return: 'client-error-forbidden',
-'client-error-not-authenticated', or 'client-error-not-authorized' as
-appropriate.
-
-
-3.3.3.1 Cancel-Job Request
-
-The following groups of attributes are part of the Cancel-Job Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.1.
-
- Target:
- Either (1) the "printer-uri" (uri) plus "job-id"
- (integer(1:MAX))or (2) the "job-uri" (uri) operation attribute(s)
- which define the target for this operation as described in section
- 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in section 8.3.
-
- "message" (text(127)):
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. It is a message to the
- operator. This "message" attribute is not the same as the "job-
- message-from-operator" attribute. That attribute is used to report
- a message from the operator to the end user that queries that
- attribute. This "message" operation attribute is used to send a
- message from the client to the operator along with the operation
- request. It is an implementation decision of how or where to
- display this message to the operator (if at all).
-
-
-3.3.3.2 Cancel-Job Response
-
-The following sets of attributes are part of the Cancel-Job Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.2.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 60]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-Group 2: Unsupported Attributes
-
- See section 3.1.7 for details on returning Unsupported Attributes.
-
-
-
-Once a successful response has been sent, the implementation guarantees
-that the Job will eventually end up in the 'canceled' state. Between the
-time of the Cancel-Job operation is accepted and when the job enters the
-'canceled' job-state (see section 4.3.7), the "job-state-reasons"
-attribute SHOULD contain the 'processing-to-stop-point' value which
-indicates to later queries that although the Job might still be
-'processing', it will eventually end up in the 'canceled' state, not the
-'completed' state.
-
-
-3.3.4 Get-Job-Attributes Operation
-
-This REQUIRED operation allows a client to request the values of
-attributes of a Job object and it is almost identical to the Get-
-Printer-Attributes operation (see section 3.2.5). The only differences
-are that the operation is directed at a Job object rather than a Printer
-object, there is no "document-format" operation attribute used when
-querying a Job object, and the returned attribute group is a set of Job
-object attributes rather than a set of Printer object attributes.
-
-For Jobs, the possible names of attribute groups are:
-
- - 'job-template': the subset of the Job Template attributes that
- apply to a Job object (the first column of the table in Section
- 4.2) that the implementation supports for Job objects.
- - 'job-description': the subset of the Job Description attributes
- specified in Section 4.3 that the implementation supports for Job
- objects.
- - 'all': the special group 'all' that includes all attributes that
- the implementation supports for Job objects.
-
-
-Since a client MAY request specific attributes or named groups, there is
-a potential that there is some overlap. For example, if a client
-requests, 'job-name' and 'job-description', the client is actually
-requesting the "job-name" attribute once by naming it explicitly, and
-once by inclusion in the 'job-description' group. In such cases, the
-Printer object NEED NOT return the attribute only once in the response
-even if it is requested multiple times. The client SHOULD NOT request
-the same attribute in multiple ways.
-
-It is NOT REQUIRED that a Job object support all attributes belonging to
-a group (since some attributes are OPTIONAL). However it is REQUIRED
-that each Job object support all group names.
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 61]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-3.3.4.1 Get-Job-Attributes Request
-
-The following groups of attributes are part of the Get-Job-Attributes
-Request when the request is directed at a Job object:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.1.
-
- Target:
- Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))
- or (2) the "job-uri" (uri) operation attribute(s) which define the
- target for this operation as described in section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in section 8.3.
-
- "requested-attributes" (1setOf keyword) :
- The client OPTIONALLY supplies this attribute. The IPP object MUST
- support this attribute. It is a set of attribute names and/or
- attribute group names in whose values the requester is interested.
- If the client omits this attribute, the IPP object MUST respond as
- if this attribute had been supplied with a value of 'all'.
-
-
-3.3.4.2 Get-Job-Attributes Response
-
-The Printer object returns the following sets of attributes as part of
-the Get-Job-Attributes Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in section 3.1.4.2. The "attributes-
- natural-language" MAY be the natural language of the Job object,
- rather than the one requested.
-
-
-
-Group 2: Unsupported Attributes
-
- See section 3.1.7 for details on returning Unsupported Attributes.
-
- The response NEED NOT contain the "requested-attributes" operation
- attribute with any supplied values (attribute keywords) that were
- requested by the client but are not supported by the IPP object. If
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 62]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- the Printer object does include unsupported attributes referenced
- in "requested-attributes" and such attributes include group names,
- such as 'all', the unsupported attributes MUST NOT include
- attributes described in the standard but not supported by the
- implementation.
-
-
-Group 3: Job Object Attributes
-
- This is the set of requested attributes and their current values.
- The IPP object ignores (does not respond with) any requested
- attribute or value which is not supported or which is restricted by
- the security policy in force, including whether the requesting user
- is the user that submitted the job (job originating user) or not
- (see section 8). However, the IPP object MUST respond with the
- 'unknown' value for any supported attribute (including all REQUIRED
- attributes) for which the IPP object does not know the value,
- unless it would violate the security policy. See the description
- of the "out-of-band" values in the beginning of Section 4.1.
-
-3.3.5 Hold-Job Operation
-
-This OPTIONAL operation allows a client to hold a pending job in the
-queue so that it is not eligible for scheduling. If the Hold-Job
-operation is supported, then the Release-Job operation MUST be
-supported, and vice-versa. The OPTIONAL "job-hold-until" operation
-attribute allows a client to specify whether to hold the job
-indefinitely or until a specified time period, if supported.
-
-The IPP object MUST accept or reject the request based on the job's
-current state and transition the job to the indicated new state as
-follows:
-
- Current "job- New "job-state" IPP object's response status
- state" code and action:
-
- 'pending' 'pending-held' 'successful-ok' See Rule 1
- 'pending' 'pending' 'successful-ok' See Rule 2
- 'pending-held' 'pending-held' 'successful-ok' See Rule 1
- 'pending-held' 'pending' 'successful-ok' See Rule 2
- 'processing' 'processing' 'client-error-not-possible'
- 'processing- 'processing- 'client-error-not-possible'
- stopped' stopped'
- 'completed' 'completed' 'client-error-not-possible'
- 'canceled' 'canceled' 'client-error-not-possible'
- 'aborted' 'aborted' 'client-error-not-possible'
-
-Rule 1: If the implementation supports multiple reasons for a job to be
-in the 'pending-held' state, the IPP object MUST add the 'job-hold-
-until-specified' value to the job's "job-state-reasons" attribute.
-
-Rule 2: If the IPP object supports the "job-hold-until" operation
-attribute, but the specified time period has already started (or is the
-'no-hold' value) and there are no other reasons to hold the job, the IPP
-object MUST make the job be a candidate for processing immediately (see
-Section 4.2.2) by putting the job in the 'pending' state.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 63]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Note: In order to keep the Hold-Job operation simple, such a request is
-rejected when the job is in the 'processing' or 'processing-stopped'
-states. If an operation is needed to hold jobs while in these states,
-it will be added as an additional operation, rather than overloading the
-Hold-Job operation. Then it is clear to clients by querying the Printer
-object's "operations-supported" (see Section 4.4.15) and the Job
-object's "job-state" (see Section 4.3.7) attributes which operations are
-possible.
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must either be the job owner or an operator or administrator
-of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP
-object MUST reject the operation and return: 'client-error-forbidden',
-'client-error-not-authenticated', or 'client-error-not-authorized' as
-appropriate.
-
-
-3.3.5.1 Hold-Job Request
-
-The groups and operation attributes are the same as for a Cancel-Job
-request (see section 3.3.3.1), with the addition of the following Group
-1 Operation attribute:
-
- "job-hold-until" (type3 keyword | name(MAX)):
- The client OPTIONALLY supplies this Operation attribute. The IPP
- object MUST support this operation attribute in a Hold-Job request,
- if it supports the "job-hold-until" Job template attribute in
- create operations. See section 4.2.2. The IPP object SHOULD
- support the "job-hold-until" Job Template attribute for use in job
- create operations with at least the 'indefinite' value, if it
- supports the Hold-Job operation. Otherwise, a client cannot create
- a job and hold it immediately (without picking some supported time
- period in the future).
-
- If supplied and supported as specified in the Printer's "job-hold-
- until-supported" attribute, the IPP object copies the supplied
- operation attribute to the Job object, replacing the job's previous
- "job-hold-until" attribute, if present, and makes the job a
- candidate for scheduling during the supplied named time period.
-
- If supplied, but either the "job-hold-until" Operation attribute
- itself or the value supplied is not supported, the IPP object
- accepts the request, returns the unsupported attribute or value in
- the Unsupported Attributes Group according to section 3.1.7,
- returns the 'successful-ok-ignored-or-substituted-attributes, and
- holds the job indefinitely until a client performs a subsequent
- Release-Job operation.
-
- If the client (1) supplies a value that specifies a time period
- that has already started or the 'no-hold' value (meaning don't hold
- the job) and (2) the IPP object supports the "job-hold-until"
- operation attribute and there are no other reasons to hold the job,
- the IPP object MUST accept the operation and make the job be a
- candidate for processing immediately (see Section 4.2.2).
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 64]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- If the client does not supply a "job-hold-until" Operation
- attribute in the request, the IPP object MUST populate the job
- object with a "job-hold-until" attribute with the 'indefinite'
- value (if IPP object supports the "job-hold-until" attribute) and
- hold the job indefinitely, until a client performs a Release-Job
- operation.
-
-
-3.3.5.2 Hold-Job Response
-
-The groups and attributes are the same as for a Cancel-Job response (see
-section 3.3.3.2).
-
-
-3.3.6 Release-Job Operation
-
-This OPTIONAL operation allows a client to release a previously held job
-so that it is again eligible for scheduling. If the Hold-Job operation
-is supported, then the Release-Job operation MUST be supported, and
-vice-versa.
-
-This operation removes the "job-hold-until" job attribute, if present,
-from the job object that had been supplied in the create or most recent
-Hold-Job or Restart-Job operation and removes its effect on the job.
-The IPP object MUST remove the 'job-hold-until-specified' value from the
-job's "job-state-reasons" attribute, if present. See section 4.3.8.
-
-The IPP object MUST accept or reject the request based on the job's
-current state and transition the job to the indicated new state as
-follows:
-
- Current "job- New "job-state" IPP object's response status
- state" code and action:
-
- 'pending' 'pending' 'successful-ok'
- No effect on the job.
- 'pending-held' 'pending-held' 'successful-ok' See Rule 1
- 'pending-held' 'pending' 'successful-ok'
- 'processing' 'processing' 'successful-ok'
- No effect on the job.
- 'processing- 'processing- 'successful-ok'
- stopped' stopped' No effect on the job.
- 'completed' 'completed' 'client-error-not-possible'
- 'canceled' 'canceled' 'client-error-not-possible'
- 'aborted' 'aborted' 'client-error-not-possible'
-
-Rule 1: If there are other reasons to keep the job in the 'pending-
-held' state, such as 'resources-are-not-ready', the job remains in the
-'pending-held' state. Thus the 'pending-held' state is not just for
-jobs that have the 'job-hold-until' applied to them, but are for any
-reason to keep the job from being a candidate for scheduling and
-processing, such as 'resources-are-not-ready'. See the "job-hold-until"
-attribute (section 4.2.2).
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must either be the job owner or an operator or administrator
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 65]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP
-object MUST reject the operation and return: 'client-error-forbidden',
-'client-error-not-authenticated', or 'client-error-not-authorized' as
-appropriate.
-
-The Release-Job Request and Release-Job Response have the same attribute
-groups and attributes as the Cancel-Job operation (see section 3.3.3.1
-and 3.3.3.2).
-
-
-3.3.7 Restart-Job Operation
-
-This OPTIONAL operation allows a client to restart a job that is
-retained in the queue after processing has completed (see section
-4.3.7.2).
-
-The job is moved to the 'pending' or 'pending-held' job state and
-restarts at the beginning on the same IPP Printer object with the same
-attribute values. If any of the documents in the job were passed by
-reference (Print-URI or Send-URI), the Printer MUST re-fetch the data,
-since the semantics of Restart-Job are to repeat all Job processing.
-The Job Description attributes that accumulate job progress, such as
-"job-impressions-completed", "job-media-sheets-completed", and "job-k-
-octets-processed", MUST be reset to 0 so that they give an accurate
-record of the job from its restart point. The job object MUST continue
-to use the same "job-uri" and "job-id" attribute values.
-
-Note: If in the future an operation is needed that does not reset the
-job progress attributes, then a new operation will be defined which
-makes a copy of the job, assigns a new "job-uri" and "job-id" to the
-copy and resets the job progress attributes in the new copy only.
-
-The IPP object MUST accept or reject the request based on the job's
-current state, transition the job to the indicated new state as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 66]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
- Current "job- New "job-state" IPP object's response status
- state" code and action:
-
- 'pending' 'pending' 'client-error-not-possible'
- 'pending-held' 'pending-held' 'client-error-not-possible'
- 'processing' 'processing' 'client-error-not-possible'
- 'processing- 'processing- 'client-error-not-possible'
- stopped' stopped'
- 'completed' 'pending' or 'successful-ok' - job is started
- 'pending-held' over.
- 'completed' 'completed' 'client-error-not-possible' -
- see Rule 1
- 'canceled' 'pending' or 'successful-ok' - job is started
- 'pending-held' over.
- 'canceled' 'canceled' 'client-error-not-possible' -
- see Rule 1
- 'aborted' 'pending' or 'successful-ok' - job is started
- 'pending-held' over.
- 'aborted' 'aborted' 'client-error-not-possible' -
- see Rule 1
-
-
-Rule 1: If the Job Retention Period has expired for the job in this
-state, then the IPP object rejects the operation. See section 4.3.7.2.
-
-Note: In order to prevent a user from inadvertently restarting a job in
-the middle, the Restart-Job request is rejected when the job is in the
-'processing' or 'processing-stopped' states. If in the future an
-operation is needed to hold or restart jobs while in these states, it
-will be added as an additional operation, rather than overloading the
-Restart-Job operation, so that it is clear that the user intended that
-the current job not be completed.
-
-Access Rights: The authenticated user (see section 8.3) performing this
-operation must either be the job owner or an operator or administrator
-of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP
-object MUST reject the operation and return: 'client-error-forbidden',
-'client-error-not-authenticated', or 'client-error-not-authorized' as
-appropriate.
-
-
-3.3.7.1 Restart-Job Request
-
-The groups and attributes are the same as for a Cancel-Job request (see
-section 3.3.3.1), with the addition of the following Group 1 Operation
-attribute:
-
- "job-hold-until" (type3 keyword | name(MAX)):
- The client OPTIONALLY supplies this attribute. The IPP object MUST
- support this Operation attribute in a Restart-Job request, if it
- supports the "job-hold-until" Job Template attribute in create
- operations. See section 4.2.2. Otherwise, the IPP object NEED NOT
- support the "job-hold-until" Operation attribute in a Restart-Job
- request.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 67]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- If supplied and supported as specified in the Printer's "job-hold-
- until-supported" attribute, the IPP object copies the supplied
- Operation attribute to the Job object, replacing the job's previous
- "job-hold-until" attribute, if present, and makes the job a
- candidate for scheduling during the supplied named time period.
- See section 4.2.2.
-
- If supplied, but the value is not supported, the IPP object accepts
- the request, returns the unsupported attribute or value in the
- Unsupported Attributes Group according to section 3.1.7, returns
- the 'successful-ok-ignored-or-substituted-attributes' status code,
- and holds the job indefinitely until a client performs a subsequent
- Release-Job operation.
-
- If supplied, but the "job-hold-until" Operation attribute itself is
- not supported, the IPP object accepts the request, returns the
- unsupported attribute with the out-of-band 'unsupported' value in
- the Unsupported Attributes Group according to section 3.1.7,
- returns the 'successful-ok-ignored-or-substituted-attributes'
- status code, and restarts the job, i.e., ignores the "job-hold-
- until" attribute.
-
- If the client (1) supplies a value that specifies a time period
- that has already started or the 'no-hold' value (meaning don't hold
- the job) and (2) the IPP object supports the "job-hold-until"
- operation attribute and there are no other reasons to hold the job,
- the IPP object makes the job a candidate for processing immediately
- (see Section 4.2.2).
-
- If the client does not supply a "job-hold-until" operation
- attribute in the request, the IPP object removes the "job-hold-
- until" attribute, if present, from the job. If there are no other
- reasons to hold the job, the Restart-Job operation makes the job a
- candidate for processing immediately (see Section 4.2.2).
-
-
-3.3.7.2 Restart-Job Response
-
-The groups and attributes are the same as for a Cancel-Job response (see
-section 3.3.3.2).
-
-Note: In the future an OPTIONAL Modify-Job or Set-Job-Attributes
-operation may be specified that allows the client to modify other
-attributes before releasing the restarted job.
-
-
-
-4. Object Attributes
-
-
-This section describes the attributes with their corresponding attribute
-syntaxes and values that are part of the IPP model. The sections below
-show the objects and their associated attributes which are included
-within the scope of this protocol. Many of these attributes are derived
-from other relevant documents:
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 68]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- - Document Printing Application (DPA) [ISO10175]
- - RFC 1759 Printer MIB [RFC1759]
-
-Each attribute is uniquely identified in this document using a "keyword"
-(see section 12.2.1) which is the name of the attribute. The keyword is
-included in the section header describing that attribute.
-
-Note: Not only are keywords used to identify attributes, but one of the
-attribute syntaxes described below is "keyword" so that some attributes
-have keyword values. Therefore, these attributes are defined as having
-an attribute syntax that is a set of keywords.
-
-
-4.1 Attribute Syntaxes
-
-
-This section defines the basic attribute syntax types that all clients
-and IPP objects MUST be able to accept in responses and accept in
-requests, respectively. Each attribute description in sections 3 and 4
-includes the name of attribute syntax(es) in the heading (in
-parentheses). A conforming implementation of an attribute MUST include
-the semantics of the attribute syntax(es) so identified. Section 6.3
-describes how the protocol can be extended with new attribute syntaxes.
-
-The attribute syntaxes are specified in the following sub-sections,
-where the sub-section heading is the keyword name of the attribute
-syntax inside the single quotes. In operation requests and responses
-each attribute value MUST be represented as one of the attribute
-syntaxes specified in the sub-section heading for the attribute. In
-addition, the value of an attribute in a response (but not in a request)
-MAY be one of the "out-of-band" values whose special encoding rules are
-defined in the "Encoding and Transport" document [IPP-PRO]. Standard
-"out-of-band" values are:
-
- 'unknown': The attribute is supported by the IPP object, but the
- value is unknown to the IPP object for some reason.
- 'unsupported': The attribute is unsupported by the IPP object. This
- value MUST be returned only as the value of an attribute in the
- Unsupported Attributes Group.
- 'no-value': The attribute is supported by the Printer object, but the
- administrator has not yet configured a value.
-
-
-
-All attributes in a request MUST have one or more values as defined in
-Sections 4.2 to 4.4. Thus clients MUST NOT supply attributes with "out-
-of-band" values for operations defined in this document. All attributes
-in a response MUST have one or more values as defined in Sections 4.2 to
-4.4 or a single "out-of-band" value.
-
-Most attributes are defined to have a single attribute syntax. However,
-a few attributes (e.g., "job-sheet", "media", "job-hold-until") are
-defined to have several attribute syntaxes, depending on the value.
-These multiple attribute syntaxes are separated by the "|" character in
-the sub-section heading to indicate the choice. Since each value MUST
-be tagged as to its attribute syntax in the protocol, a single-valued
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 69]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-attribute instance may have any one of its attribute syntaxes and a
-multi-valued attribute instance may have a mixture of its defined
-attribute syntaxes.
-
-
-4.1.1 'text'
-
-A text attribute is an attribute whose value is a sequence of zero or
-more characters encoded in a maximum of 1023 ('MAX') octets. MAX is the
-maximum length for each value of any text attribute. However, if an
-attribute will always contain values whose maximum length is much less
-than MAX, the definition of that attribute will include a qualifier that
-defines the maximum length for values of that attribute. For example:
-the "printer-location" attribute is specified as "printer-location
-(text(127))". In this case, text values for "printer-location" MUST NOT
-exceed 127 octets; if supplied with a longer text string via some
-external interface (other than the protocol), implementations are free
-to truncate to this shorter length limitation.
-
-In this document, all text attributes are defined using the 'text'
-syntax. However, 'text' is used only for brevity; the formal
-interpretation of 'text' is: 'textWithoutLanguage | textWithLanguage'.
-That is, for any attribute defined in this document using the 'text'
-attribute syntax, all IPP objects and clients MUST support both the
-'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes.
-However, in actual usage and protocol execution, objects and clients
-accept and return only one of the two syntax per attribute. The syntax
-'text' never appears "on-the-wire".
-
-Both 'textWithoutLanguage' and 'textWithLanguage' are needed to support
-the real world needs of interoperability between sites and systems that
-use different natural languages as the basis for human communication.
-Generally, one natural language applies to all text attributes in a
-given request or response. The language is indicated by the "attributes-
-natural-language" operation attribute defined in section 3.1.4 or
-"attributes-natural-language" job attribute defined in section 4.3.20,
-and there is no need to identify the natural language for each text
-string on a value-by-value basis. In these cases, the attribute syntax
-'textWithoutLanguage' is used for text attributes. In other cases, the
-client needs to supply or the Printer object needs to return a text
-value in a natural language that is different from the rest of the text
-values in the request or response. In these cases, the client or
-Printer object uses the attribute syntax 'textWithLanguage' for text
-attributes (this is the Natural Language Override mechanism described in
-section 3.1.4).
-
-The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes are
-described in more detail in the following sections.
-
-
-4.1.1.1 'textWithoutLanguage'
-
-The 'textWithoutLanguage' syntax indicates a value that is sequence of
-zero or more characters encoded in a maximum of 1023 (MAX) octets.
-Text strings are encoded using the rules of some charset. The Printer
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 70]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-object MUST support the UTF-8 charset [RFC2279] and MAY support
-additional charsets to represent 'text' values, provided that the
-charsets are registered with IANA [IANA-CS]. See Section 4.1.7 for the
-definition of the 'charset' attribute syntax, including restricted
-semantics and examples of charsets.
-
-
-4.1.1.2 'textWithLanguage'
-
-The 'textWithLanguage' attribute syntax is a compound attribute syntax
-consisting of two parts: a 'textWithoutLanguage' part encoded in a
-maximum of 1023 (MAX) octets plus an additional 'naturalLanguage' (see
-section 4.1.8) part that overrides the natural language in force. The
-'naturalLanguage' part explicitly identifies the natural language that
-applies to the text part of that value and that value alone. For any
-give text attribute, the 'textWithoutLanguage' part is limited to the
-maximum length defined for that 'text' attribute, and the
-'naturalLanguage' part is always limited to 63 (additional) octets.
-Using the 'textWithLanguage' attribute syntax rather than the normal
-'textWithoutLanguage' syntax is the so-called Natural Language Override
-mechanism and MUST be supported by all IPP objects and clients.
-
-If the attribute is multi-valued (1setOf text), then the
-'textWithLanguage' attribute syntax MUST be used to explicitly specify
-each attribute value whose natural language needs to be overridden.
-Other values in a multi-valued 'text' attribute in a request or a
-response revert to the natural language of the operation attribute.
-
-In a create request, the Printer object MUST accept and store with the
-Job object any natural language in the "attributes-natural-language"
-operation attribute, whether the Printer object supports that natural
-language or not. Furthermore, the Printer object MUST accept and store
-any 'textWithLanguage' attribute value, whether the Printer object
-supports that natural language or not. These requirements are
-independent of the value of the "ipp-attribute-fidelity" operation
-attribute that the client MAY supply.
-
-Example: If the client supplies the "attributes-natural-language"
-operation attribute with the value: 'en' indicating English, but the
-value of the "job-name" attribute is in French, the client MUST use the
-'textWithLanguage' attribute syntax with the following two values:
-
- 'fr': Natural Language Override indicating French
- 'Rapport Mensuel': the job name in French
-
-
-See the "Encoding and Transport" document [IPP-PRO] section 3.11 for the
-encoding of the two parts and Appendix A for a detailed example of the
-'textWithLanguage' attribute syntax.
-
-
-4.1.2 'name'
-
-This syntax type is used for user-friendly strings, such as a Printer
-name, that, for humans, are more meaningful than identifiers. Names are
-never translated from one natural language to another. The 'name'
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 71]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-attribute syntax is essentially the same as 'text', including the
-REQUIRED support of UTF-8 except that the sequence of characters is
-limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
-
-Also like 'text', 'name' is really an abbreviated notation for either
-'nameWithoutLanguage' or 'nameWithLanguage'. That is, all IPP objects
-and clients MUST support both the 'nameWithoutLanguage' and
-'nameWithLanguage' attribute syntaxes. However, in actual usage and
-protocol execution, objects and clients accept and return only one of
-the two syntax per attribute. The syntax 'name' never appears "on-the-
-wire".
-
-Only the 'text' and 'name' attribute syntaxes permit the Natural
-Language Override mechanism.
-
-Some attributes are defined as 'type3 keyword | name'. These attributes
-support values that are either type3 keywords or names. This dual-
-syntax mechanism enables a site administrator to extend these attributes
-to legally include values that are locally defined by the site
-administrator. Such names are not registered with IANA.
-
-
-4.1.2.1 'nameWithoutLanguage'
-
-The nameWithoutLanguage' syntax indicates a value that is sequence of
-zero or more characters encoded in a maximum of 255 (MAX) octets.
-
-
-4.1.2.2 'nameWithLanguage'
-
-The 'nameWithLanguage' attribute syntax is a compound attribute syntax
-consisting of two parts: a 'nameWithoutLanguage' part encoded in a
-maximum of 1023 (MAX) octets plus an additional 'naturalLanguage' (see
-section 4.1.8) part that overrides the natural language in force. The
-'naturalLanguage' part explicitly identifies the natural language that
-applies to that name value and that name value alone. For any give text
-attribute, the 'textWithoutLanguage' part is limited to the maximum
-length defined for that 'text' attribute, and the 'naturalLanguage' part
-is always limited to 63 (additional) octets. Using the
-'textWithLanguage' attribute syntax rather than the normal
-'textWithoutLanguage' syntax is the so-called Natural Language Override
-mechanism and MUST be supported by all IPP objects and clients.
-
-The 'nameWithLanguage' attribute syntax behaves the same as the
-'textWithLanguage' syntax. Using the 'textWithLanguage' attribute
-syntax rather than the normal 'textWithoutLanguage' syntax is the so-
-called Natural Language Override mechanism and MUST be supported by all
-IPP objects and clients. If a name is in a language that is different
-than the rest of the object or operation, then this 'nameWithLanguage'
-syntax is used rather than the generic 'nameWithoutLanguage' syntax.
-
-If the attribute is multi-valued (1setOf text), then the
-'nameWithLanguage' attribute syntax MUST be used to explicitly specify
-each attribute value whose natural language needs to be overridden.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 72]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Other values in a multi-valued 'name' attribute in a request or a
-response revert to the natural language of the operation attribute.
-
-In a create request, the Printer object MUST accept and store with the
-Job object any natural language in the "attributes-natural-language"
-operation attribute, whether the Printer object supports that natural
-language or not. Furthermore, the Printer object MUST accept and store
-any 'nameWithLanguage' attribute value, whether the Printer object
-supports that natural language or not. These requirements are
-independent of the value of the "ipp-attribute-fidelity" operation
-attribute that the client MAY supply.
-
-Example: If the client supplies the "attributes-natural-language"
-operation attribute with the value: 'en' indicating English, but the
-"printer-name" attribute is in German, the client MUST use the
-'nameWithLanguage' attribute syntax as follows:
-
- 'de': Natural Language Override indicating German
- 'Farbdrucker': the Printer name in German
-
-
-See the "Encoding and Transport" document [IPP-PRO] section 3.11 for the
-encoding of the two parts and Appendix A for a detailed example of the
-'nameWithLanguage' attribute syntax.
-
-
-4.1.2.3 Matching 'name' attribute values
-
-For purposes of matching two 'name' attribute values for equality, such
-as in job validation (where a client-supplied value for attribute "xxx"
-is checked to see if the value is among the values of the Printer
-object's corresponding "xxx-supported" attribute), the following match
-rules apply:
-
- 1. 'keyword' values never match 'name' values.
-
- 2. 'name' (nameWithoutLanguage and nameWithLanguage) values match
- if (1) the name parts match and (2) the Associated Natural-Language
- parts (see section 3.1.4.1) match. The matching rules are:
-
- a. the name parts match if the two names are identical
- character by character, except it is RECOMMENDED that case be
- ignored. For example: 'Ajax-letter-head-white' MUST match
- 'Ajax-letter-head-white' and SHOULD match 'ajax-letter-head-
- white' and 'AJAX-LETTER-HEAD-WHITE'.
-
- b. the Associated Natural-Language parts match if the shorter
- of the two meets the syntactic requirements of RFC 1766
- [RFC1766] and matches byte for byte with the longer. For
- example, 'en' matches 'en', 'en-us' and 'en-gb', but matches
- neither 'fr' nor 'e'.
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 73]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.1.3 'keyword'
-
-The 'keyword' attribute syntax is a sequence of characters, length: 1 to
-255, containing only the US-ASCII [ASCII] encoded values for lowercase
-letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot ("."), and
-underscore ("_"). The first character MUST be a lowercase letter.
-Furthermore, keywords MUST be in U.S. English.
-
-This syntax type is used for enumerating semantic identifiers of
-entities in the abstract protocol, i.e., entities identified in this
-document. Keywords are used as attribute names or values of attributes.
-Unlike 'text' and 'name' attribute values, 'keyword' values MUST NOT use
-the Natural Language Override mechanism, since they MUST always be US-
-ASCII and U.S. English.
-
-Keywords are for use in the protocol. A user interface will likely
-provide a mapping between protocol keywords and displayable user-
-friendly words and phrases which are localized to the natural language
-of the user. While the keywords specified in this document MAY be
-displayed to users whose natural language is U.S. English, they MAY be
-mapped to other U.S. English words for U.S. English users, since the
-user interface is outside the scope of this document.
-
-In the definition for each attribute of this syntax type, the full set
-of defined keyword values for that attribute are listed.
-
-When a keyword is used to represent an attribute (its name), it MUST be
-unique within the full scope of all IPP objects and attributes. When a
-keyword is used to represent a value of an attribute, it MUST be unique
-just within the scope of that attribute. That is, the same keyword MUST
-NOT be used for two different values within the same attribute to mean
-two different semantic ideas. However, the same keyword MAY be used
-across two or more attributes, representing different semantic ideas for
-each attribute. Section 6.1 describes how the protocol can be extended
-with new keyword values. Examples of attribute name keywords:
-
- "job-name"
- "attributes-charset"
-
-
-Note: This document uses "type1", "type2", and "type3" prefixes to the
-"keyword" basic syntax to indicate different levels of review for
-extensions (see section 6.1).
-
-
-4.1.4 'enum'
-
-The 'enum' attribute syntax is an enumerated integer value that is in
-the range from 1 to 2**31 - 1 (MAX). Each value has an associated
-'keyword' name. In the definition for each attribute of this syntax
-type, the full set of possible values for that attribute are listed.
-This syntax type is used for attributes for which there are enum values
-assigned by other standards, such as SNMP MIBs. A number of attribute
-enum values in this document are also used for corresponding attributes
-in other standards [RFC1759]. This syntax type is not used for
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 74]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-attributes to which the administrator may assign values. Section 6.1
-describes how the protocol can be extended with new enum values.
-
-Enum values are for use in the protocol. A user interface will provide
-a mapping between protocol enum values and displayable user-friendly
-words and phrases which are localized to the natural language of the
-user. While the enum symbols specified in this document MAY be
-displayed to users whose natural language is U.S. English, they MAY be
-mapped to other U.S. English words for U.S. English users, since the
-user interface is outside the scope of this document.
-
-Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP "out-
-of-band" value 'unknown'. See the description of the "out-of-band"
-values at the beginning of Section 4.1. Therefore, attributes of type
-'enum' start at '3'.
-
-Note: This document uses "type1", "type2", and "type3" prefixes to the
-"enum" basic syntax to indicate different levels of review for
-extensions (see section 6.1).
-
-
-4.1.5 'uri'
-
-The 'uri' attribute syntax is any valid Uniform Resource Identifier or
-URI [RFC2396]. Most often, URIs are simply Uniform Resource Locators or
-URLs. The maximum length of URIs used as values of IPP attributes is
-1023 octets. Although most other IPP attribute syntax types allow for
-only lower-cased values, this attribute syntax type conforms to the
-case-sensitive and case-insensitive rules specified in [RFC2396]. See
-also [IPP-IIG] for a discussion of case in URIs.
-
-
-4.1.6 'uriScheme'
-
-The 'uriScheme' attribute syntax is a sequence of characters
-representing a URI scheme according to RFC 2396 [RFC2396]. Though RFC
-2396 requires that the values be case-insensitive, IPP requires all
-lower case values in IPP attributes to simplify comparing by IPP clients
-and Printer objects.
-
-Standard values for this syntax type are the following keywords:
-
- 'ipp': for IPP schemed URIs (e.g., "ipp:...")
- 'http': for HTTP schemed URIs (e.g., "http:...")
- 'https': for use with HTTPS schemed URIs (e.g., "https:...") (not on
- IETF standards track)
- 'ftp': for FTP schemed URIs (e.g., "ftp:...")
- 'mailto': for SMTP schemed URIs (e.g., "mailto:...")
- 'file': for file schemed URIs (e.g., "file:...")
-
-
-A Printer object MAY support any URI 'scheme' that has been registered
-with IANA [IANA-MT]. The maximum length of URI 'scheme' values used to
-represent IPP attribute values is 63 octets.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 75]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.1.7 'charset'
-
-The 'charset' attribute syntax is a standard identifier for a charset.
-A charset is a coded character set and encoding scheme. Charsets are
-used for labeling certain document contents and 'text' and 'name'
-attribute values. The syntax and semantics of this attribute syntax are
-specified in RFC 2046 [RFC2046] and contained in the IANA character-set
-Registry [IANA-CS] according to the IANA procedures [RFC2278]. Though
-RFC 2046 requires that the values be case-insensitive US-ASCII, IPP
-requires all lower case values in IPP attributes to simplify comparing
-by IPP clients and Printer objects. When a character-set in the IANA
-registry has more than one name (alias), the name labeled as "(preferred
-MIME name)", if present, MUST be used.
-
-The maximum length of 'charset' values used to represent IPP attribute
-values is 63 octets.
-
-Some examples are:
-
- 'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set
- (UCS) represented as the UTF-8 [RFC2279] transfer encoding scheme
- in which US-ASCII is a subset charset.
- 'us-ascii': 7-bit American Standard Code for Information Interchange
- (ASCII), ANSI X3.4-1986 [ASCII]. That standard defines US-ASCII,
- but RFC 2045 [RFC2045] eliminates most of the control characters
- from conformant usage in MIME and IPP.
- 'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet Nr
- 1 [ISO8859-1]. That standard defines a coded character set that is
- used by Latin languages in the Western Hemisphere and Western
- Europe. US-ASCII is a subset charset.
-
-
-Some attribute descriptions MAY place additional requirements on charset
-values that may be used, such as REQUIRED values that MUST be supported
-or additional restrictions, such as requiring that the charset have US-
-ASCII as a subset charset.
-
-
-4.1.8 'naturalLanguage'
-
-The 'naturalLanguage' attribute syntax is a standard identifier for a
-natural language and optionally a country. The values for this syntax
-type are defined by RFC 1766 [RFC1766]. Though RFC 1766 requires that
-the values be case-insensitive US-ASCII, IPP requires all lower case to
-simplify comparing by IPP clients and Printer objects. Examples
-include:
-
- 'en': for English
- 'en-us': for US English
- 'fr': for French
- 'de': for German
-
-
-The maximum length of 'naturalLanguage' values used to represent IPP
-attribute values is 63 octets.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 76]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.1.9 'mimeMediaType'
-
-The 'mimeMediaType' attribute syntax is the Internet Media Type
-(sometimes called MIME type) as defined by RFC 2046 [RFC2046] and
-registered according to the procedures of RFC 2048 [RFC2048] for
-identifying a document format. The value MAY include a charset, or
-other, parameter, depending on the specification of the Media Type in
-the IANA Registry [IANA-MT]. Although most other IPP syntax types allow
-for only lower-cased values, this syntax type allows for mixed-case
-values which are case-insensitive.
-
-Examples are:
-
- 'text/html': An HTML document
- 'text/plain': A plain text document in US-ASCII (RFC 2046 indicates
- that in the absence of the charset parameter MUST mean US-ASCII
- rather than simply unspecified) [RFC2046].
- 'text/plain; charset=US-ASCII': A plain text document in US-ASCII
- [52, 56].
- 'text/plain; charset=ISO-8859-1': A plain text document in ISO 8859-
- 1 (Latin 1) [ISO8859-1].
- 'text/plain; charset=utf-8': A plain text document in ISO 10646
- represented as UTF-8 [RFC2279]
- 'application/postscript': A PostScript document [RFC2046]
- 'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape
- sequence embedded in the document data)
- 'application/pdf': Portable Document Format - see IANA MIME Media
- Type registry
- 'application/octet-stream': Auto-sense - see section 4.1.9.1
-
-The maximum length of a 'mimeMediaType' value to represent IPP attribute
-values is 255 octets.
-
-
-4.1.9.1 Application/octet-stream -- Auto-Sensing the document format
-
-One special type is 'application/octet-stream'. If the Printer object
-supports this value, the Printer object MUST be capable of auto-sensing
-the format of the document data using an implementation-dependent method
-that examines some number of octets of the document data, either as part
-of the create operation and/or at document processing time. During
-auto-sensing, a Printer may determine that the document-data has a
-format that the Printer doesn't recognize. If the Printer determines
-this problem before returning an operation response, it rejects the
-request and returns the 'client-error-document-format-not-supported'
-status code. If the Printer determines this problem after accepting the
-request and returning an operation response with one of the successful
-status codes, the Printer adds the 'unsupported-document-format' value
-to the job's "job-state-reasons" attribute.
-
-If the Printer object's default value attribute "document-format-
-default" is set to 'application/octet-stream', the Printer object not
-only supports auto-sensing of the document format, but will depend on
-the result of applying its auto-sensing when the client does not supply
-the "document-format" attribute. If the client supplies a document
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 77]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-format value, the Printer MUST rely on the supplied attribute, rather
-than trust its auto-sensing algorithm. To summarize:
-
- 1. If the client does not supply a document format value, the Printer
- MUST rely on its default value setting (which may be
- 'application/octet-stream' indicating an auto-sensing mechanism).
- 2. If the client supplies a value other than 'application/octet-
- stream', the client is supplying valid information about the format
- of the document data and the Printer object MUST trust the client
- supplied value more than the outcome of applying an automatic
- format detection mechanism. For example, the client may be
- requesting the printing of a PostScript file as a 'text/plain'
- document. The Printer object MUST print a text representation of
- the PostScript commands rather than interpret the stream of
- PostScript commands and print the result.
- 3. If the client supplies a value of 'application/octet-stream', the
- client is indicating that the Printer object MUST use its auto-
- sensing mechanism on the client supplied document data whether
- auto-sensing is the Printer object's default or not.
-
-
-Note: Since the auto-sensing algorithm is probabilistic, if the client
-requests both auto-sensing ("document-format" set to 'application/octet-
-stream') and true fidelity ("ipp-attribute-fidelity" set to 'true'), the
-Printer object might not be able to guarantee exactly what the end user
-intended (the auto-sensing algorithm might mistake one document format
-for another), but it is able to guarantee that its auto-sensing
-mechanism be used.
-
-When a Printer performs auto-sensing of a document in a submitted job,
-it is RECOMMENDED that the Printer indicate to the user that such auto-
-sensing has occurred and which document-format was auto-sensed by
-printing that information on the job's job-start-sheet.
-
-
-4.1.10 'octetString'
-
-The 'octetString' attribute syntax is a sequence of octets encoded in a
-maximum of 1023 octets which is indicated in sub-section headers using
-the notation: octetString(MAX). This syntax type is used for opaque
-data.
-
-
-4.1.11 'boolean'
-
-The 'boolean' attribute syntax has only two values: 'true' and 'false'.
-
-
-4.1.12 'integer'
-
-The 'integer' attribute syntax is an integer value that is in the range
-from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual attribute may
-specify the range constraint explicitly in sub-section headers if the
-range is different from the full range of possible integer values. For
-example: job-priority (integer(1:100)) for the "job-priority"
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 78]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-attribute. However, the enforcement of that additional constraint is up
-to the IPP objects, not the protocol.
-
-
-4.1.13 'rangeOfInteger'
-
-The 'rangeOfInteger' attribute syntax is an ordered pair of integers
-that defines an inclusive range of integer values. The first integer
-specifies the lower bound and the second specifies the upper bound. If
-a range constraint is specified in the header description for an
-attribute in this document whose attribute syntax is 'rangeOfInteger'
-(i.e., 'X:Y' indicating X as a minimum value and Y as a maximum value),
-then the constraint applies to both integers.
-
-
-4.1.14 'dateTime'
-
-The 'dateTime' attribute syntax is a standard, fixed length, 11 octet
-representation of the "DateAndTime" syntax as defined in RFC 2579
-[RFC2579]. RFC 2579 also identifies an 8 octet representation of a
-"DateAndTime" value, but IPP objects MUST use the 11 octet
-representation. A user interface will provide a mapping between
-protocol dateTime values and displayable user-friendly words or
-presentation values and phrases which are localized to the natural
-language and date format of the user, including time zone.
-
-
-4.1.15 'resolution'
-
-The 'resolution' attribute syntax specifies a two-dimensional resolution
-in the indicated units. It consists of 3 values: a cross feed direction
-resolution (positive integer value), a feed direction resolution
-(positive integer value), and a units value. The semantics of these
-three components are taken from the Printer MIB [RFC1759] suggested
-values. That is, the cross feed direction component resolution
-component is the same as the prtMarkerAddressabilityXFeedDir object in
-the Printer MIB, the feed direction component resolution component is
-the same as the prtMarkerAddressabilityFeedDir in the Printer MIB, and
-the units component is the same as the prtMarkerAddressabilityUnit
-object in the Printer MIB (namely, '3' indicates dots per inch and '4'
-indicates dots per centimeter). All three values MUST be present even
-if the first two values are the same. Example: '300', '600', '3'
-indicates a 300 dpi cross-feed direction resolution, a 600 dpi feed
-direction resolution, since a '3' indicates dots per inch (dpi).
-
-
-4.1.16 '1setOf X'
-
-The '1setOf X' attribute syntax is 1 or more values of attribute syntax
-type X. This syntax type is used for multi-valued attributes. The
-syntax type is called '1setOf' rather than just 'setOf' as a reminder
-that the set of values MUST NOT be empty (i.e., a set of size 0). Sets
-are normally unordered. However each attribute description of this type
-may specify that the values MUST be in a certain order for that
-attribute.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 79]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.2 Job Template Attributes
-
-
-Job Template attributes describe job processing behavior. Support for
-Job Template attributes by a Printer object is OPTIONAL (see section
-12.2.3 for a description of support for OPTIONAL attributes). Also,
-clients OPTIONALLY supply Job Template attributes in create requests.
-
-Job Template attributes conform to the following rules. For each Job
-Template attribute called "xxx":
-
- 1. If the Printer object supports "xxx" then it MUST support both a
- "xxx-default" attribute (unless there is a "No" in the table below)
- and a "xxx-supported" attribute. If the Printer object doesn't
- support "xxx", then it MUST support neither an "xxx-default"
- attribute nor an "xxx-supported" attribute, and it MUST treat an
- attribute "xxx" supplied by a client as unsupported. An attribute
- "xxx" may be supported for some document formats and not supported
- for other document formats. For example, it is expected that a
- Printer object would only support "orientation-requested" for some
- document formats (such as 'text/plain' or 'text/html') but not
- others (such as 'application/postscript').
-
- 2. "xxx" is OPTIONALLY supplied by the client in a create request.
- If "xxx" is supplied, the client is indicating a desired job
- processing behavior for this Job. When "xxx" is not supplied, the
- client is indicating that the Printer object apply its default job
- processing behavior at job processing time if the document content
- does not contain an embedded instruction indicating an xxx-related
- behavior.
-
- Since an administrator MAY change the default value attribute after
- a Job object has been submitted but before it has been processed,
- the default value used by the Printer object at job processing time
- may be different that the default value in effect at job submission
- time.
-
- 3. The "xxx-supported" attribute is a Printer object attribute that
- describes which job processing behaviors are supported by that
- Printer object. A client can query the Printer object to find out
- what xxx-related behaviors are supported by inspecting the returned
- values of the "xxx-supported" attribute.
-
- Note: The "xxx" in each "xxx-supported" attribute name is singular,
- even though an "xxx-supported" attribute usually has more than one
- value, such as "job-sheet-supported", unless the "xxx" Job Template
- attribute is plural, such as "finishings" or "sides". In such
- cases the "xxx-supported" attribute names are: "finishings-
- supported" and "sides-supported".
-
- 4. The "xxx-default" default value attribute describes what will be
- done at job processing time when no other job processing
- information is supplied by the client (either explicitly as an IPP
- attribute in the create request or implicitly as an embedded
- instruction within the document data).
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 80]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-If an application wishes to present an end user with a list of supported
-values from which to choose, the application SHOULD query the Printer
-object for its supported value attributes. The application SHOULD also
-query the default value attributes. If the application then limits
-selectable values to only those value that are supported, the
-application can guarantee that the values supplied by the client in the
-create request all fall within the set of supported values at the
-Printer. When querying the Printer, the client MAY enumerate each
-attribute by name in the Get-Printer-Attributes Request, or the client
-MAY just name the "job-template" group in order to get the complete set
-of supported attributes (both supported and default attributes).
-
-The "finishings" attribute is an example of a Job Template attribute.
-It can take on a set of values such as 'staple', 'punch', and/or
-'cover'. A client can query the Printer object for the "finishings-
-supported" attribute and the "finishings-default" attribute. The
-supported attribute contains a set of supported values. The default
-value attribute contains the finishing value(s) that will be used for a
-new Job if the client does not supply a "finishings" attribute in the
-create request and the document data does not contain any corresponding
-finishing instructions. If the client does supply the "finishings"
-attribute in the create request, the IPP object validates the value or
-values to make sure that they are a subset of the supported values
-identified in the Printer object's "finishings-supported" attribute.
-See section 3.1.7.
-
-The table below summarizes the names and relationships for all Job
-Template attributes. The first column of the table (labeled "Job
-Attribute") shows the name and syntax for each Job Template attribute in
-the Job object. These are the attributes that can optionally be supplied
-by the client in a create request. The last two columns (labeled
-"Printer: Default Value Attribute" and "Printer: Supported Values
-Attribute") show the name and syntax for each Job Template attribute in
-the Printer object (the default value attribute and the supported values
-attribute). A "No" in the table means the Printer MUST NOT support the
-attribute (that is, the attribute is simply not applicable). For
-brevity in the table, the 'text' and 'name' entries do not show the
-maximum length for each attribute.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 81]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- +===================+======================+======================+
- | Job Attribute |Printer: Default Value| Printer: Supported |
- | | Attribute | Values Attribute |
- +===================+======================+======================+
- | job-priority | job-priority-default |job-priority-supported|
- | (integer 1:100) | (integer 1:100) |(integer 1:100) |
- +-------------------+----------------------+----------------------+
- | job-hold-until | job-hold-until- |job-hold-until- |
- | (type3 keyword | | default | supported |
- | name) | (type3 keyword | |(1setOf ( |
- | | name) |type3 keyword | name))|
- +-------------------+----------------------+----------------------+
- | job-sheets | job-sheets-default |job-sheets-supported |
- | (type3 keyword | | (type3 keyword | |(1setOf ( |
- | name) | name) |type3 keyword | name))|
- +-------------------+----------------------+----------------------+
- |multiple-document- |multiple-document- |multiple-document- |
- | handling | handling-default |handling-supported |
- | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|
- +-------------------+----------------------+----------------------+
- | copies | copies-default | copies-supported |
- | (integer (1:MAX)) | (integer (1:MAX)) | (rangeOfInteger |
- | | | (1:MAX)) |
- +-------------------+----------------------+----------------------+
- | finishings | finishings-default | finishings-supported |
- |(1setOf type2 enum)|(1setOf type2 enum) |(1setOf type2 enum) |
- +-------------------+----------------------+----------------------+
- | page-ranges | No | page-ranges- |
- | (1setOf | | supported (boolean) |
- | rangeOfInteger | | |
- | (1:MAX)) | | |
- +-------------------+----------------------+----------------------+
- | sides | sides-default | sides-supported |
- | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|
- +-------------------+----------------------+----------------------+
- | number-up | number-up-default | number-up-supported |
- | (integer (1:MAX)) | (integer (1:MAX)) |(1setOf (integer |
- | | | (1:MAX) | |
- | | | rangeOfInteger |
- | | | (1:MAX))) |
- +-------------------+----------------------+----------------------+
- | orientation- |orientation-requested-|orientation-requested-|
- | requested | default | supported |
- | (type2 enum) | (type2 enum) | (1setOf type2 enum) |
- +-------------------+----------------------+----------------------+
- | media | media-default | media-supported |
- | (type3 keyword | | (type3 keyword | |(1setOf ( |
- | name) | name) |type3 keyword | name))|
- | | | |
- | | | media-ready |
- | | |(1setOf ( |
- | | |type3 keyword | name))|
- +-------------------+----------------------+----------------------+
- | printer-resolution| printer-resolution- | printer-resolution- |
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 82]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- | (resolution) | default | supported |
- | | (resolution) |(1setOf resolution) |
- +-------------------+----------------------+----------------------+
- | print-quality | print-quality-default| print-quality- |
- | (type2 enum) | (type2 enum) | supported |
- | | |(1setOf type2 enum) |
- +-------------------+----------------------+----------------------+
-
-
-
-4.2.1 job-priority (integer(1:100))
-
-This attribute specifies a priority for scheduling the Job. A higher
-value specifies a higher priority. The value 1 indicates the lowest
-possible priority. The value 100 indicates the highest possible
-priority. Among those jobs that are ready to print, a Printer MUST
-print all jobs with a priority value of n before printing those with a
-priority value of n-1 for all n.
-
-If the Printer object supports this attribute, it MUST always support
-the full range from 1 to 100. No administrative restrictions are
-permitted. This way an end-user can always make full use of the entire
-range with any Printer object. If privileged jobs are implemented
-outside IPP/1.1, they MUST have priorities higher than 100, rather than
-restricting the range available to end-users.
-
-If the client does not supply this attribute and this attribute is
-supported by the Printer object, the Printer object MUST use the value
-of the Printer object's "job-priority-default" at job submission time
-(unlike most Job Template attributes that are used if necessary at job
-processing time).
-
-The syntax for the "job-priority-supported" is also integer(1:100).
-This single integer value indicates the number of priority levels
-supported. The Printer object MUST take the value supplied by the
-client and map it to the closest integer in a sequence of n integers
-values that are evenly distributed over the range from 1 to 100 using
-the formula:
-
- roundToNearestInt((100x+50)/n)
-
-where n is the value of "job-priority-supported" and x ranges from 0
-through n-1.
-
-For example, if n=1 the sequence of values is 50; if n=2, the sequence
-of values is: 25 and 75; if n = 3, the sequence of values is: 17, 50
-and 83; if n = 10, the sequence of values is: 5, 15, 25, 35, 45, 55,
-65, 75, 85, and 95; if n = 100, the sequence of values is: 1, 2, 3,
-... 100.
-
-If the value of the Printer object's "job-priority-supported" is 10 and
-the client supplies values in the range 1 to 10, the Printer object maps
-them to 5, in the range 11 to 20, the Printer object maps them to 15,
-etc.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 83]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.2.2 job-hold-until (type3 keyword | name (MAX))
-
-This attribute specifies the named time period during which the Job MUST
-become a candidate for printing.
-
-Standard keyword values for named time periods are:
-
- 'no-hold': immediately, if there are not other reasons to hold the
- job
- 'indefinite': - the job is held indefinitely, until a client
- performs a Release-Job (section 3.3.6)
- 'day-time': during the day
- 'evening': evening
- 'night': night
- 'weekend': weekend
- 'second-shift': second-shift (after close of business)
- 'third-shift': third-shift (after midnight)
-
-
-An administrator MUST associate allowable print times with a named time
-period (by means outside the scope of this IPP/1.1 document). An
-administrator is encouraged to pick names that suggest the type of time
-period. An administrator MAY define additional values using the 'name'
-or 'keyword' attribute syntax, depending on implementation.
-
-If the value of this attribute specifies a time period that is in the
-future, the Printer SHOULD add the 'job-hold-until-specified' value to
-the job's "job-state-reasons" attribute, MUST move the job to the
-'pending-held' state, and MUST NOT schedule the job for printing until
-the specified time-period arrives.
-
-When the specified time period arrives, the Printer MUST remove the
-'job-hold-until-specified' value from the job's "job-state-reason"
-attribute, if present. If there are no other job state reasons that
-keep the job in the 'pending-held' state, the Printer MUST consider the
-job as a candidate for processing by moving the job to the 'pending'
-state.
-
-If this job attribute value is the named value 'no-hold', or the
-specified time period has already started, the job MUST be a candidate
-for processing immediately.
-
-If the client does not supply this attribute and this attribute is
-supported by the Printer object, the Printer object MUST use the value
-of the Printer object's "job-hold-until-default" at job submission time
-(unlike most Job Template attributes that are used if necessary at job
-processing time).
-
-
-4.2.3 job-sheets (type3 keyword | name(MAX))
-
-This attribute determines which job start/end sheet(s), if any, MUST be
-printed with a job.
-
-Standard keyword values are:
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 84]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'none': no job sheet is printed
- 'standard': one or more site specific standard job sheets are
- printed, e.g. a single start sheet or both start and end sheet is
- printed
-
-
-An administrator MAY define additional values using the 'name' or
-'keyword' attribute syntax, depending on implementation.
-
-The effect of this attribute on jobs with multiple documents MAY be
-affected by the "multiple-document-handling" job attribute (section
-4.2.4), depending on the job sheet semantics.
-
-
-4.2.4 multiple-document-handling (type2 keyword)
-
-This attribute is relevant only if a job consists of two or more
-documents. This attribute MUST be supported if the Printer supports
-multiple documents per job (see sections 3.2.4 and 3.3.1). The
-attribute controls finishing operations and the placement of one or more
-print-stream pages into impressions and onto media sheets. When the
-value of the "copies" attribute exceeds 1, it also controls the order in
-which the copies that result from processing the documents are produced.
-For the purposes of this explanations, if "a" represents an instance of
-document data, then the result of processing the data in document "a" is
-a sequence of media sheets represented by "a(*)".
-
-Standard keyword values are:
-
- 'single-document': If a Job object has multiple documents, say, the
- document data is called a and b, then the result of processing all
- the document data (a and then b) MUST be treated as a single
- sequence of media sheets for finishing operations; that is,
- finishing would be performed on the concatenation of the sequences
- a(*),b(*). The Printer object MUST NOT force the data in each
- document instance to be formatted onto a new print-stream page, nor
- to start a new impression on a new media sheet. If more than one
- copy is made, the ordering of the sets of media sheets resulting
- from processing the document data MUST be a(*), b(*), a(*), b(*),
- ..., and the Printer object MUST force each copy (a(*),b(*)) to
- start on a new media sheet.
- 'separate-documents-uncollated-copies': If a Job object has multiple
- documents, say, the document data is called a and b, then the
- result of processing the data in each document instance MUST be
- treated as a single sequence of media sheets for finishing
- operations; that is, the sets a(*) and b(*) would each be finished
- separately. The Printer object MUST force each copy of the result
- of processing the data in a single document to start on a new media
- sheet. If more than one copy is made, the ordering of the sets of
- media sheets resulting from processing the document data MUST be
- a(*), a(*), ..., b(*), b(*) ... .
- 'separate-documents-collated-copies': If a Job object has multiple
- documents, say, the document data is called a and b, then the
- result of processing the data in each document instance MUST be
- treated as a single sequence of media sheets for finishing
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 85]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- operations; that is, the sets a(*) and b(*) would each be finished
- separately. The Printer object MUST force each copy of the result
- of processing the data in a single document to start on a new media
- sheet. If more than one copy is made, the ordering of the sets of
- media sheets resulting from processing the document data MUST be
- a(*), b(*), a(*), b(*), ... .
- 'single-document-new-sheet': Same as 'single-document', except that
- the Printer object MUST ensure that the first impression of each
- document instance in the job is placed on a new media sheet. This
- value allows multiple documents to be stapled together with a
- single staple where each document starts on a new sheet.
-
-
-The 'single-document' value is the same as 'separate-documents-collated-
-copies' with respect to ordering of print-stream pages, but not media
-sheet generation, since 'single-document' will put the first page of the
-next document on the back side of a sheet if an odd number of pages have
-been produced so far for the job, while 'separate-documents-collated-
-copies' always forces the next document or document copy on to a new
-sheet. In addition, if the "finishings" attribute specifies 'staple',
-then with 'single-document', documents a and b are stapled together as a
-single document with no regard to new sheets, with 'single-document-new-
-sheet', documents a and b are stapled together as a single document, but
-document b starts on a new sheet, but with 'separate-documents-
-uncollated-copies' and 'separate-documents-collated-copies', documents a
-and b are stapled separately.
-
-Note: None of these values provide means to produce uncollated sheets
-within a document, i.e., where multiple copies of sheet n are produced
-before sheet n+1 of the same document.
-
-The relationship of this attribute and the other attributes that control
-document processing is described in section 15.3.
-
-
-4.2.5 copies (integer(1:MAX))
-
-This attribute specifies the number of copies to be printed.
-
-On many devices the supported number of collated copies will be limited
-by the number of physical output bins on the device, and may be
-different from the number of uncollated copies which can be supported.
-
-Note: The effect of this attribute on jobs with multiple documents is
-controlled by the "multiple-document-handling" job attribute (section
-4.2.4) and the relationship of this attribute and the other attributes
-that control document processing is described in section 15.3.
-
-
-4.2.6 finishings (1setOf type2 enum)
-
-This attribute identifies the finishing operations that the Printer uses
-for each copy of each printed document in the Job. For Jobs with
-multiple documents, the "multiple-document-handling" attribute
-determines what constitutes a "copy" for purposes of finishing.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 86]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Standard enum values are:
-
- Value Symbolic Name and Description
-
- '3' 'none': Perform no finishing
- '4' 'staple': Bind the document(s) with one or more staples. The
- exact number and placement of the staples is site-
- defined.
- '5' 'punch': This value indicates that holes are required in the
- finished document. The exact number and placement of the
- holes is site-defined The punch specification MAY be
- satisfied (in a site- and implementation-specific manner)
- either by drilling/punching, or by substituting pre-
- drilled media.
- '6' 'cover': This value is specified when it is desired to select
- a non-printed (or pre-printed) cover for the document.
- This does not supplant the specification of a printed
- cover (on cover stock medium) by the document itself.
- '7' 'bind': This value indicates that a binding is to be applied
- to the document; the type and placement of the binding is
- site-defined.
-
- '8' 'saddle-stitch': Bind the document(s) with one or more
- staples (wire stitches) along the middle fold. The exact
- number and placement of the staples and the middle fold
- is implementation and/or site-defined.
- '9' 'edge-stitch': Bind the document(s) with one or more staples
- (wire stitches) along one edge. The exact number and
- placement of the staples is implementation and/or site-
- defined.
- '10'-'19' reserved for future generic finishing enum values.
-
-The following values are more specific; they indicate a corner or an
-edge as if the document were a portrait document (see below):
-
- '20' 'staple-top-left': Bind the document(s) with one or more
- staples in the top left corner.
- '21' 'staple-bottom-left': Bind the document(s) with one or more
- staples in the bottom left corner.
- '22' 'staple-top-right': Bind the document(s) with one or more
- staples in the top right corner.
- '23' 'staple-bottom-right': Bind the document(s) with one or more
- staples in the bottom right corner.
- '24' 'edge-stitch-left': Bind the document(s) with one or more
- staples (wire stitches) along the left edge. The exact
- number and placement of the staples is implementation
- and/or site-defined.
- '25' 'edge-stitch-top': Bind the document(s) with one or more
- staples (wire stitches) along the top edge. The exact
- number and placement of the staples is implementation
- and/or site-defined.
- '26' 'edge-stitch-right': Bind the document(s) with one or more
- staples (wire stitches) along the right edge. The exact
- number and placement of the staples is implementation
- and/or site-defined.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 87]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- '27' 'edge-stitch-bottom': Bind the document(s) with one or more
- staples (wire stitches) along the bottom edge. The exact
- number and placement of the staples is implementation
- and/or site-defined.
- '28' 'staple-dual-left': Bind the document(s) with two staples
- (wire stitches) along the left edge assuming a portrait
- document (see above).
- '29' 'staple-dual-top': Bind the document(s) with two staples
- (wire stitches) along the top edge assuming a portrait
- document (see above).
- '30' 'staple-dual-right': Bind the document(s) with two staples
- (wire stitches) along the right edge assuming a portrait
- document (see above).
- '31' 'staple-dual-bottom': Bind the document(s) with two staples
- (wire stitches) along the bottom edge assuming a portrait
- document (see above).
-
-The 'staple-xxx' values are specified with respect to the document as if
-the document were a portrait document. If the document is actually a
-landscape or a reverse-landscape document, the client supplies the
-appropriate transformed value. For example, to position a staple in the
-upper left hand corner of a landscape document when held for reading,
-the client supplies the 'staple-bottom-left' value (since landscape is
-defined as a +90 degree rotation of the image with respect to the media
-from portrait, i.e., anti-clockwise). On the other hand, to position a
-staple in the upper left hand corner of a reverse-landscape document
-when held for reading, the client supplies the 'staple-top-right' value
-(since reverse-landscape is defined as a -90 degree rotation of the
-image with respect to the media from portrait, i.e., clockwise).
-
-The angle (vertical, horizontal, angled) of each staple with respect to
-the document depends on the implementation which may in turn depend on
-the value of the attribute.
-
-Note: The effect of this attribute on jobs with multiple documents is
-controlled by the "multiple-document-handling" job attribute (section
-4.2.4) and the relationship of this attribute and the other attributes
-that control document processing is described in section 15.3.
-
-If the client supplies a value of 'none' along with any other
-combination of values, it is the same as if only that other combination
-of values had been supplied (that is the 'none' value has no effect).
-
-
-4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX))
-
-This attribute identifies the range(s) of print-stream pages that the
-Printer object uses for each copy of each document which are to be
-printed. Nothing is printed for any pages identified that do not exist
-in the document(s). Ranges MUST be in ascending order, for example: 1-
-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling Printer
-object can process the job in a single pass. If the ranges are not
-ascending or are overlapping, the IPP object MUST reject the request and
-return the 'client-error-bad-request' status code. The attribute is
-associated with print-stream pages not application-numbered pages (for
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 88]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-example, the page numbers found in the headers and or footers for
-certain word processing applications).
-
-For Jobs with multiple documents, the "multiple-document-handling"
-attribute determines what constitutes a "copy" for purposes of the
-specified page range(s). When "multiple-document-handling" is 'single-
-document', the Printer object MUST apply each supplied page range once
-to the concatenation of the print-stream pages. For example, if there
-are 8 documents of 10 pages each, the page-range '41:60' prints the
-pages in the 5th and 6th documents as a single document and none of the
-pages of the other documents are printed. When "multiple-document-
-handling" is 'separate-documents-uncollated-copies' or 'separate-
-documents-collated-copies', the Printer object MUST apply each supplied
-page range repeatedly to each document copy. For the same job, the
-page-range '1:3, 10:10' would print the first 3 pages and the 10th page
-of each of the 8 documents in the Job, as 8 separate documents.
-
-In most cases, the exact pages to be printed will be generated by a
-device driver and this attribute would not be required. However, when
-printing an archived document which has already been formatted, the end
-user may elect to print just a subset of the pages contained in the
-document. In this case, if page-range = n.m is specified, the first
-page to be printed will be page n. All subsequent pages of the document
-will be printed through and including page m.
-
-"page-ranges-supported" is a boolean value indicating whether or not the
-printer is capable of supporting the printing of page ranges. This
-capability may differ from one PDL to another. There is no "page-ranges-
-default" attribute. If the "page-ranges" attribute is not supplied by
-the client, all pages of the document will be printed.
-
-Note: The effect of this attribute on jobs with multiple documents is
-controlled by the "multiple-document-handling" job attribute (section
-4.2.4) and the relationship of this attribute and the other attributes
-that control document processing is described in section 15.3.
-
-
-4.2.8 sides (type2 keyword)
-
-This attribute specifies how print-stream pages are to be imposed upon
-the sides of an instance of a selected medium, i.e., an impression.
-
-The standard keyword values are:
-
- 'one-sided': imposes each consecutive print-stream page upon the same
- side of consecutive media sheets.
- 'two-sided-long-edge': imposes each consecutive pair of print-stream
- pages upon front and back sides of consecutive media sheets, such
- that the orientation of each pair of print-stream pages on the
- medium would be correct for the reader as if for binding on the
- long edge. This imposition is sometimes called 'duplex' or 'head-
- to-head'.
- 'two-sided-short-edge': imposes each consecutive pair of print-stream
- pages upon front and back sides of consecutive media sheets, such
- that the orientation of each pair of print-stream pages on the
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 89]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- medium would be correct for the reader as if for binding on the
- short edge. This imposition is sometimes called 'tumble' or 'head-
- to-toe'.
-
-
-'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex'
-all work the same for portrait or landscape. However 'head-to-toe' is
-'tumble' in portrait but 'duplex' in landscape. 'head-to-head' also
-switches between 'duplex' and 'tumble' when using portrait and landscape
-modes.
-
-Note: The effect of this attribute on jobs with multiple documents is
-controlled by the "multiple-document-handling" job attribute (section
-4.2.4) and the relationship of this attribute and the other attributes
-that control document processing is described in section 15.3.
-
-
-4.2.9 number-up (integer(1:MAX))
-
-This attribute specifies the number of print-stream pages to impose upon
-a single side of an instance of a selected medium. For example, if the
-value is:
-
- Value Description
-
- '1' the Printer MUST place one print-stream page on a single side
- of an instance of the selected medium (MAY add some sort
- of translation, scaling, or rotation).
- '2' the Printer MUST place two print-stream pages on a single side
- of an instance of the selected medium (MAY add some sort
- of translation, scaling, or rotation).
- '4' the Printer MUST place four print-stream pages on a single
- side of an instance of the selected medium (MAY add some
- sort of translation, scaling, or rotation).
-
-
-This attribute primarily controls the translation, scaling and rotation
-of print-stream pages.
-
-Note: The effect of this attribute on jobs with multiple documents is
-controlled by the "multiple-document-handling" job attribute (section
-4.2.4) and the relationship of this attribute and the other attributes
-that control document processing is described in section 15.3.
-
-
-4.2.10 orientation-requested (type2 enum)
-
-This attribute indicates the desired orientation for printed print-
-stream pages; it does not describe the orientation of the client-
-supplied print-stream pages.
-
-For some document formats (such as 'application/postscript'), the
-desired orientation of the print-stream pages is specified within the
-document data. This information is generated by a device driver prior
-to the submission of the print job. Other document formats (such as
-'text/plain') do not include the notion of desired orientation within
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 90]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-the document data. In the latter case it is possible for the Printer
-object to bind the desired orientation to the document data after it has
-been submitted. It is expected that a Printer object would only support
-"orientations-requested" for some document formats (e.g., 'text/plain'
-or 'text/html') but not others (e.g., 'application/postscript'). This
-is no different than any other Job Template attribute since section 4.2,
-item 1, points out that a Printer object may support or not support any
-Job Template attribute based on the document format supplied by the
-client. However, a special mention is made here since it is very likely
-that a Printer object will support "orientation-requested" for only a
-subset of the supported document formats.
-
-Standard enum values are:
-
- Value Symbolic Name and Description
-
- '3' 'portrait': The content will be imaged across the short edge
- of the medium.
- '4' 'landscape': The content will be imaged across the long edge
- of the medium. Landscape is defined to be a rotation of
- the print-stream page to be imaged by +90 degrees with
- respect to the medium (i.e. anti-clockwise) from the
- portrait orientation. Note: The +90 direction was
- chosen because simple finishing on the long edge is the
- same edge whether portrait or landscape
- '5' 'reverse-landscape': The content will be imaged across the
- long edge of the medium. Reverse-landscape is defined to
- be a rotation of the print-stream page to be imaged by -
- 90 degrees with respect to the medium (i.e. clockwise)
- from the portrait orientation. Note: The 'reverse-
- landscape' value was added because some applications
- rotate landscape -90 degrees from portrait, rather than
- +90 degrees.
- '6' 'reverse-portrait': The content will be imaged across the
- short edge of the medium. Reverse-portrait is defined to
- be a rotation of the print-stream page to be imaged by
- 180 degrees with respect to the medium from the portrait
- orientation. Note: The 'reverse-portrait' value was
- added for use with the "finishings" attribute in cases
- where the opposite edge is desired for finishing a
- portrait document on simple finishing devices that have
- only one finishing position. Thus a 'text'/plain'
- portrait document can be stapled "on the right" by a
- simple finishing device as is common use with some middle
- eastern languages such as Hebrew.
-
-
-Note: The effect of this attribute on jobs with multiple documents is
-controlled by the "multiple-document-handling" job attribute (section
-4.2.4) and the relationship of this attribute and the other attributes
-that control document processing is described in section 15.3.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 91]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.2.11 media (type3 keyword | name(MAX))
-
-This attribute identifies the medium that the Printer uses for all
-impressions of the Job.
-
-The values for "media" include medium-names, medium-sizes, input-trays
-and electronic forms so that one attribute specifies the media. If a
-Printer object supports a medium name as a value of this attribute, such
-a medium name implicitly selects an input-tray that contains the
-specified medium. If a Printer object supports a medium size as a value
-of this attribute, such a medium size implicitly selects a medium name
-that in turn implicitly selects an input-tray that contains the medium
-with the specified size. If a Printer object supports an input-tray as
-the value of this attribute, such an input-tray implicitly selects the
-medium that is in that input-tray at the time the job prints. This case
-includes manual-feed input-trays. If a Printer object supports an
-electronic form as the value of this attribute, such an electronic form
-implicitly selects a medium-name that in turn implicitly selects an
-input-tray that contains the medium specified by the electronic form.
-The electronic form also implicitly selects an image that the Printer
-MUST merge with the document data as its prints each page.
-
-Standard keyword values are taken from ISO DPA [ISO10175], the Printer
-MIB [RFC1759], and ASME-Y14.1M [ASME-Y14.1M] and are listed in section
-14. An administrator MAY define additional values using the 'name' or
-'keyword' attribute syntax, depending on implementation.
-
-There is also an additional Printer attribute named "media-ready" which
-differs from "media-supported" in that legal values only include the
-subset of "media-supported" values that are physically loaded and ready
-for printing with no operator intervention required. If an IPP object
-supports "media-supported", it NEED NOT support "media-ready".
-
-The relationship of this attribute and the other attributes that control
-document processing is described in section 15.3.
-
-
-4.2.12 printer-resolution (resolution)
-
-This attribute identifies the resolution that Printer uses for the Job.
-
-
-4.2.13 print-quality (type2 enum)
-
-This attribute specifies the print quality that the Printer uses for the
-Job.
-
-The standard enum values are:
-
- Value Symbolic Name and Description
-
- '3' 'draft': lowest quality available on the printer
- '4' 'normal': normal or intermediate quality on the printer
- '5' 'high': highest quality available on the printer
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 92]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.3 Job Description Attributes
-
-
-The attributes in this section form the attribute group called "job-
-description". The following table summarizes these attributes. The
-third column indicates whether the attribute is a REQUIRED attribute
-that MUST be supported by Printer objects. If it is not indicated as
-REQUIRED, then it is OPTIONAL. The maximum size in octets for 'text'
-and 'name' attributes is indicated in parenthesizes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 93]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-+----------------------------+----------------------+----------------+
-| Attribute | Syntax | REQUIRED? |
-+----------------------------+----------------------+----------------+
-| job-uri | uri | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-id | integer(1:MAX) | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-printer-uri | uri | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-more-info | uri | |
-+----------------------------+----------------------+----------------+
-| job-name | name (MAX) | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-originating-user-name | name (MAX) | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-state | type1 enum | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-state-reasons | 1setOf type2 keyword | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-state-message | text (MAX) | |
-+----------------------------+----------------------+----------------+
-| job-detailed-status- | 1setOf text (MAX) | |
-| messages | | |
-+----------------------------+----------------------+----------------+
-| job-document-access-errors | 1setOf text (MAX) | |
-+----------------------------+----------------------+----------------+
-| number-of-documents | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-| output-device-assigned | name (127) | |
-+----------------------------+----------------------+----------------+
-| time-at-creation | integer (MIN:MAX) | REQUIRED |
-+----------------------------+----------------------+----------------+
-| time-at-processing | integer (MIN:MAX) | REQUIRED |
-+----------------------------+----------------------+----------------+
-| time-at-completed | integer (MIN:MAX) | REQUIRED |
-+----------------------------+----------------------+----------------+
-| job-printer-up-time | integer (1:MAX) | REQUIRED |
-+----------------------------+----------------------+----------------+
-| date-time-at-creation | dateTime | |
-+----------------------------+----------------------+----------------+
-| date-time-at-processing | dateTime | |
-+----------------------------+----------------------+----------------+
-| date-time-at-completed | dateTime | |
-+----------------------------+----------------------+----------------+
-| number-of-intervening-jobs | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-| job-message-from-operator | text (127) | |
-+----------------------------+----------------------+----------------+
-| job-k-octets | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-| job-impressions | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-| job-media-sheets | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 94]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-| job-k-octets-processed | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-| job-impressions-completed | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-| job-media-sheets-completed | integer (0:MAX) | |
-+----------------------------+----------------------+----------------+
-| attributes-charset | charset | REQUIRED |
-+----------------------------+----------------------+----------------+
-| attributes-natural-language| naturalLanguage | REQUIRED |
-+----------------------------+----------------------+----------------+
-
-
-
-4.3.1 job-uri (uri)
-
-This REQUIRED attribute contains the URI for the job. The Printer
-object, on receipt of a new job, generates a URI which identifies the
-new Job. The Printer object returns the value of the "job-uri"
-attribute as part of the response to a create request. The precise
-format of a Job URI is implementation dependent. If the Printer object
-supports more than one URI and there is some relationship between the
-newly formed Job URI and the Printer object's URI, the Printer object
-uses the Printer URI supplied by the client in the create request. For
-example, if the create request comes in over a secure channel, the new
-Job URI MUST use the same secure channel. This can be guaranteed
-because the Printer object is responsible for generating the Job URI and
-the Printer object is aware of its security configuration and policy as
-well as the Printer URI used in the create request.
-
-For a description of this attribute and its relationship to "job-id" and
-"job-printer-uri" attribute, see the discussion in section 2.4 on
-"Object Identity".
-
-
-4.3.2 job-id (integer(1:MAX))
-
-This REQUIRED attribute contains the ID of the job. The Printer, on
-receipt of a new job, generates an ID which identifies the new Job on
-that Printer. The Printer returns the value of the "job-id" attribute
-as part of the response to a create request. The 0 value is not
-included to allow for compatibility with SNMP index values which also
-cannot be 0.
-
-For a description of this attribute and its relationship to "job-uri"
-and "job-printer-uri" attribute, see the discussion in section 2.4 on
-"Object Identity".
-
-
-4.3.3 job-printer-uri (uri)
-
-This REQUIRED attribute identifies the Printer object that created this
-Job object. When a Printer object creates a Job object, it populates
-this attribute with the Printer object URI that was used in the create
-request. This attribute permits a client to identify the Printer object
-that created this Job object when only the Job object's URI is available
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 95]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-to the client. The client queries the creating Printer object to
-determine which languages, charsets, operations, are supported for this
-Job.
-
-For a description of this attribute and its relationship to "job-uri"
-and "job-id" attribute, see the discussion in section 2.4 on "Object
-Identity".
-
-
-4.3.4 job-more-info (uri)
-
-Similar to "printer-more-info", this attribute contains the URI
-referencing some resource with more information about this Job object,
-perhaps an HTML page containing information about the Job.
-
-
-4.3.5 job-name (name(MAX))
-
-This REQUIRED attribute is the name of the job. It is a name that is
-more user friendly than the "job-uri" attribute value. It does not need
-to be unique between Jobs. The Job's "job-name" attribute is set to the
-value supplied by the client in the "job-name" operation attribute in
-the create request (see Section 3.2.1.1). If, however, the "job-name"
-operation attribute is not supplied by the client in the create request,
-the Printer object, on creation of the Job, MUST generate a name. The
-printer SHOULD generate the value of the Job's "job-name" attribute from
-the first of the following sources that produces a value: 1) the
-"document-name" operation attribute of the first (or only) document, 2)
-the "document-URI" attribute of the first (or only) document, or 3) any
-other piece of Job specific and/or Document Content information.
-
-
-4.3.6 job-originating-user-name (name(MAX))
-
-This REQUIRED attribute contains the name of the end user that submitted
-the print job. The Printer object sets this attribute to the most
-authenticated printable name that it can obtain from the authentication
-service over which the IPP operation was received. Only if such is not
-available, does the Printer object use the value supplied by the client
-in the "requesting-user-name" operation attribute of the create
-operation (see Sections 4.4.2, 4.4.3, and 8).
-
-Note: The Printer object needs to keep an internal originating user id
-of some form, typically as a credential of a principal, with the Job
-object. Since such an internal attribute is implementation-dependent
-and not of interest to clients, it is not specified as a Job Description
-attribute. This originating user id is used for authorization checks
-(if any) on all subsequent operations.
-
-
-4.3.7 job-state (type1 enum)
-
-This REQUIRED attribute identifies the current state of the job. Even
-though the IPP protocol defines seven values for job states (plus the
-out-of-band 'unknown' value - see Section 4.1), implementations only
-need to support those states which are appropriate for the particular
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 96]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-implementation. In other words, a Printer supports only those job
-states implemented by the output device and available to the Printer
-object implementation.
-
-Standard enum values are:
-
- Values Symbolic Name and Description
-
- '3' 'pending': The job is a candidate to start processing, but is
- not yet processing.
-
- '4' 'pending-held': The job is not a candidate for processing for
- any number of reasons but will return to the 'pending'
- state as soon as the reasons are no longer present. The
- job's "job-state-reason" attribute MUST indicate why the
- job is no longer a candidate for processing.
-
- '5' 'processing': One or more of:
-
- 1. the job is using, or is attempting to use, one or
- more purely software processes that are analyzing,
- creating, or interpreting a PDL, etc.,
- 2. the job is using, or is attempting to use, one or
- more hardware devices that are interpreting a PDL, making
- marks on a medium, and/or performing finishing, such as
- stapling, etc.,
- 3. the Printer object has made the job ready for
- printing, but the output device is not yet printing it,
- either because the job hasn't reached the output device
- or because the job is queued in the output device or some
- other spooler, awaiting the output device to print it.
-
-
- When the job is in the 'processing' state, the entire job
- state includes the detailed status represented in the
- Printer object's "printer-state", "printer-state-
- reasons", and "printer-state-message" attributes.
-
- Implementations MAY, though they NEED NOT, include
- additional values in the job's "job-state-reasons"
- attribute to indicate the progress of the job, such as
- adding the 'job-printing' value to indicate when the
- output device is actually making marks on paper and/or
- the 'processing-to-stop-point' value to indicate that the
- IPP object is in the process of canceling or aborting the
- job. Most implementations won't bother with this nuance.
-
-
- '6' 'processing-stopped': The job has stopped while processing
- for any number of reasons and will return to the
- 'processing' state as soon as the reasons are no longer
- present.
-
-
- The job's "job-state-reason" attribute MAY indicate why
- the job has stopped processing. For example, if the
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 97]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- output device is stopped, the 'printer-stopped' value MAY
- be included in the job's "job-state-reasons" attribute.
-
-
- Note: When an output device is stopped, the device
- usually indicates its condition in human readable form
- locally at the device. A client can obtain more complete
- device status remotely by querying the Printer object's
- "printer-state", "printer-state-reasons" and "printer-
- state-message" attributes.
-
-
- '7' 'canceled': The job has been canceled by a Cancel-Job
- operation and the Printer object has completed canceling
- the job and all job status attributes have reached their
- final values for the job. While the Printer object is
- canceling the job, the job remains in its current state,
- but the job's "job-state-reasons" attribute SHOULD
- contain the 'processing-to-stop-point' value and one of
- the 'canceled-by-user', 'canceled-by-operator', or
- 'canceled-at-device' value. When the job moves to the
- 'canceled' state, the 'processing-to-stop-point' value,
- if present, MUST be removed, but the 'canceled-by-xxx',
- if present, MUST remain.
-
- '8' 'aborted': The job has been aborted by the system, usually
- while the job was in the 'processing' or 'processing-
- stopped' state and the Printer has completed aborting the
- job and all job status attributes have reached their
- final values for the job. While the Printer object is
- aborting the job, the job remains in its current state,
- but the job's "job-state-reasons" attribute SHOULD
- contain the 'processing-to-stop-point' and 'aborted-by-
- system' values. When the job moves to the 'aborted'
- state, the 'processing-to-stop-point' value, if present,
- MUST be removed, but the 'aborted-by-system' value, if
- present, MUST remain.
-
- '9' 'completed': The job has completed successfully or with
- warnings or errors after processing and all of the job
- media sheets have been successfully stacked in the
- appropriate output bin(s) and all job status attributes
- have reached their final values for the job. The job's
- "job-state-reasons" attribute SHOULD contain one of:
- 'completed-successfully', 'completed-with-warnings', or
- 'completed-with-errors' values.
-
-
-The final value for this attribute MUST be one of: 'completed',
-'canceled', or 'aborted' before the Printer removes the job altogether.
-The length of time that jobs remain in the 'canceled', 'aborted', and
-'completed' states depends on implementation. See section 4.3.7.2.
-
-The following figure shows the normal job state transitions.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 98]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- +----> canceled
- /
- +----> pending --------> processing ---------+------> completed
- | ^ ^ \
---->+ | | +----> aborted
- | v v /
- +----> pending-held processing-stopped ---+
-
-
-Normally a job progresses from left to right. Other state transitions
-are unlikely, but are not forbidden. Not shown are the transitions to
-the 'canceled' state from the 'pending', 'pending-held', and
-'processing-stopped' states.
-
-Jobs reach one of the three terminal states: 'completed', 'canceled', or
-'aborted', after the jobs have completed all activity, including
-stacking output media, after the jobs have completed all activity, and
-all job status attributes have reached their final values for the job.
-
-
-4.3.7.1 Forwarding Servers
-
-As with all other IPP attributes, if the implementation cannot determine
-the correct value for this attribute, it SHOULD respond with the out-of-
-band value 'unknown' (see section 4.1) rather than try to guess at some
-possibly incorrect value and give the end user the wrong impression
-about the state of the Job object. For example, if the implementation
-is just a gateway into some printing system from which it can normally
-get status, but temporarily is unable, then the implementation should
-return the 'unknown' value. However, if the implementation is a gateway
-to a printing system that never provides detailed status about the print
-job, the implementation MAY set the IPP Job object's state to
-'completed', provided that it also sets the 'queued-in-device' value in
-the job's "job-state-reasons" attribute (see section 4.3.8).
-
-
-4.3.7.2 Partitioning of Job States
-
-This section partitions the 7 job states into phases: Job Not
-Completed, Job Retention, Job History, and Job Removal. This section
-also explains the 'job-restartable' value of the "job-state-reasons" Job
-Description attribute for use with the Restart-Job operation.
-
-Job Not Completed: When a job is in the 'pending', 'pending-held',
-'processing', or 'processing-stopped' states, the job is not completed.
-
-Job Retention: When a job enters one of the three terminal job states:
-'completed', 'canceled', or 'aborted', the IPP Printer object MAY
-"retain" the job in a restartable condition for an implementation-
-defined time period. This time period MAY be zero seconds and MAY
-depend on the terminal job state. This phase is called Job Retention.
-While in the Job Retention phase, the job's document data is retained
-and a client may restart the job using the Restart-Job operation. If
-the IPP object supports the Restart-Job operation, then it SHOULD
-indicate that the job is restartable by adding the 'job-restartable'
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 99]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-value to the job's "job-state-reasons" attribute (see Section 4.3.8)
-during the Job Retention phase.
-
-Job History: After the Job Retention phase expires for a job, the
-Printer object deletes the document data for the job and the job becomes
-part of the Job History. The Printer object MAY also delete any number
-of the job attributes. Since the job is no longer restartable, the
-Printer object MUST remove the 'job-restartable' value from the job's
-"job-state-reasons" attribute, if present.
-
-Job Removal: After the job has remained in the Job History for an
-implementation-defined time, such as when the number of jobs exceeds a
-fixed number or after a fixed time period (which MAY be zero seconds),
-the IPP Printer removes the job from the system.
-
-Using the Get-Jobs operation and supplying the 'not-completed' value for
-the "which-jobs" operation attribute, a client is requesting jobs in the
-Job Not Completed phase. Using the Get-Jobs operation and supplying the
-'completed' value for the "which-jobs" operation attribute, a client is
-requesting jobs in the Job Retention and Job History phases. Using the
-Get-Job-Attributes operation, a client is requesting a job in any phase
-except Job Removal. After Job Removal, the Get-Job-Attributes and Get-
-Jobs operations no longer are capable of returning any information about
-a job.
-
-
-4.3.8 job-state-reasons (1setOf type2 keyword)
-
-This REQUIRED attribute provides additional information about the job's
-current state, i.e., information that augments the value of the job's
-"job-state" attribute.
-
-These values MAY be used with any job state or states for which the
-reason makes sense. Some of these value definitions indicate
-conformance requirements; the rest are OPTIONAL. Furthermore, when
-implemented, the Printer MUST return these values when the reason
-applies and MUST NOT return them when the reason no longer applies
-whether the value of the Job's "job-state" attribute changed or not.
-When the Job does not have any reasons for being in its current state,
-the value of the Job's "job-state-reasons" attribute MUST be 'none'.
-
-Note: While values cannot be added to the 'job-state' attribute without
-impacting deployed clients that take actions upon receiving "job-state"
-values, it is the intent that additional "job-state-reasons" values can
-be defined and registered without impacting such deployed clients. In
-other words, the "job-state-reasons" attribute is intended to be
-extensible.
-
-The following standard keyword values are defined. For ease of
-understanding, the values are presented in the order in which the
-reasons are likely to occur (if implemented), starting with the 'job-
-incoming' value:
-
- 'none': There are no reasons for the job's current state. This
- state reason is semantically equivalent to "job-state-reasons"
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 100]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- without any value and MUST be used when there is no other value,
- since the 1setOf attribute syntax requires at least one value.
- 'job-incoming': Either (1) the Printer has accepted the Create-Job
- operation and is expecting additional Send-Document and/or Send-URI
- operations, or (2) the Printer is retrieving/accepting document
- data as a result of a Print-Job, Print-URI, Send-Document or Send-
- URI operation.
- 'job-data-insufficient': The Create-Job operation has been accepted
- by the Printer, but the Printer is expecting additional document
- data before it can move the job into the 'processing' state. If a
- Printer starts processing before it has received all data, the
- Printer removes the 'job-data-insufficient' reason, but the 'job-
- incoming' remains. If a Printer starts processing after it has
- received all data, the Printer removes the 'job-data-insufficient'
- reason and the 'job-incoming' at the same time.
- 'document-access-error': After accepting a Print-URI or Send-URI
- request, the Printer could not access one or more documents passed
- by reference. This reason is intended to cover any file access
- problem, including file does not exist and access denied because of
- an access control problem. The Printer MAY also indicate the
- document access error using the "job-document-access-errors" Job
- Description attribute (see section 4.3.11). Whether the Printer
- aborts the job and moves the job to the 'aborted' job state or
- prints all documents that are accessible and moves the job to the
- 'completed' job state and adds the 'completed-with-errors' value in
- the job's "job-state-reasons" attribute depends on implementation
- and/or site policy. This value SHOULD be supported if the Print-
- URI or Send-URI operations are supported.
- 'submission-interrupted': The job was not completely submitted for
- some unforeseen reason, such as: (1) the Printer has crashed before
- the job was closed by the client, (2) the Printer or the document
- transfer method has crashed in some non-recoverable way before the
- document data was entirely transferred to the Printer, (3) the
- client crashed or failed to close the job before the time-out
- period. See section 4.4.31.
- 'job-outgoing': The Printer is transmitting the job to the output
- device.
- 'job-hold-until-specified': The value of the job's "job-hold-until"
- attribute was specified with a time period that is still in the
- future. The job MUST NOT be a candidate for processing until this
- reason is removed and there are no other reasons to hold the job.
- This value SHOULD be supported if the "job-hold-until" Job Template
- attribute is supported.
- 'resources-are-not-ready': At least one of the resources needed by
- the job, such as media, fonts, resource objects, etc., is not ready
- on any of the physical printer's for which the job is a candidate.
- This condition MAY be detected when the job is accepted, or
- subsequently while the job is pending or processing, depending on
- implementation. The job may remain in its current state or be
- moved to the 'pending-held' state, depending on implementation
- and/or job scheduling policy.
- 'printer-stopped-partly': The value of the Printer's "printer-state-
- reasons" attribute contains the value 'stopped-partly'.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 101]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'printer-stopped': The value of the Printer's "printer-state"
- attribute is 'stopped'.
- 'job-interpreting': Job is in the 'processing' state, but more
- specifically, the Printer is interpreting the document data.
- 'job-queued': Job is in the 'processing' state, but more
- specifically, the Printer has queued the document data.
- 'job-transforming': Job is in the 'processing' state, but more
- specifically, the Printer is interpreting document data and
- producing another electronic representation.
- 'job-queued-for-marker': Job is in any of the 'pending-held',
- 'pending', or 'processing' states, but more specifically, the
- Printer has completed enough processing of the document to be able
- to start marking and the job is waiting for the marker. Systems
- that require human intervention to release jobs using the Release-
- Job operation, put the job into the 'pending-held' job state.
- Systems that automatically select a job to use the marker put the
- job into the 'pending' job state or keep the job in the
- 'processing' job state while waiting for the marker, depending on
- implementation. All implementations put the job into (or back
- into) the 'processing' state when marking does begin.
- 'job-printing': The output device is marking media. This value is
- useful for Printers which spend a great deal of time processing (1)
- when no marking is happening and then want to show that marking is
- now happening or (2) when the job is in the process of being
- canceled or aborted while the job remains in the 'processing'
- state, but the marking has not yet stopped so that impression or
- sheet counts are still increasing for the job.
- 'job-canceled-by-user': The job was canceled by the owner of the job
- using the Cancel-Job request, i.e., by a user whose authenticated
- identity is the same as the value of the originating user that
- created the Job object, or by some other authorized end-user, such
- as a member of the job owner's security group. This value SHOULD
- be supported.
- 'job-canceled-by-operator': The job was canceled by the operator
- using the Cancel-Job request, i.e., by a user who has been
- authenticated as having operator privileges (whether local or
- remote). If the security policy is to allow anyone to cancel
- anyone's job, then this value may be used when the job is canceled
- by other than the owner of the job. For such a security policy, in
- effect, everyone is an operator as far as canceling jobs with IPP
- is concerned. This value SHOULD be supported if the implementation
- permits canceling by other than the owner of the job.
- 'job-canceled-at-device': The job was canceled by an unidentified
- local user, i.e., a user at a console at the device. This value
- SHOULD be supported if the implementation supports canceling jobs
- at the console.
- 'aborted-by-system': The job (1) is in the process of being aborted,
- (2) has been aborted by the system and placed in the 'aborted'
- state, or (3) has been aborted by the system and placed in the
- 'pending-held' state, so that a user or operator can manually try
- the job again. This value SHOULD be supported.
- 'unsupported-compression': The job was aborted by the system because
- the Printer determined while attempting to decompress the document-
- data's that the compression is actually not among those supported
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 102]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- by the Printer. This value MUST be supported, since "compressions
- is a REQUIRED operation attribute.
- 'compression-error': The job was aborted by the system because the
- Printer encountered an error in the document-data while
- decompressing it. If the Printer posts this reason, the document-
- data has already passed any tests that would have led to the
- 'unsupported-compression' job-state-reason.
- 'unsupported-document-format': The job was aborted by the system
- because the document-data's document-format is not among those
- supported by the Printer. If the client specifies the document-
- format as 'application/octet-stream', the printer MAY abort the job
- and post this reason even though the format is a member of the
- "document-format-supported" printer attribute, but not among the
- auto-sensed document-formats. This value MUST be supported, since
- "document-format" is a REQUIRED operation attribute.
- 'document-format-error': The job was aborted by the system because
- the Printer encountered an error in the document-data while
- processing it. If the Printer posts this reason, the document-data
- has already passed any tests that would have led to the
- 'unsupported-document-format' job-state-reason.
- 'processing-to-stop-point': The requester has issued a Cancel-Job
- operation or the Printer object has aborted the job, but is still
- performing some actions on the job until a specified stop point
- occurs or job termination/cleanup is completed.
-
- If the implementation requires some measurable time to cancel the
- job in the 'processing' or 'processing-stopped' job states, the IPP
- object MUST use this value to indicate that the Printer object is
- still performing some actions on the job while the job remains in
- the 'processing' or 'processing-stopped' state. After all the
- job's job description attributes have stopped incrementing, the
- Printer object moves the job from the 'processing' state to the
- 'canceled' or 'aborted' job states.
-
- 'service-off-line': The Printer is off-line and accepting no jobs.
- All 'pending' jobs are put into the 'pending-held' state. This
- situation could be true if the service's or document transform's
- input is impaired or broken.
- 'job-completed-successfully': The job completed successfully. This
- value SHOULD be supported.
- 'job-completed-with-warnings': The job completed with warnings.
- This value SHOULD be supported if the implementation detects
- warnings.
- 'job-completed-with-errors': The job completed with errors (and
- possibly warnings too). This value SHOULD be supported if the
- implementation detects errors.
- 'job-restartable' - This job is retained (see section 4.3.7.2) and is
- currently able to be restarted using the Restart-Job operation (see
- section 3.3.7). If 'job-restartable' is a value of the job's 'job-
- state-reasons' attribute, then the IPP object MUST accept a
- Restart-Job operation for that job. This value SHOULD be supported
- if the Restart-Job operation is supported.
- 'queued-in-device': The job has been forwarded to a device or print
- system that is unable to send back status. The Printer sets the
- job's "job-state " attribute to 'completed' and adds the 'queued-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 103]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- in-device' value to the job's "job-state-reasons" attribute to
- indicate that the Printer has no additional information about the
- job and never will have any better information. See section
- 4.3.7.1.
-
-4.3.9 job-state-message (text(MAX))
-
-This attribute specifies information about the "job-state" and "job-
-state-reasons" attributes in human readable text. If the Printer object
-supports this attribute, the Printer object MUST be able to generate
-this message in any of the natural languages identified by the Printer's
-"generated-natural-language-supported" attribute (see the "attributes-
-natural-language" operation attribute specified in Section 3.1.4.1).
-
-The value SHOULD NOT contain additional information not contained in the
-values of the "job-state" and "job-states-reasons" attributes, such as
-interpreter error information. Otherwise, application programs might
-attempt to parse the (localized text). For such additional information
-such as interpreter errors for application program consumption or
-specific document access errors, new attributes with keyword values,
-needs to be developed and registered.
-
-
-4.3.10 job-detailed-status-messages (1setOf text(MAX))
-
-This attribute specifies additional detailed and technical information
-about the job. The Printer NEED NOT localize the message(s), since they
-are intended for use by the system administrator or other experienced
-technical persons. Localization might obscure the technical meaning of
-such messages. Clients MUST NOT attempt to parse the value of this
-attribute. See "job-document-access-errors" (section 4.3.11) for
-additional errors that a program can process.
-
-
-4.3.11 job-document-access-errors (1setOf text(MAX))
-
-This attribute provides additional information about each document
-access error for this job encountered by the Printer after it returned a
-response to the Print-URI or Send-URI operation and subsequently
-attempted to access document(s) supplied in the Print-URI or Send-URI
-operation. For errors in the protocol that is identified by the URI
-scheme in the "document-uri" operation attribute, such as 'http:' or
-'ftp:', the error code is returned in parentheses, followed by the URI.
-For example:
-
- (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-
- 990510.pdf
-
-Most Internet protocols use decimal error codes (unlike IPP), so the
-ASCII error code representation is in decimal.
-
-4.3.12 number-of-documents (integer(0:MAX))
-
-This attribute indicates the number of documents in the job, i.e., the
-number of Send-Document, Send-URI, Print-Job, or Print-URI operations
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 104]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-that the Printer has accepted for this job, regardless of whether the
-document data has reached the Printer object or not.
-
-Implementations supporting the OPTIONAL Create-Job/Send-Document/Send-
-URI operations SHOULD support this attribute so that clients can query
-the number of documents in each job.
-
-
-4.3.13 output-device-assigned (name(127))
-
-This attribute identifies the output device to which the Printer object
-has assigned this job. If an output device implements an embedded
-Printer object, the Printer object NEED NOT set this attribute. If a
-print server implements a Printer object, the value MAY be empty (zero-
-length string) or not returned until the Printer object assigns an
-output device to the job. This attribute is particularly useful when a
-single Printer object supports multiple devices (so called "fan-out" -
-see section 2.1).
-
-
-4.3.14 Event Time Job Description Attributes
-
-This section defines the Job Description attributes that indicate the
-time at which certain events occur for a job. If the job event has not
-yet occurred, then the IPP object MUST return the 'no-value' out-of-band
-value (see the beginning of Section 4.1). The "time-at-xxx(integer)"
-attributes represent time as an 'integer' representing the number of
-seconds since the device was powered up (informally called "time
-ticks"). The "date-time-at-xxx(dateTime)" attributes represent time as
-'dateTime' representing date and time (including an offset from UTC).
-
-In order to populate these attributes, the Printer object copies the
-value(s) of the following Printer Description attributes at the time the
-event occurs:
-
- 1. the value in the Printer's "printer-up-time" attribute for the
- "time-at-xxx(integer)" attributes
-
- 2. the value in the Printer's "printer-current-time" attribute for the
- "date-time-at-xxx(dateTime)" attributes.
-
-If the Printer resets its "printer-up-time" attribute to 1 on power-up
-(see section 4.4.29) and has persistent jobs, then it MUST change all of
-jobs' "time-at-xxx(integer)" (time tick) job attributes whose events
-have occurred either to:
-
- 1. 0 to indicate that the event happened before the most recent power
- up OR
-
- 2. the negative of the number of seconds before the most recent power-
- up that the event took place, though the negative number NEED NOT
- reflect the exact number of seconds.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 105]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-If a client queries a "time-at-xxx(integer)" time tick Job attribute and
-finds the value to be 0 or negative, the client MUST assume that the
-event occurred in some life other than the Printer's current life.
-
-Note: A Printer does not change the values of any "date-time-at-
-xxx(dateTime)" job attributes on power-up.
-
-
-4.3.14.1 time-at-creation (integer(MIN:MAX))
-
-This REQUIRED attribute indicates the time at which the Job object was
-created.
-
-
-4.3.14.2 time-at-processing (integer(MIN:MAX))
-
-This REQUIRED attribute indicates the time at which the Job object first
-began processing after the create operation or the most recent Restart-
-Job operation. The out-of-band 'no-value' value is returned if the job
-has not yet been in the 'processing' state (see the beginning of Section
-4.1).
-
-
-4.3.14.3 time-at-completed (integer(MIN:MAX))
-
-This REQUIRED attribute indicates the time at which the Job object
-completed (or was canceled or aborted). The out-of-band 'no-value'
-value is returned if the job has not yet completed, been canceled, or
-aborted (see the beginning of Section 4.1).
-
-
-4.3.14.4 job-printer-up-time (integer(1:MAX))
-
-This REQUIRED Job Description attribute indicates the amount of time (in
-seconds) that the Printer implementation has been up and running. This
-attribute is an alias for the "printer-up-time" Printer Description
-attribute (see Section 4.4.29).
-
-A client MAY request this attribute in a Get-Job-Attributes or Get-Jobs
-request and use the value returned in combination with other requested
-Event Time Job Description Attributes in order to display time
-attributes to a user. The difference between this attribute and the
-'integer' value of a "time-at-xxx" attribute is the number of seconds
-ago that the "time-at-xxx" event occurred. A client can compute the
-wall-clock time at which the "time-at-xxx" event occurred by subtracting
-this difference from the client's wall-clock time.
-
-
-4.3.14.5 date-time-at-creation (dateTime)
-
-This attribute indicates the date and time at which the Job object was
-created.
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 106]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.3.14.6 date-time-at-processing (dateTime)
-
-This attribute indicates the date and time at which the Job object first
-began processing after the create operation or the most recent Restart-
-Job operation.
-
-
-4.3.14.7 date-time-at-completed (dateTime)
-
-This attribute indicates the date and time at which the Job object
-completed (or was canceled or aborted).
-
-
-
-
-4.3.15 number-of-intervening-jobs (integer(0:MAX))
-
-This attribute indicates the number of jobs that are "ahead" of this job
-in the relative chronological order of expected time to complete (i.e.,
-the current scheduled order). For efficiency, it is only necessary to
-calculate this value when an operation is performed that requests this
-attribute.
-
-
-4.3.16 job-message-from-operator (text(127))
-
-This attribute provides a message from an operator, system administrator
-or "intelligent" process to indicate to the end user the reasons for
-modification or other management action taken on a job.
-
-
-4.3.17 Job Size Attributes
-
-This sub-section defines job attributes that describe the size of the
-job. These attributes are not intended to be counters; they are
-intended to be useful routing and scheduling information if known. For
-these attributes, the Printer object may try to compute the value if it
-is not supplied in the create request. Even if the client does supply a
-value for these three attributes in the create request, the Printer
-object MAY choose to change the value if the Printer object is able to
-compute a value which is more accurate than the client supplied value.
-The Printer object may be able to determine the correct value for these
-attributes either right at job submission time or at any later point in
-time.
-
-
-4.3.17.1 job-k-octets (integer(0:MAX))
-
-This attribute specifies the total size of the document(s) in K octets,
-i.e., in units of 1024 octets requested to be processed in the job. The
-value MUST be rounded up, so that a job between 1 and 1024 octets MUST
-be indicated as being 1, 1025 to 2048 MUST be 2, etc.
-
-This value MUST NOT include the multiplicative factors contributed by
-the number of copies specified by the "copies" attribute, independent of
-whether the device can process multiple copies without making multiple
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 107]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-passes over the job or document data and independent of whether the
-output is collated or not. Thus the value is independent of the
-implementation and indicates the size of the document(s) measured in K
-octets independent of the number of copies.
-
-This value MUST also not include the multiplicative factor due to a
-copies instruction embedded in the document data. If the document data
-actually includes replications of the document data, this value will
-include such replication. In other words, this value is always the size
-of the source document data, rather than a measure of the hardcopy
-output to be produced.
-
-
-4.3.17.2 job-impressions (integer(0:MAX))
-
-This attribute specifies the total size in number of impressions of the
-document(s) being submitted (see the definition of impression in section
-12.2.5).
-
-As with "job-k-octets", this value MUST NOT include the multiplicative
-factors contributed by the number of copies specified by the "copies"
-attribute, independent of whether the device can process multiple copies
-without making multiple passes over the job or document data and
-independent of whether the output is collated or not. Thus the value is
-independent of the implementation and reflects the size of the
-document(s) measured in impressions independent of the number of copies.
-
-As with "job-k-octets", this value MUST also not include the
-multiplicative factor due to a copies instruction embedded in the
-document data. If the document data actually includes replications of
-the document data, this value will include such replication. In other
-words, this value is always the number of impressions in the source
-document data, rather than a measure of the number of impressions to be
-produced by the job.
-
-
-4.3.17.3 job-media-sheets (integer(0:MAX))
-
-This attribute specifies the total number of media sheets to be produced
-for this job.
-
-Unlike the "job-k-octets" and the "job-impressions" attributes, this
-value MUST include the multiplicative factors contributed by the number
-of copies specified by the "copies" attribute and a 'number of copies'
-instruction embedded in the document data, if any. This difference
-allows the system administrator to control the lower and upper bounds of
-both (1) the size of the document(s) with "job-k-octets-supported" and
-"job-impressions-supported" and (2) the size of the job with "job-media-
-sheets-supported".
-
-
-4.3.18 Job Progress Attributes
-
-This sub-section defines job attributes that describe the progress of
-the job. These attributes are intended to be counters. That is, the
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 108]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-value for a job that has not started processing MUST be 0. When the
-job's "job-state" is 'processing' or 'processing-stopped', this value is
-intended to contain the amount of the job that has been processed to the
-time at which the attributes are requested. When the job enters the
-'completed', 'canceled', or 'aborted' states, these values are the final
-values for the job.
-
-
-4.3.18.1 job-k-octets-processed (integer(0:MAX))
-
-This attribute specifies the total number of octets processed in K
-octets, i.e., in units of 1024 octets so far. The value MUST be rounded
-up, so that a job between 1 and 1024 octets inclusive MUST be indicated
-as being 1, 1025 to 2048 inclusive MUST be 2, etc.
-
-For implementations where multiple copies are produced by the
-interpreter with only a single pass over the data, the final value MUST
-be equal to the value of the "job-k-octets" attribute. For
-implementations where multiple copies are produced by the interpreter by
-processing the data for each copy, the final value MUST be a multiple of
-the value of the "job-k-octets" attribute.
-
-
-4.3.18.2 job-impressions-completed (integer(0:MAX))
-
-This job attribute specifies the number of impressions completed for the
-job so far. For printing devices, the impressions completed includes
-interpreting, marking, and stacking the output.
-
-
-4.3.18.3 job-media-sheets-completed (integer(0:MAX))
-
-This job attribute specifies the media-sheets completed marking and
-stacking for the entire job so far whether those sheets have been
-processed on one side or on both.
-
-
-4.3.19 attributes-charset (charset)
-
-This REQUIRED attribute is populated using the value in the client
-supplied "attributes-charset" attribute in the create request. It
-identifies the charset (coded character set and encoding method) used by
-any Job attributes with attribute syntax 'text' and 'name' that were
-supplied by the client in the create request. See Section 3.1.4 for a
-complete description of the "attributes-charset" operation attribute.
-
-This attribute does not indicate the charset in which the 'text' and
-'name' values are stored internally in the Job object. The internal
-charset is implementation-defined. The IPP object MUST convert from
-whatever the internal charset is to that being requested in an operation
-as specified in Section 3.1.4.
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 109]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.3.20 attributes-natural-language (naturalLanguage)
-
-This REQUIRED attribute is populated using the value in the client
-supplied "attributes-natural-language" attribute in the create request.
-It identifies the natural language used for any Job attributes with
-attribute syntax 'text' and 'name' that were supplied by the client in
-the create request. See Section 3.1.4 for a complete description of the
-"attributes-natural-language" operation attribute. See Sections 4.1.1.2
-and 4.1.2.2 for how a Natural Language Override may be supplied
-explicitly for each 'text' and 'name' attribute value that differs from
-the value identified by the "attributes-natural-language" attribute.
-
-
-4.4 Printer Description Attributes
-
-
-These attributes form the attribute group called "printer-description".
-The following table summarizes these attributes, their syntax, and
-whether or not they are REQUIRED for a Printer object to support. If
-they are not indicated as REQUIRED, they are OPTIONAL. The maximum size
-in octets for 'text' and 'name' attributes is indicated in
-parenthesizes.
-
-Note: How these attributes are set by an Administrator is outside the
-scope of this IPP/1.1 document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 110]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-+----------------------------+---------------------------+-----------+
-| Attribute | Syntax | REQUIRED? |
-+----------------------------+---------------------------+-----------+
-| printer-uri-supported | 1setOf uri | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| uri-security-supported | 1setOf type2 keyword | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| uri-authentication- | 1setOf type2 keyword | REQUIRED |
-| supported | | |
-+----------------------------+---------------------------+-----------+
-| printer-name | name (127) | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| printer-location | text (127) | |
-+----------------------------+---------------------------+-----------+
-| printer-info | text (127) | |
-+----------------------------+---------------------------+-----------+
-| printer-more-info | uri | |
-+----------------------------+---------------------------+-----------+
-| printer-driver-installer | uri | |
-+----------------------------+---------------------------+-----------+
-| printer-make-and-model | text (127) | |
-+----------------------------+---------------------------+-----------+
-| printer-more-info- | uri | |
-| manufacturer | | |
-+----------------------------+---------------------------+-----------+
-| printer-state | type1 enum | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| printer-state-reasons | 1setOf type2 keyword | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| printer-state-message | text (MAX) | |
-+----------------------------+---------------------------+-----------+
-| ipp-versions-supported | 1setOf type2 keyword | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| operations-supported | 1setOf type2 enum | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| multiple-document-jobs- | boolean | |
-| supported | | |
-+----------------------------+---------------------------+-----------+
-| charset-configured | charset | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| charset-supported | 1setOf charset | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| natural-language-configured| naturalLanguage | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| generated-natural-language-| 1setOf naturalLanguage | REQUIRED |
-| supported | | |
-+----------------------------+---------------------------+-----------+
-| document-format-default | mimeMediaType | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| document-format-supported | 1setOf mimeMediaType | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| printer-is-accepting-jobs | boolean | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| queued-job-count | integer (0:MAX) | REQUIRED |
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 111]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-+----------------------------+---------------------------+-----------+
-| printer-message-from- | text (127) | |
-| operator | | |
-+----------------------------+---------------------------+-----------+
-| color-supported | boolean | |
-+----------------------------+---------------------------+-----------+
-| reference-uri-schemes- | 1setOf uriScheme | |
-| supported | | |
-+----------------------------+---------------------------+-----------+
-| pdl-override-supported | type2 keyword | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| printer-up-time | integer (1:MAX) | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| printer-current-time | dateTime | |
-+----------------------------+---------------------------+-----------+
-| multiple-operation-time-out| integer (1:MAX) | |
-+----------------------------+---------------------------+-----------+
-| compression-supported | 1setOf type3 keyword | REQUIRED |
-+----------------------------+---------------------------+-----------+
-| job-k-octets-supported | rangeOfInteger (0:MAX) | |
-+----------------------------+---------------------------+-----------+
-| job-impressions-supported | rangeOfInteger (0:MAX) | |
-+----------------------------+---------------------------+-----------+
-| job-media-sheets-supported | rangeOfInteger (0:MAX) | |
-+----------------------------+---------------------------+-----------+
-| pages-per-minute | integer(0:MAX) | |
-+----------------------------+---------------------------+-----------+
-| pages-per-minute-color | integer(0:MAX) | |
-+----------------------------+---------------------------+-----------+
-
-
-4.4.1 printer-uri-supported (1setOf uri)
-
-This REQUIRED Printer attribute contains at least one URI for the
-Printer object. It OPTIONALLY contains more than one URI for the
-Printer object. An administrator determines a Printer object's URI(s)
-and configures this attribute to contain those URIs by some means
-outside the scope of this IPP/1.1 document. The precise format of this
-URI is implementation dependent and depends on the protocol. See the
-next two sections for a description of the "uri-security-supported" and
-"uri-authentication-supported" attributes, both of which are the
-REQUIRED companion attributes to this "printer-uri-supported" attribute.
-See section 2.4 on Printer object identity and section 8.2 on security
-and URIs for more information.
-
-
-4.4.2 uri-authentication-supported (1setOf type2 keyword)
-
-This REQUIRED Printer attribute MUST have the same cardinality (contain
-the same number of values) as the "printer-uri-supported" attribute.
-This attribute identifies the Client Authentication mechanism associated
-with each URI listed in the "printer-uri-supported" attribute. The
-Printer object uses the specified mechanism to identify the
-authenticated user (see section 8.3) . The "i th" value in "uri-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 112]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-authentication-supported" corresponds to the "i th" value in "printer-
-uri-supported" and it describes the authentication mechanisms used by
-the Printer when accessed via that URI. See [IPP-PRO] for more details
-on Client Authentication.
-
-The following standard keyword values are defined:
-
- 'none': There is no authentication mechanism associated with the URI.
- The Printer object assumes that the authenticated user is
- "anonymous".
- 'requesting-user-name': When a client performs an operation whose
- target is the associated URI, the Printer object assumes that the
- authenticated user is specified by the "requesting-user-name"
- Operation attribute (see section 8.3). If the "requesting-user-
- name" attribute is absent in a request, the Printer object assumes
- that the authenticated user is "anonymous".
- 'basic': When a client performs an operation whose target is the
- associated URI, the Printer object challenges the client with HTTP
- basic authentication [RFC2617]. The Printer object assumes that the
- authenticated user is the name received via the basic
- authentication mechanism.
- 'digest': When a client performs an operation whose target is the
- associated URI, the Printer object challenges the client with HTTP
- digest authentication [RFC2617]. The Printer object assumes that
- the authenticated user is the name received via the digest
- authentication mechanism.
- 'certificate': When a client performs an operation whose target is
- the associated URI, the Printer object expects the client to
- provide a certificate. The Printer object assumes that the
- authenticated user is the textual name contained within the
- certificate.
-
-4.4.3 uri-security-supported (1setOf type2 keyword)
-
-This REQUIRED Printer attribute MUST have the same cardinality (contain
-the same number of values) as the "printer-uri-supported" attribute.
-This attribute identifies the security mechanisms used for each URI
-listed in the "printer-uri-supported" attribute. The "i th" value in
-"uri-security-supported" corresponds to the "i th" value in "printer-
-uri-supported" and it describes the security mechanisms used for
-accessing the Printer object via that URI. See [IPP-PRO] for more
-details on security mechanisms.
-
-The following standard keyword values are defined:
-
- 'none': There are no secure communication channel protocols in use
- for the given URI.
- 'ssl3': SSL3 [SSL] is the secure communications channel protocol in
- use for the given URI.
- 'tls': TLS [RFC2246] is the secure communications channel protocol
- in use for the given URI.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 113]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-This attribute is orthogonal to the definition of a Client
-Authentication mechanism. Specifically, 'none' does not exclude Client
-Authentication. See section 4.4.2.
-
-Consider the following example. For a single Printer object, an
-administrator configures the "printer-uri-supported", "uri-
-authentication-supported" and "uri-security-supported" attributes as
-follows:
-
- "printer-uri-supported": 'xxx://acme.com/open-use-printer',
- 'xxx://acme.com/restricted-use-printer', 'xxx://acme.com/private-
- printer'
- "uri-authentication-supported": 'none', 'digest', 'basic'
- "uri-security-supported": 'none', 'none', 'tls'
-
-
-Note: 'xxx' is not a valid scheme. See the IPP/1.1 "Transport and
-Encoding" document [IPP-PRO] for the actual URI schemes to be used in
-object target attributes.
-
-In this case, one Printer object has three URIs.
-
- - For the first URI, 'xxx://acme.com/open-use-printer', the value
- 'none' in "uri-security-supported" indicates that there is no
- secure channel protocol configured to run under HTTP. The value of
- 'none' in "uri-authentication-supported" indicates that all users
- are 'anonymous'. There will be no challenge and the Printer will
- ignore "requesting-user-name".
- - For the second URI, 'xxx://acme.com/restricted-use-printer', the
- value 'none' in "uri-security-supported" indicates that there is no
- secure channel protocol configured to run under HTTP. The value of
- 'digest' in "uri-authentication-supported" indicates that the
- Printer will issue a challenge and that the Printer will use the
- name supplied by the digest mechanism to determine the
- authenticated user (see section 8.3).
- - For the third URI, 'xxx://acme.com/private-printer', the value
- 'tls' in "uri-security-supported" indicates that TLS is being used
- to secure the channel. The client SHOULD be prepared to use TLS
- framing to negotiate an acceptable ciphersuite to use while
- communicating with the Printer object. In this case, the name
- implies the use of a secure communications channel, but the fact is
- made explicit by the presence of the 'tls' value in "uri-security-
- supported". The client does not need to resort to understanding
- which security it must use by following naming conventions or by
- parsing the URI to determine which security mechanisms are implied.
- The value of 'basic' in "uri-authentication-supported" indicates
- that the Printer will issue a challenge and that the Printer will
- use the name supplied by the digest mechanism to determine the
- authenticated user (see section 8.3) . Because this challenge
- occurs in a tls session, the channel is secure.
-
-
-It is expected that many IPP Printer objects will be configured to
-support only one channel (either configured to use TLS access or not)
-and only one authentication mechanism. Such Printer objects only have
-one URI listed in the "printer-uri-supported" attribute. No matter the
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 114]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-configuration of the Printer object (whether it has only one URI or more
-than one URI), a client MUST supply only one URI in the target "printer-
-uri" operation attribute.
-
-
-4.4.4 printer-name (name(127))
-
-This REQUIRED Printer attribute contains the name of the Printer object.
-It is a name that is more end-user friendly than a URI. An administrator
-determines a printer's name and sets this attribute to that name. This
-name may be the last part of the printer's URI or it may be unrelated.
-In non-US-English locales, a name may contain characters that are not
-allowed in a URI.
-
-
-4.4.5 printer-location (text(127))
-
-This Printer attribute identifies the location of the device. This could
-include things like: "in Room 123A, second floor of building XYZ".
-
-
-4.4.6 printer-info (text(127))
-
-This Printer attribute identifies the descriptive information about this
-Printer object. This could include things like: "This printer can be
-used for printing color transparencies for HR presentations", or "Out of
-courtesy for others, please print only small (1-5 page) jobs at this
-printer", or even "This printer is going away on July 1, 1997, please
-find a new printer".
-
-
-4.4.7 printer-more-info (uri)
-
-This Printer attribute contains a URI used to obtain more information
-about this specific Printer object. For example, this could be an HTTP
-type URI referencing an HTML page accessible to a Web Browser. The
-information obtained from this URI is intended for end user consumption.
-Features outside the scope of IPP can be accessed from this URI. The
-information is intended to be specific to this printer instance and site
-specific services (e.g. job pricing, services offered, end user
-assistance). The device manufacturer may initially populate this
-attribute.
-
-
-4.4.8 printer-driver-installer (uri)
-
-This Printer attribute contains a URI to use to locate the driver
-installer for this Printer object. This attribute is intended for
-consumption by automata. The mechanics of print driver installation is
-outside the scope of this IPP/1.1 document. The device manufacturer may
-initially populate this attribute.
-
-
-4.4.9 printer-make-and-model (text(127))
-
-This Printer attribute identifies the make and model of the device. The
-device manufacturer may initially populate this attribute.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 115]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.4.10 printer-more-info-manufacturer (uri)
-
-This Printer attribute contains a URI used to obtain more information
-about this type of device. The information obtained from this URI is
-intended for end user consumption. Features outside the scope of IPP
-can be accessed from this URI (e.g., latest firmware, upgrades, print
-drivers, optional features available, details on color support). The
-information is intended to be germane to this printer without regard to
-site specific modifications or services. The device manufacturer may
-initially populate this attribute.
-
-
-4.4.11 printer-state (type1 enum)
-
-This REQUIRED Printer attribute identifies the current state of the
-device. The "printer-state reasons" attribute augments the "printer-
-state" attribute to give more detailed information about the Printer in
-the given printer state.
-
-A Printer object need only update this attribute before responding to an
-operation which requests the attribute; the Printer object NEED NOT
-update this attribute continually, since asynchronous event notification
-is not part of IPP/1.1. A Printer NEED NOT implement all values if they
-are not applicable to a given implementation.
-
-The following standard enum values are defined:
-
- Value Symbolic Name and Description
-
- '3' 'idle': Indicates that new jobs can start processing without
- waiting.
- '4' 'processing': Indicates that jobs are processing; new jobs
- will wait before processing.
- '5' 'stopped': Indicates that no jobs can be processed and
- intervention is required.
-
-Values of "printer-state-reasons", such as 'spool-area-full' and
-'stopped-partly', MAY be used to provide further information.
-
-
-4.4.12 printer-state-reasons (1setOf type2 keyword)
-
-This REQUIRED Printer attribute supplies additional detail about the
-device's state. Some of the these value definitions indicate
-conformance requirements; the rest are OPTIONAL.
-
-Each keyword value MAY have a suffix to indicate its level of severity.
-The three levels are: report (least severe), warning, and error (most
-severe).
-
- - '-report': This suffix indicates that the reason is a "report". An
- implementation may choose to omit some or all reports. Some reports
- specify finer granularity about the printer state; others serve as
- a precursor to a warning. A report MUST contain nothing that could
- affect the printed output.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 116]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- - '-warning': This suffix indicates that the reason is a "warning".
- An implementation may choose to omit some or all warnings. Warnings
- serve as a precursor to an error. A warning MUST contain nothing
- that prevents a job from completing, though in some cases the
- output may be of lower quality.
- - '-error': This suffix indicates that the reason is an "error". An
- implementation MUST include all errors. If this attribute contains
- one or more errors, printer MUST be in the stopped state.
-
-
-If the implementation does not add any one of the three suffixes, all
-parties MUST assume that the reason is an "error".
-
-If a Printer object controls more than one output device, each value of
-this attribute MAY apply to one or more of the output devices. An error
-on one output device that does not stop the Printer object as a whole
-MAY appear as a warning in the Printer's "printer-state-reasons
-attribute". If the "printer-state" for such a Printer has a value of
-'stopped', then there MUST be an error reason among the values in the
-"printer-state-reasons" attribute.
-
-The following standard keyword values are defined:
-
- 'other': The device has detected an error other than one listed in
- this document.
- 'none': There are not reasons. This state reason is semantically
- equivalent to "printer-state-reasons" without any value and MUST be
- used, since the 1setOf attribute syntax requires at least one
- value.
- 'media-needed': A tray has run out of media.
- 'media-jam': The device has a media jam.
- 'moving-to-paused': Someone has paused the Printer object using the
- Pause-Printer operation (see section 3.2.7) or other means, but the
- device(s) are taking an appreciable time to stop. Later, when all
- output has stopped, the "printer-state" becomes 'stopped', and the
- 'paused' value replaces the 'moving-to-paused' value in the
- "printer-state-reasons" attribute. This value MUST be supported,
- if the Pause-Printer operation is supported and the implementation
- takes significant time to pause a device in certain circumstances.
- 'paused': Someone has paused the Printer object using the Pause-
- Printer operation (see section 3.2.7) or other means and the
- Printer object's "printer-state" is 'stopped'. In this state, a
- Printer MUST NOT produce printed output, but it MUST perform other
- operations requested by a client. If a Printer had been printing a
- job when the Printer was paused, the Printer MUST resume printing
- that job when the Printer is no longer paused and leave no evidence
- in the printed output of such a pause. This value MUST be
- supported, if the Pause-Printer operation is supported.
- 'shutdown': Someone has removed a Printer object from service, and
- the device may be powered down or physically removed. In this
- state, a Printer object MUST NOT produce printed output, and unless
- the Printer object is realized by a print server that is still
- active, the Printer object MUST perform no other operations
- requested by a client, including returning this value. If a Printer
- object had been printing a job when it was shutdown, the Printer
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 117]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- NEED NOT resume printing that job when the Printer is no longer
- shutdown. If the Printer resumes printing such a job, it may leave
- evidence in the printed output of such a shutdown, e.g. the part
- printed before the shutdown may be printed a second time after the
- shutdown.
- 'connecting-to-device': The Printer object has scheduled a job on the
- output device and is in the process of connecting to a shared
- network output device (and might not be able to actually start
- printing the job for an arbitrarily long time depending on the
- usage of the output device by other servers on the network).
- 'timed-out': The server was able to connect to the output device (or
- is always connected), but was unable to get a response from the
- output device.
- 'stopping': The Printer object is in the process of stopping the
- device and will be stopped in a while. When the device is stopped,
- the Printer object will change the Printer object's state to
- 'stopped'. The 'stopping-warning' reason is never an error, even
- for a Printer with a single output device. When an output-device
- ceases accepting jobs, the Printer will have this reason while the
- output device completes printing.
- 'stopped-partly': When a Printer object controls more than one output
- device, this reason indicates that one or more output devices are
- stopped. If the reason is a report, fewer than half of the output
- devices are stopped. If the reason is a warning, fewer than all of
- the output devices are stopped.
- 'toner-low': The device is low on toner.
- 'toner-empty': The device is out of toner.
- 'spool-area-full': The limit of persistent storage allocated for
- spooling has been reached. The Printer is temporarily unable to
- accept more jobs. The Printer will remove this value when it is
- able to accept more jobs. This value SHOULD be used by a non-
- spooling Printer that only accepts one or a small number jobs at a
- time or a spooling Printer that has filled the spool space.
- 'cover-open': One or more covers on the device are open.
- 'interlock-open': One or more interlock devices on the printer are
- unlocked.
- 'door-open': One or more doors on the device are open.
- 'input-tray-missing': One or more input trays are not in the device.
- 'media-low': At least one input tray is low on media.
- 'media-empty': At least one input tray is empty.
- 'output-tray-missing': One or more output trays are not in the device
- 'output-area-almost-full': One or more output area is almost full
- (e.g. tray, stacker, collator).
- 'output-area-full': One or more output area is full. (e.g. tray,
- stacker, collator)
- 'marker-supply-low': The device is low on at least one marker supply.
- (e.g. toner, ink, ribbon)
- 'marker-supply-empty: The device is out of at least one marker
- supply. (e.g. toner, ink, ribbon)
- 'marker-waste-almost-full': The device marker supply waste receptacle
- is almost full.
- 'marker-waste-full': The device marker supply waste receptacle is
- full.
- 'fuser-over-temp': The fuser temperature is above normal.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 118]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'fuser-under-temp': The fuser temperature is below normal.
- 'opc-near-eol': The optical photo conductor is near end of life.
- 'opc-life-over': The optical photo conductor is no longer
- functioning.
- 'developer-low': The device is low on developer.
- 'developer-empty: The device is out of developer.
- 'interpreter-resource-unavailable': An interpreter resource is
- unavailable (i.e. font, form)
-
-
-
-4.4.13 printer-state-message (text(MAX))
-
-This Printer attribute specifies information about the "printer-state"
-and "printer-state-reasons" attributes in human readable text. If the
-Printer object supports this attribute, the Printer object MUST be able
-to generate this message in any of the natural languages identified by
-the Printer's "generated-natural-language-supported" attribute (see the
-"attributes-natural-language" operation attribute specified in Section
-3.1.4.1).
-
-
-4.4.14 ipp-versions-supported (1setOf type2 keyword)
-
-This REQUIRED attribute identifies the IPP protocol version(s) that this
-Printer supports, including major and minor versions, i.e., the version
-numbers for which this Printer implementation meets the conformance
-requirements. For version number validation, the Printer matches the
-(two-octet binary) "version-number" parameter supplied by the client in
-each request (see sections 3.1.1 and 3.1.8) with the (US-ASCII) keyword
-values of this attribute.
-
-The following standard keyword values are defined:
-
- '1.0': Meets the conformance requirement of IPP version 1.0 as
- specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565] including
- any extensions registered according to Section 6 and any extension
- defined in this version or any future version of the IPP "Model and
- Semantics" document or the IPP "Encoding and Transport" document
- following the rules, if any, when the "version-number" parameter is
- '1.0'.
- '1.1': Meets the conformance requirement of IPP version 1.1 as
- specified in this document and [IPP-PRO] including any extensions
- registered according to Section 6 and any extension defined in any
- future versions of the IPP "Model and Semantics" document or the
- IPP Encoding and Transport document following the rules, if any,
- when the "version-number" parameter is '1.1'.
-
-4.4.15 operations-supported (1setOf type2 enum)
-
-This REQUIRED Printer attribute specifies the set of supported
-operations for this Printer object and contained Job objects.
-
-This attribute is encoded as any other enum attribute syntax according
-to [IPP-PRO] as 32-bits. However, all 32-bit enum values for this
-attribute MUST NOT exceed 0x00008FFF, since these same values are also
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 119]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-passed in two octets in the "operation-id" parameter (see section 3.1.1)
-in each Protocol request with the two high order octets omitted in order
-to indicate the operation being performed [IPP-PRO].
-
-The following standard enum and "operation-id" (see section 3.1.2)
-values are defined:
-
- Value Operation Name
- ----------------- -------------------------------------
-
- 0x0000 reserved, not used
- 0x0001 reserved, not used
- 0x0002 Print-Job
- 0x0003 Print-URI
- 0x0004 Validate-Job
- 0x0005 Create-Job
- 0x0006 Send-Document
- 0x0007 Send-URI
- 0x0008 Cancel-Job
- 0x0009 Get-Job-Attributes
- 0x000A Get-Jobs
- 0x000B Get-Printer-Attributes
- 0x000C Hold-Job
- 0x000D Release-Job
- 0x000E Restart-Job
- 0x000F reserved for a future operation
- 0x0010 Pause-Printer
- 0x0011 Resume-Printer
- 0x0012 Purge-Jobs
- 0x0013-0x3FFF reserved for future IETF standards track
- operations (see section 6.4)
- 0x4000-0x8FFF reserved for vendor extensions (see section 6.4)
-
-
-4.4.16 multiple-document-jobs-supported (boolean)
-
-This Printer attribute indicates whether or not the Printer supports
-more than one document per job, i.e., more than one Send-Document or
-Send-Data operation with document data. If the Printer supports the
-Create-Job and Send-Document operations (see section 3.2.4 and 3.3.1),
-it MUST support this attribute.
-
-
-4.4.17 charset-configured (charset)
-
-This REQUIRED Printer attribute identifies the charset that the Printer
-object has been configured to represent 'text' and 'name' Printer
-attributes that are set by the operator, system administrator, or
-manufacturer, i.e., for "printer-name" (name), "printer-location"
-(text), "printer-info" (text), and "printer-make-and-model" (text).
-Therefore, the value of the Printer object's "charset-configured"
-attribute MUST also be among the values of the Printer object's
-"charset-supported" attribute.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 120]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.4.18 charset-supported (1setOf charset)
-
-This REQUIRED Printer attribute identifies the set of charsets that the
-Printer and contained Job objects support in attributes with attribute
-syntax 'text' and 'name'. At least the value 'utf-8' MUST be present,
-since IPP objects MUST support the UTF-8 [RFC2279] charset. If a
-Printer object supports a charset, it means that for all attributes of
-syntax 'text' and 'name' the IPP object MUST (1) accept the charset in
-requests and return the charset in responses as needed.
-
-If more charsets than UTF-8 are supported, the IPP object MUST perform
-charset conversion between the charsets as described in Section 3.1.4.2.
-
-
-4.4.19 natural-language-configured (naturalLanguage)
-
-This REQUIRED Printer attribute identifies the natural language that the
-Printer object has been configured to represent 'text' and 'name'
-Printer attributes that are set by the operator, system administrator,
-or manufacturer, i.e., for "printer-name" (name), "printer-location"
-(text), "printer-info" (text), and "printer-make-and-model" (text).
-When returning these Printer attributes, the Printer object MAY return
-them in the configured natural language specified by this attribute,
-instead of the natural language requested by the client in the
-"attributes-natural-language" operation attribute. See Section 3.1.4.1
-for the specification of the OPTIONAL multiple natural language support.
-Therefore, the value of the Printer object's "natural-language-
-configured" attribute MUST also be among the values of the Printer
-object's "generated-natural-language-supported" attribute.
-
-
-4.4.20 generated-natural-language-supported (1setOf naturalLanguage)
-
-This REQUIRED Printer attribute identifies the natural language(s) that
-the Printer object and contained Job objects support in attributes with
-attribute syntax 'text' and 'name'. The natural language(s) supported
-depends on implementation and/or configuration. Unlike charsets, IPP
-objects MUST accept requests with any natural language or any Natural
-Language Override whether the natural language is supported or not.
-
-If a Printer object supports a natural language, it means that for any
-of the attributes for which the Printer or Job object generates
-messages, i.e., for the "job-state-message" and "printer-state-message"
-attributes and Operation Messages (see Section 3.1.5) in operation
-responses, the Printer and Job objects MUST be able to generate messages
-in any of the Printer's supported natural languages. See section 3.1.4
-for the definition of 'text' and 'name' attributes in operation requests
-and responses.
-
-Note: A Printer object that supports multiple natural languages, often
-has separate catalogs of messages, one for each natural language
-supported.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 121]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.4.21 document-format-default (mimeMediaType)
-
-This REQUIRED Printer attribute identifies the document format that the
-Printer object has been configured to assume if the client does not
-supply a "document-format" operation attribute in any of the operation
-requests that supply document data. The standard values for this
-attribute are Internet Media types (sometimes called MIME types). For
-further details see the description of the 'mimeMediaType' attribute
-syntax in Section 4.1.9.
-
-
-4.4.22 document-format-supported (1setOf mimeMediaType)
-
-This REQUIRED Printer attribute identifies the set of document formats
-that the Printer object and contained Job objects can support. For
-further details see the description of the 'mimeMediaType' attribute
-syntax in Section 4.1.9.
-
-
-4.4.23 printer-is-accepting-jobs (boolean)
-
-This REQUIRED Printer attribute indicates whether the printer is
-currently able to accept jobs, i.e., is accepting Print-Job, Print-URI,
-and Create-Job requests. If the value is 'true', the printer is
-accepting jobs. If the value is 'false', the Printer object is
-currently rejecting any jobs submitted to it. In this case, the Printer
-object returns the 'server-error-not-accepting-jobs' status code.
-
-This value is independent of the "printer-state" and "printer-state-
-reasons" attributes because its value does not affect the current job;
-rather it affects future jobs. This attribute, when 'false', causes the
-Printer to reject jobs even when the "printer-state" is 'idle' or, when
-'true', causes the Printer object to accepts jobs even when the
-"printer-state" is 'stopped'.
-
-
-4.4.24 queued-job-count (integer(0:MAX))
-
-This REQUIRED Printer attribute contains a count of the number of jobs
-that are either 'pending', 'processing', 'pending-held', or 'processing-
-stopped' and is set by the Printer object.
-
-
-4.4.25 printer-message-from-operator (text(127))
-
-This Printer attribute provides a message from an operator, system
-administrator or "intelligent" process to indicate to the end user
-information or status of the printer, such as why it is unavailable or
-when it is expected to be available.
-
-
-4.4.26 color-supported (boolean)
-
-This Printer attribute identifies whether the device is capable of any
-type of color printing at all, including highlight color. All document
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 122]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-instructions having to do with color are embedded within the document
-PDL (none are external IPP attributes in IPP/1.1).
-
-Note: end-users are able to determine the nature and details of the
-color support by querying the "printer-more-info-manufacturer" Printer
-attribute.
-
-
-4.4.27 reference-uri-schemes-supported (1setOf uriScheme)
-
-This Printer attribute specifies which URI schemes are supported for use
-in the "document-uri" operation attribute of the Print-URI or Send-URI
-operation. If a Printer object supports these optional operations, it
-MUST support the "reference-uri-schemes-supported" Printer attribute
-with at least the following schemed URI value:
-
- 'ftp': The Printer object will use an FTP 'get' operation as defined
- in RFC 2228 [RFC2228] using FTP URLs as defined by [RFC2396]
- and[RFC2316].
-
-
-The Printer object MAY OPTIONALLY support other URI schemes (see section
-4.1.6).
-
-
-4.4.28 pdl-override-supported (type2 keyword)
-
-This REQUIRED Printer attribute expresses the ability for a particular
-Printer implementation to either attempt to override document data
-instructions with IPP attributes or not.
-
-This attribute takes on the following keyword values:
-
- - 'attempted': This value indicates that the Printer object attempts
- to make the IPP attribute values take precedence over embedded
- instructions in the document data, however there is no guarantee.
- - 'not-attempted': This value indicates that the Printer object makes
- no attempt to make the IPP attribute values take precedence over
- embedded instructions in the document data.
-
-
-Section 15 contains a full description of how this attribute interacts
-with and affects other IPP attributes, especially the "ipp-attribute-
-fidelity" attribute.
-
-
-4.4.29 printer-up-time (integer(1:MAX))
-
-This REQUIRED Printer attribute indicates the amount of time (in
-seconds) that this Printer instance has been up and running. The value
-is a monotonically increasing value starting from 1 when the Printer
-object is started-up (initialized, booted, etc.). This value is used to
-populate the Event Time Job Description Job attributes "time-at-
-creation", "time-at-processing", and "time-at-completed" (see section
-4.3.14).
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 123]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-If the Printer object goes down at some value 'n', and comes back up,
-the implementation MAY:
-
- 1. Know how long it has been down, and resume at some value greater
- than 'n', or
- 2. Restart from 1.
-
-In other words, if the device or devices that the Printer object is
-representing are restarted or power cycled, the Printer object MAY
-continue counting this value or MAY reset this value to 1 depending on
-implementation. However, if the Printer object software ceases running,
-and restarts without knowing the last value for "printer-up-time", the
-implementation MUST reset this value to 1. If this value is reset and
-the Printer has persistent jobs, the Printer MUST reset the "time-at-
-xxx(integer) Event Time Job Description attributes according to Section
-4.3.14. An implementation MAY use both implementation alternatives,
-depending on warm versus cold start, respectively.
-
-
-4.4.30 printer-current-time (dateTime)
-
-This Printer attribute indicates the current date and time. This value
-is used to populate the Event Time Job Description attributes: "time-
-at-creation", "time-at-processing", and "time-at-completed" (see Section
-4.3.14).
-
-The date and time is obtained on a "best efforts basis" and does not
-have to be that precise in order to work in practice. A Printer
-implementation sets the value of this attribute by obtaining the date
-and time via some implementation-dependent means, such as getting the
-value from a network time server, initialization at time of manufacture,
-or setting by an administrator. See [IPP-IIG] for examples. If an
-implementation supports this attribute and the implementation knows that
-it has not yet been set, then the implementation MUST return the value
-of this attribute using the out-of-band 'no-value' meaning not
-configured. See the beginning of section 4.1.
-
-The time zone of this attribute NEED NOT be the time zone used by people
-located near the Printer object or device. The client MUST NOT expect
-that the time zone of any received 'dateTime' value to be in the time
-zone of the client or in the time zone of the people located near the
-printer.
-
-The client SHOULD display any dateTime attributes to the user in client
-local time by converting the 'dateTime' value returned by the server to
-the time zone of the client, rather than using the time zone returned by
-the Printer in attributes that use the 'dateTime' attribute syntax.
-
-
-4.4.31 multiple-operation-time-out (integer(1:MAX))
-
-This Printer attributes identifies the minimum time (in seconds) that
-the Printer object waits for additional Send-Document or Send-URI
-operations to follow a still-open Job object before taking any recovery
-actions, such as the ones indicated in section 3.3.1. If the Printer
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 124]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-object supports the Create-Job and Send-Document operations (see section
-3.2.4 and 3.3.1), it MUST support this attribute.
-
-It is RECOMMENDED that vendors supply a value for this attribute that is
-between 60 and 240 seconds. An implementation MAY allow a system
-administrator to set this attribute (by means outside this IPP/1.1
-document). If so, the system administrator MAY be able to set values
-outside this range.
-
-
-4.4.32 compression-supported (1setOf type3 keyword)
-
-This REQUIRED Printer attribute identifies the set of supported
-compression algorithms for document data. Compression only applies to
-the document data; compression does not apply to the encoding of the IPP
-operation itself. The supported values are used to validate the client
-supplied "compression" operation attributes in Print-Job, Send-Document,
-and Send-URI requests.
-
-Standard keyword values are :
-
- 'none': no compression is used.
- 'deflate': ZIP public domain inflate/deflate) compression technology
- [RFC1951]
- 'gzip' GNU zip compression technology described in RFC 1952
- [RFC1952].
- 'compress': UNIX compression technology [RFC1977]
-
-
-4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX))
-
-This Printer attribute specifies the upper and lower bounds of total
-sizes of jobs in K octets, i.e., in units of 1024 octets. The supported
-values are used to validate the client supplied "job-k-octets" operation
-attributes in create requests. The corresponding job description
-attribute "job-k-octets" is defined in section 4.3.17.1.
-
-
-4.4.34 job-impressions-supported (rangeOfInteger(0:MAX))
-
-This Printer attribute specifies the upper and lower bounds for the
-number of impressions per job. The supported values are used to validate
-the client supplied "job-impressions" operation attributes in create
-requests. The corresponding job description attribute "job-impressions"
-is defined in section 4.3.17.2.
-
-
-4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX))
-
-This Printer attribute specifies the upper and lower bounds for the
-number of media sheets per job. The supported values are used to
-validate the client supplied "job-media-sheets" operation attributes in
-create requests. The corresponding Job attribute "job-media-sheets" is
-defined in section 4.3.17.3.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 125]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-4.4.36 pages-per-minute (integer(0:MAX))
-
-This Printer attributes specifies the nominal number of pages per minute
-to the nearest whole number which may be generated by this printer
-(e.g., simplex, black-and-white). This attribute is informative, not a
-service guarantee. Generally, it is the value used in the marketing
-literature to describe the device.
-
-A value of 0 indicates a device that takes more than two minutes to
-process a page.
-
-
-4.4.37 pages-per-minute-color (integer(0:MAX))
-
-This Printer attributes specifies the nominal number of pages per minute
-to the nearest whole number which may be generated by this printer when
-printing color (e.g., simplex, color). For purposes of this attribute,
-"color" means the same as for the "color-supported" attribute, namely,
-the device is capable of any type of color printing at all, including
-highlight color. This attribute is informative, not a service
-guarantee. Generally, it is the value used in the marketing literature
-to describe the color capabilities of this device.
-
-A value of 0 indicates a device that takes more than two minutes to
-process a page.
-
-If a color device has several color modes, it MAY use the pages-per-
-minute value for this attribute that corresponds to the mode that
-produces the highest number.
-
-Black and white only printers MUST NOT support this attribute. If this
-attribute is present, then the "color-supported" Printer description
-attribute MUST be present and have a 'true' value.
-
-The values of these two attributes returned by the Get-Printer-
-Attributes operation MAY be affected by the "document-format" attribute
-supplied by the client in the Get-Printer-Attributes request. In other
-words, the implementation MAY have different speeds depending on the
-document format being processed. See section 3.2.5.1 Get-Printer-
-Attributes.
-
-
-
-5. Conformance
-
-
-This section describes conformance issues and requirements. This
-document introduces model entities such as objects, operations,
-attributes, attribute syntaxes, and attribute values. These conformance
-sections describe the conformance requirements which apply to these
-model entities.
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 126]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-5.1 Client Conformance Requirements
-
-
-This section describes the conformance requirements for a client (see
-section 2.1), whether it be:
-
- 1. contained within software controlled by an end user, e.g. activated
- by the "Print" menu item in an application that sends IPP requests
- or
-
- 2. the print server component that sends IPP requests to either an
- output device or another "downstream" print server.
-
-A conforming client MUST support all REQUIRED operations as defined in
-this document. For each attribute included in an operation request, a
-conforming client MUST supply a value whose type and value syntax
-conforms to the requirements of the Model document as specified in
-Sections 3 and 4. A conforming client MAY supply any IETF standards
-track extensions and/or vendor extensions in an operation request, as
-long as the extensions meet the requirements in Section 6.
-
-Otherwise, there are no conformance requirements placed on the user
-interfaces provided by IPP clients or their applications. For example,
-one application might not allow an end user to submit multiple documents
-per job, while another does. One application might first query a
-Printer object in order to supply a graphical user interface (GUI)
-dialogue box with supported and default values whereas a different
-implementation might not.
-
-When sending a request, an IPP client NEED NOT supply any attributes
-that are indicated as OPTIONALLY supplied by the client.
-
-A client MUST be able to accept any of the attribute syntaxes defined in
-Section 4.1, including their full range, that may be returned to it in a
-response from a Printer object. In particular for each attribute that
-the client supports whose attribute syntax is 'text', the client MUST
-accept and process both the 'textWithoutLanguage' and 'textWithLanguage'
-forms. Similarly, for each attribute that the client supports whose
-attribute syntax is 'name', the client MUST accept and process both the
-'nameWithoutLanguage' and 'nameWithLanguage' forms. For presentation
-purposes, truncation of long attribute values is not recommended. A
-recommended approach would be for the client implementation to allow the
-user to scroll through long attribute values.
-
-A response MAY contain attribute groups, attributes, attribute syntaxes,
-values, and status codes that the client does not expect. Therefore, a
-client implementation MUST gracefully handle such responses and not
-refuse to inter-operate with a conforming Printer that is returning IETF
-standards track extension or vendor extensions, including attribute
-groups, attributes, attribute syntaxes, attribute values, status codes,
-and out-of-band attribute values that conform to Section 6. Clients may
-choose to ignore any parameters, attributes, attribute syntaxes, or
-values that they do not understand.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 127]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-While a client is sending data to a printer, it SHOULD do its best to
-prevent a channel from being closed by a lower layer when the channel is
-blocked (i.e. flow-controlled off) for whatever reason, e.g. 'out of
-paper' or 'job ahead hasn't freed up enough memory'. However, the layer
-that launched the print submission (e.g. an end user) MAY close the
-channel in order to cancel the job. When a client closes a channel, a
-Printer MAY print all or part of the received portion of the document.
-See the "Encoding and Transport" document [IPP-PRO] for more details.
-
-A client MUST support Client Authentication as defined in the IPP/1.1
-Encoding and Transport document [IPP-PRO]. A client SHOULD support
-Operation Privacy and Server Authentication as defined in the IPP/1.1
-Encoding and Transport document [IPP-PRO]. See also section 8 of this
-document.
-
-
-5.2 IPP Object Conformance Requirements
-
-
-This section specifies the conformance requirements for conforming
-implementations of IPP objects (see section 2). These requirements
-apply to an IPP object whether it is:
-
- (1) an (embedded) device component that accepts IPP requests and
- controls the device or
-
- (2) a component of a print server that accepts IPP requests (where
- the print server control one or more networked devices using IPP or
- other protocols).
-
-
-5.2.1 Objects
-
-Conforming implementations MUST implement all of the model objects as
-defined in this document in the indicated sections:
-
- Section 2.1 - Printer Object
- Section 2.2 - Job Object
-
-5.2.2 Operations
-
-Conforming IPP object implementations MUST implement all of the REQUIRED
-model operations, including REQUIRED responses, as defined in this
-document in the indicated sections:
-
- For a Printer object:
- Print-Job (section 3.2.1) REQUIRED
- Print-URI (section 3.2.2) OPTIONAL
- Validate-Job (section 3.2.3) REQUIRED
- Create-Job (section 3.2.4) OPTIONAL
- Get-Printer-Attributes (section 3.2.5) REQUIRED
- Get-Jobs (section 3.2.6) REQUIRED
- Pause-Printer (section 3.2.7) OPTIONAL
- Resume-Printer (section 3.2.8) OPTIONAL
- Purge-Jobs (section 3.2.9) OPTIONAL
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 128]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- For a Job object:
- Send-Document (section 3.3.1) OPTIONAL
- Send-URI (section 3.3.2) OPTIONAL
- Cancel-Job (section 3.3.3) REQUIRED
- Get-Job-Attributes (section 3.3.4) REQUIRED
- Hold-Job (section 3.3.5) OPTIONAL
- Release-Job (section 3.3.6) OPTIONAL
- Restart-Job (section 3.3.7) OPTIONAL
-
-
-Conforming IPP objects MUST support all REQUIRED operation attributes
-and all values of such attributes if so indicated in the description.
-Conforming IPP objects MUST ignore all unsupported or unknown operation
-attributes or operation attribute groups received in a request, but MUST
-reject a request that contains a supported operation attribute that
-contains an unsupported value.
-
-Conforming IPP objects MAY return operation responses that contain
-attributes groups, attributes names, attribute syntaxes, attribute
-values, and status codes that are extensions to this standard. The
-additional attribute groups MAY occur in any order.
-
-The following section on object attributes specifies the support
-required for object attributes.
-
-
-5.2.3 IPP Object Attributes
-
-Conforming IPP objects MUST support all of the REQUIRED object
-attributes, as defined in this document in the indicated sections.
-
-If an object supports an attribute, it MUST support only those values
-specified in this document or through the extension mechanism described
-in section 5.2.4. It MAY support any non-empty subset of these values.
-That is, it MUST support at least one of the specified values and at
-most all of them.
-
-
-5.2.4 Versions
-
-IPP/1.1 clients MUST meet the conformance requirements for clients
-specified in this document and [IPP-PRO]. IPP/1.1 clients MUST send
-requests containing a "version-number" parameter with a '1.1' value.
-
-IPP/1.1 Printer and Job objects MUST meet the conformance requirements
-for IPP objects specified in this document and [IPP-PRO]. IPP/1.1
-objects MUST accept requests containing a "version-number" parameter
-with a '1.1' value (or reject the request if the operation is not
-supported).
-
-It is beyond the scope of this specification to mandate conformance with
-previous versions. IPP/1.1 was deliberately designed, however, to make
-supporting previous versions easy. It is worth noting that, at the time
-of composing this specification (1999), we would expect IPP/1.1 Printer
-implementations to:
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 129]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- understand any valid request in the format of IPP/1.0, or 1.1;
-
- respond appropriately with a response containing the same "version-
- number" parameter value used by the client in the request.
-
-And we would expect IPP/1.1 clients to:
-
- understand any valid response in the format of IPP/1.0, or 1.1.
-
-It is recommended that IPP/1.1 clients try supplying alternate version
-numbers if they receive a 'server-error-version-not-supported' error
-return in a response.
-
-
-5.2.5 Extensions
-
-A conforming IPP object MAY support IETF standards track extensions and
-vendor extensions, as long as the extensions meet the requirements
-specified in Section 6.
-
-For each attribute included in an operation response, a conforming IPP
-object MUST return a value whose type and value syntax conforms to the
-requirement of the Model document as specified in Sections 3 and 4.
-
-
-5.2.6 Attribute Syntaxes
-
-An IPP object MUST be able to accept any of the attribute syntaxes
-defined in Section 4.1, including their full range, in any operation in
-which a client may supply attributes or the system administrator may
-configure attributes (by means outside the scope of this IPP/1.1
-document). In particular for each attribute that the IPP object
-supports whose attribute syntax is 'text', the IPP object MUST accept
-and process both the 'textWithoutLanguage' and 'textWithLanguage' forms.
-Similarly, for each attribute that the IPP object supports whose
-attribute syntax is 'name', the IPP object MUST accept and process both
-the 'nameWithoutLanguage' and 'nameWithLanguage' forms. Furthermore, an
-IPP object MUST return attributes to the client in operation responses
-that conform to the syntax specified in Section 4.1, including their
-full range if supplied previously by a client.
-
-
-5.2.7 Security
-
-An IPP Printer implementation SHOULD contain support for Client
-Authentication as defined in the IPP/1.1 Encoding and Transport document
-[IPP-PRO]. A Printer implementation MAY allow an administrator to
-configure the Printer so that all, some, or none of the users are
-authenticated. See also section 8 of this document.
-
-An IPP Printer implementation SHOULD contain support for Operation
-Privacy and Server Authentication as defined in the IPP/1.1 Encoding and
-Transport document [IPP-PRO]. A Printer implementation MAY allow an
-administrator to configure the degree of support for Operation Privacy
-and Server Authentication. See also section 8 of this document.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 130]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Security MUST NOT be compromised when a client supplies a lower
-"version-number" parameter in a request. For example, if an IPP/1.1
-conforming Printer object accepts version '1.0' requests and is
-configured to enforce Digest Authentication, it MUST do the same for a
-version '1.0' request.
-
-
-5.3 Charset and Natural Language Requirements
-
-
-All clients and IPP objects MUST support the 'utf-8' charset as defined
-in section 4.1.7.
-
-IPP objects MUST be able to accept any client request which correctly
-uses the "attributes-natural-language" operation attribute or the
-Natural Language Override mechanism on any individual attribute whether
-or not the natural language is supported by the IPP object. If an IPP
-object supports a natural language, then it MUST be able to translate
-(perhaps by table lookup) all generated 'text' or 'name' attribute
-values into one of the supported languages (see section 3.1.4). That
-is, the IPP object that supports a natural language NEED NOT be a
-general purpose translator of any arbitrary 'text' or 'name' value
-supplied by the client into that natural language. However, the object
-MUST be able to translate (automatically generate) any of its own
-attribute values and messages into that natural language.
-
-
-
-6. IANA Considerations
-
-
-This section describes the procedures for defining semantics for the
-following IETF standards track extensions and vendor extensions to the
-IPP/1.1 Model and Semantics document:
-
- 1. keyword attribute values
- 2. enum attribute values
- 3. attributes
- 4. attribute syntaxes
- 5. operations
- 6. attribute groups
- 7. status codes
- 8. out-of-band attribute values
-
-
-Extensions registered for use with IPP/1.1 are OPTIONAL for client and
-IPP object conformance to the IPP/1.1 "Model and Semantics" document
-(this document).
-
-These extension procedures are aligned with the guidelines as set forth
-by the IESG [IANA-CON]. Section 11 describes how to propose new
-registrations for consideration. IANA will reject registration
-proposals that leave out required information or do not follow the
-appropriate format described in Section 11. The IPP/1.1 Model and
-Semantics document may also be extended by an appropriate RFC that
-specifies any of the above extensions.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 131]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-6.1 Typed 'keyword' and 'enum' Extensions
-
-
-IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3 and
-4.1.4). This document uses prefixes to the 'keyword' and 'enum' basic
-attribute syntax type in order to communicate extra information to the
-reader through its name. This extra information is not represented in
-the protocol because it is unimportant to a client or Printer object.
-The list below describes the prefixes and their meaning.
-
- "type1": This IPP specification document must be revised (or another
- IETF standards track document which augments this document) to add
- a new keyword or a new enum. No vendor defined keywords or enums
- are allowed.
-
- "type2": Implementers can, at any time, add new keyword or enum
- values by proposing the complete specification to IANA:
-
- iana@iana.org
-
- IANA will forward the registration proposal to the IPP Designated
- Expert who will review the proposal with a mailing list that the
- Designated Expert keeps for this purpose. Initially, that list
- will be the mailing list used by the IPP WG:
-
- ipp@pwg.org
-
- even after the IPP WG is disbanded as permitted by [IANA-CON]. The
- IPP Designated Expert is appointed by the IESG Area Director
- responsible for IPP, according to [IANA-CON].
-
- When a type2 keyword or enum is approved, the IPP Designated Expert
- becomes the point of contact for any future maintenance that might
- be required for that registration.
-
- "type3": Implementers can, at any time, add new keyword and enum
- values by submitting the complete specification to IANA as for
- type2 who will forward the proposal to the IPP Designated Expert.
- While no additional technical review is required, the IPP
- Designated Expert may, at his/her discretion, forward the proposal
- to the same mailing list as for type2 registrations for advice and
- comment.
-
- When a type3 keyword or enum is approved by the IPP Designated
- Expert, the original proposer becomes the point of contact for any
- future maintenance that might be required for that registration.
-
-
-For type2 and type3 keywords, the proposer includes the name of the
-keyword in the registration proposal and the name is part of the
-technical review.
-
-After type2 and type3 enums specifications are approved, the IPP
-Designated Expert in consultation with IANA assigns the next available
-enum number for each enum value.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 132]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-IANA will publish approved type2 and type3 keyword and enum attributes
-value registration specifications in:
-
- ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
-
-where xxx is the attribute name that specifies the initial values and
-yyy.txt is a descriptive file name that contains one or more enums or
-keywords approved at the same time. For example, if several additional
-enums for stapling are approved for use with the "finishings" attribute
-(and "finishings-default" and "finishings-supported" attributes), IANA
-will publish the additional values in the file:
-
- ftp.isi.edu/iana/assignments/ipp/attribute-
- values/finishings/stapling.txt
-
-Note: Some attributes are defined to be: 'type3 keywords' | 'name' which
-allows for attribute values to be extended by a site administrator with
-administrator defined names. Such names are not registered with IANA.
-
-By definition, each of the three types above assert some sort of
-registry or review process in order for extensions to be considered
-valid. Each higher numbered level (1, 2, 3) tends to be decreasingly
-less stringent than the previous level. Therefore, any typeN value MAY
-be registered using a process for some typeM where M is less than N,
-however such registration is NOT REQUIRED. For example, a type3 value
-MAY be registered in a type 1 manner (by being included in a future
-version of an IPP specification), however, it is NOT REQUIRED.
-
-This document defines keyword and enum values for all of the above
-types, including type3 keywords.
-
-For vendor keyword extensions, implementers SHOULD use keywords with a
-suitable distinguishing prefix, such as "xxx-" where xxx follows the
-syntax rules for keywords (see section 4.1.3) and is the (lowercase)
-fully qualified company name registered with IANA for use in domain
-names [RFC1035]. For example, if the company XYZ Corp. had obtained the
-domain name "XYZ.com", then a vendor keyword 'abc' would be: 'xyz.com-
-abc'.
-
-Note: RFC 1035 [RFC1035] indicates that while upper and lower case
-letters are allowed in domain names, no significance is attached to the
-case. That is, two names with the same spelling but different case are
-to be treated as if identical. Also, the labels in a domain name must
-follow the rules for ARPANET host names: They must start with a letter,
-end with a letter or digit, and have as interior characters only
-letters, digits, and hyphen. Labels must be 63 characters or less.
-Labels are separated by the "." character.
-
-For vendor enum extensions, implementers MUST use values in the reserved
-integer range which is 2**30 to 2**31-1.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 133]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-6.2 Attribute Extensibility
-
-
-Attribute names (see section 4.1.3) are type2 keywords. Therefore, new
-attributes may be registered and have the same status as attributes in
-this document by following the type2 extension rules. For vendor
-attribute extensions, implementers SHOULD use keywords with a suitable
-distinguishing prefix as described in Section 6.1.
-
-IANA will publish approved attribute registration specifications as
-separate files:
-
- ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt
-
-where "xxx-yyy" is the new attribute name.
-
-If a new Printer object attribute is defined and its values can be
-affected by a specific document format, its specification needs to
-contain the following sentence:
-
- "The value of this attribute returned in a Get-Printer-
- Attributes response MAY depend on the "document-format"
- attribute supplied (see Section 3.2.5.1)."
-
-If the specification does not, then its value in the Get-Printer-
-Attributes response MUST NOT depend on the "document-format" supplied in
-the request. When a new Job Template attribute is registered, the value
-of the Printer attributes MAY vary with "document-format" supplied in
-the request without the specification having to indicate so.
-
-
-6.3 Attribute Syntax Extensibility
-
-
-Attribute syntaxes (see section 4.1) are like type2 enums. Therefore,
-new attribute syntaxes may be registered and have the same status as
-attribute syntaxes in this document by following the type2 extension
-rules described in Section 6.1. The initial set of value codes that
-identify each of the attribute syntaxes have been assigned in the
-"Encoding and Transport" document [IPP-PRO], including a designated
-range for vendor extension.
-
-For attribute syntaxes, the IPP Designated Expert in consultation with
-IANA assigns the next attribute syntax code in the appropriate range as
-specified in [IPP-PRO]. IANA will publish approved attribute syntax
-registration specifications as separate files:
-
- ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt
-
-where 'xxx-yyy' is the new attribute syntax name.
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 134]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-6.4 Operation Extensibility
-
-
-Operations (see section 3) may also be registered following the type2
-procedures described in Section 6.1, though major new operations will
-usually be done by a new standards track RFC that augments this
-document. For vendor operation extensions, implementers MUST use the
-range for the "operation-id" in requests specified in Section 4.4.15
-"operations-supported" Printer attribute.
-
-For operations, the IPP Designated Expert in consultation with IANA
-assigns the next operation-id code as specified in Section 4.4.15. IANA
-will publish approved operation registration specifications as separate
-files:
-
- ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt
-
-where "Xxx-Yyy" is the new operation name.
-
-
-6.5 Attribute Group Extensibility
-
-
-Attribute groups (see section 3.1.3) passed in requests and responses
-may be registered following the type2 procedures described in Section
-6.1. The initial set of attribute group tags have been assigned in the
-"Encoding and Transport" document [IPP-PRO], including a designated
-range for vendor extension.
-
-For attribute groups, the IPP Designated Expert in consultation with
-IANA assigns the next attribute group tag code in the appropriate range
-as specified in [IPP-PRO]. IANA will publish approved attribute group
-registration specifications as separate files:
-
- ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
- tag.txt
-
-where 'xxx-yyy-tag' is the new attribute group tag name.
-
-
-6.6 Status Code Extensibility
-
-
-Operation status codes (see section 3.1.6.1) may also be registered
-following the type2 procedures described in Section 6.1. The values for
-status codes are allocated in ranges as specified in Section 14 for each
-status code class:
-
- "informational" - Request received, continuing process
- "successful" - The action was successfully received, understood, and
- accepted
- "redirection" - Further action must be taken in order to complete the
- request
- "client-error" - The request contains bad syntax or cannot be
- fulfilled
- "server-error" - The IPP object failed to fulfill an apparently
- valid request
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 135]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-For vendor operation status code extensions, implementers MUST use the
-top of each range as specified in Section 13.
-
-For operation status codes, the IPP Designated Expert in consultation
-with IANA assigns the next status code in the appropriate class range as
-specified in Section 13. IANA will publish approved status code
-registration specifications as separate files:
-
- ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt
-
-where "xxx-yyy" is the new operation status code keyword.
-
-
-6.7 Out-of-band Attribute Value Extensibility
-
-
-Out-of-band attribute values (see the beginning of section 4.1) passed
-in requests and responses may be registered following the type2
-procedures described in Section 6.1. The initial set of out-of-band
-attribute value tags have been assigned in the "Encoding and Transport"
-document [IPP-PRO].
-
-For out-of-band attribute value tags, the IPP Designated Expert in
-consultation with IANA assigns the next out-of-band attribute value tag
-code in the appropriate range as specified in [IPP-PRO]. IANA will
-publish approved out-of-band attribute value tags registration
-specifications as separate files:
-
- ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-
- tags/xxx-yyy-tag.txt
-
-where 'xxx-yyy-tag' is the new out-of-band attribute value tag name.
-
-
-6.8 Registration of MIME types/sub-types for document-formats
-
-
-The "document-format" attribute's syntax is 'mimeMediaType'. This means
-that valid values are Internet Media Types (see Section 4.1.9). RFC
-2045 [RFC2045] defines the syntax for valid Internet media types. IANA
-is the registry for all Internet media types.
-
-
-6.9 Registration of charsets for use in 'charset' attribute values
-
-The "attributes-charset" attribute's syntax is 'charset'. This means
-that valid values are charsets names. When a charset in the IANA
-registry has more than one name (alias), the name labeled as "(preferred
-MIME name)", if present, MUST be used (see Section 4.1.7). IANA is the
-registry for charsets following the procedures of [RFC2278].
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 136]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-7. Internationalization Considerations
-
-
-Some of the attributes have values that are text strings and names which
-are intended for human understanding rather than machine understanding
-(see the 'text' and 'name' attribute syntaxes in Sections 4.1.1 and
-4.1.2).
-
-In each operation request, the client
-
- - identifies the charset and natural language of the request which
- affects each supplied 'text' and 'name' attribute value, and
- - requests the charset and natural language for attributes returned
- by the IPP object in operation responses (as described in Section
- 3.1.4.1).
-
-
-In addition, the client MAY separately and individually identify the
-Natural Language Override of a supplied 'text' or 'name' attribute using
-the 'textWithLanguage' and 'nameWithLanguage' technique described
-section 4.1.1.2 and 4.1.2.2 respectively.
-
-All IPP objects MUST support the UTF-8 [RFC2279] charset in all 'text'
-and 'name' attributes supported. If an IPP object supports more than
-the UTF-8 charset, the object MUST convert between them in order to
-return the requested charset to the client according to Section 3.1.4.2.
-If an IPP object supports more than one natural language, the object
-SHOULD return 'text' and 'name' values in the natural language requested
-where those values are generated by the Printer (see Section 3.1.4.1).
-
-For Printers that support multiple charsets and/or multiple natural
-languages in 'text' and 'name' attributes, different jobs may have been
-submitted in differing charsets and/or natural languages. All responses
-MUST be returned in the charset requested by the client. However, the
-Get-Jobs operation uses the 'textWithLanguage' and 'nameWithLanguage'
-mechanism to identify the differing natural languages with each job
-attribute returned.
-
-The Printer object also has configured charset and natural language
-attributes. The client can query the Printer object to determine the
-list of charsets and natural languages supported by the Printer object
-and what the Printer object's configured values are. See the "charset-
-configured", "charset-supported", "natural-language-configured", and
-"generated-natural-language-supported" Printer description attributes
-for more details.
-
-The "charset-supported" attributed identifies the supported charsets.
-If a charset is supported, the IPP object MUST be capable of converting
-to and from that charset into any other supported charset. In many
-cases, an IPP object will support only one charset and it MUST be the
-UTF-8 charset.
-
-The "charset-configured" attribute identifies the one supported charset
-which is the native charset given the current configuration of the IPP
-object (administrator defined).
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 137]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-The "generated-natural-language-supported" attribute identifies the set
-of supported natural languages for generated messages; it is not related
-to the set of natural languages that must be accepted for client
-supplied 'text' and 'name' attributes. For client supplied 'text' and
-'name' attributes, an IPP object MUST accept ALL supplied natural
-languages. Just because a Printer object is currently configured to
-support 'en-us' natural language does not mean that the Printer object
-should reject a job if the client supplies a job name that is in 'fr-
-ca'.
-
-The "natural-language-configured" attribute identifies the one supported
-natural language for generated messages which is the native natural
-language given the current configuration of the IPP object
-(administrator defined).
-
-Attributes of type 'text' and 'name' are populated from different
-sources. These attributes can be categorized into following groups
-(depending on the source of the attribute):
-
- 1. Some attributes are supplied by the client (e.g., the client
- supplied "job-name", "document-name", and "requesting-user-name"
- operation attributes along with the corresponding Job object's
- "job-name" and "job-originating-user-name" attributes). The IPP
- object MUST accept these attributes in any natural language no
- matter what the set of supported languages for generated messages
- 2. Some attributes are supplied by the system administrator (e.g.,
- the Printer object's "printer-name" and "printer-location"
- attributes). These too can be in any natural language. If the
- natural language for these attributes is different than what a
- client requests, then they must be reported using the Natural
- Language Override mechanism.
- 3. Some attributes are supplied by the device manufacturer (e.g., the
- Printer object's "printer-make-and-model" attribute). These too
- can be in any natural language. If the natural language for these
- attributes is different than what a client requests, then they must
- be reported using the Natural Language Override mechanism.
- 4. Some attributes are supplied by the operator (e.g., the Job
- object's "job-message-from-operator" attribute). These too can be
- in any natural language. If the natural language for these
- attributes is different than what a client requests, then they must
- be reported using the Natural Language Override mechanism.
- 5. Some attributes are generated by the IPP object (e.g., the Job
- object's "job-state-message" attribute, the Printer object's
- "printer-state-message" attribute, and the "status-message"
- operation attribute). These attributes can only be in one of the
- "generated-natural-language-supported" natural languages. If a
- client requests some natural language for these attributes other
- than one of the supported values, the IPP object SHOULD respond
- using the value of the "natural-language-configured" attribute
- (using the Natural Language Override mechanism if needed).
-
-
-The 'text' and 'name' attributes specified in this version of this
-document (additional ones will be registered according to the procedures
-in Section 6) are:
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 138]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
- Attributes Source
-
-
-Operation Attributes:
- job-name (name) client
- document-name (name) client
- requesting-user-name (name) client
- status-message (text) Job or Printer object
- detailed-status-message (text) Job or Printer object -
- see rule 1
- document-access-error (text) Job or Printer object -
- see rule 1
-
-Job Template Attributes:
- job-hold-until (keyword | name) client matches
- administrator-configured
- job-hold-until-default (keyword | name) client matches
- administrator-configured
- job-hold-until-supported (keyword | client matches
- name) administrator-configured
- job-sheets (keyword | name) client matches
- administrator-configured
- job-sheets-default (keyword | name) client matches
- administrator-configured
- job-sheets-supported (keyword | name) client matches
- administrator-configured
- media (keyword | name) client matches
- administrator-configured
- media-default (keyword | name) client matches
- administrator-configured
- media-supported (keyword | name) client matches
- administrator-configured
- media-ready (keyword | name) client matches
- administrator-configured
-
-Job Description Attributes:
- job-name (name) client or Printer object
- job-originating-user-name (name) Printer object
- job-state-message (text) Job or Printer object
- output-device-assigned (name(127)) administrator
- job-message-from-operator (text(127)) operator
- job-detailed-status-messages (1setOf Job or Printer object -
- text) see rule 1
- job-document-access-errors (1setOf Job or Printer object -
- text) see rule 1
-
-Printer Description Attributes:
- printer-name (name(127)) administrator
- printer-location (text(127)) administrator
- printer-info (text(127)) administrator
- printer-make-and-model (text(127)) administrator or
- manufacturer
- printer-state-message (text) Printer object
- printer-message-from-operator operator
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 139]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
- (text(127))
-
-Rule 1 - Neither the Printer nor the client localizes these message
-attributes, since they are intended for use by the system administrator
-or other experienced technical persons.
-
-
-
-
-
-8. Security Considerations
-
-
-It is difficult to anticipate the security risks that might exist in any
-given IPP environment. For example, if IPP is used within a given
-corporation over a private network, the risks of exposing document data
-may be low enough that the corporation will choose not to use encryption
-on that data. However, if the connection between the client and the IPP
-object is over a public network, the client may wish to protect the
-content of the information during transmission through the network with
-encryption.
-
-Furthermore, the value of the information being printed may vary from
-one IPP environment to the next. Printing payroll checks, for example,
-would have a different value than printing public information from a
-file. There is also the possibly of denial-of-service attacks, but
-denial-of-service attacks against printing resources are not well
-understood and there is no published precedents regarding this scenario.
-
-Once the authenticated identity of the requester has been supplied to
-the IPP object, the object uses that identity to enforce any
-authorization policy that might be in place. For example, one site's
-policy might be that only the job owner is allowed to cancel a job. The
-details and mechanisms to set up a particular access control policy are
-not part of IPP/1.1, and must be established via some other type of
-administrative or access control framework. However, there are
-operation status codes that allow an IPP server to return information
-back to a client about any potential access control violations for an
-IPP object.
-
-During a create operation, the client's identity is recorded in the Job
-object in an implementation-defined attribute. This information can be
-used to verify a client's identity for subsequent operations on that Job
-object in order to enforce any access control policy that might be in
-effect. See section 8.3 below for more details.
-
-Since the security levels or the specific threats that an IPP system
-administrator may be concerned with cannot be anticipated, IPP MUST be
-capable of operating with different security mechanisms and security
-policies as required by the individual installation. Security policies
-might vary from very strong, to very weak, to none at all, and
-corresponding security mechanisms will be required.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 140]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-8.1 Security Scenarios
-
-
-The following sections describe specific security attacks for IPP
-environments. Where examples are provided they should be considered
-illustrative of the environment and not an exhaustive set. Not all of
-these environments will necessarily be addressed in initial
-implementations of IPP.
-
-
-8.1.1 Client and Server in the Same Security Domain
-
-This environment is typical of internal networks where traditional
-office workers print the output of personal productivity applications on
-shared work-group printers, or where batch applications print their
-output on large production printers. Although the identity of the user
-may be trusted in this environment, a user might want to protect the
-content of a document against such attacks as eavesdropping, replaying
-or tampering.
-
-
-8.1.2 Client and Server in Different Security Domains
-
-Examples of this environment include printing a document created by the
-client on a publicly available printer, such as at a commercial print
-shop; or printing a document remotely on a business associate's printer.
-This latter operation is functionally equivalent to sending the document
-to the business associate as a facsimile. Printing sensitive information
-on a Printer in a different security domain requires strong security
-measures. In this environment authentication of the printer is required
-as well as protection against unauthorized use of print resources. Since
-the document crosses security domains, protection against eavesdropping
-and document tampering are also required. It will also be important in
-this environment to protect Printers against "spamming" and malicious
-document content.
-
-
-8.1.3 Print by Reference
-
-When the document is not stored on the client, printing can be done by
-reference. That is, the print request can contain a reference, or
-pointer, to the document instead of the actual document itself (see
-sections 3.2.2 and 3.3.2). Standard methods currently do not exist for
-remote entities to "assume" the credentials of a client for forwarding
-requests to a 3rd party. It is anticipated that Print-By-Reference will
-be used to access "public" documents and that sophisticated methods for
-authenticating "proxies" is not specified in this document.
-
-
-8.2 URIs in Operation, Job, and Printer attributes
-
-
-The "printer-uri-supported" attribute contains the Printer object's
-URI(s). Its companion attribute, "uri-security-supported", identifies
-the security mechanism used for each URI listed in the "printer-uri-
-supported" attribute. For each Printer operation request, a client MUST
-supply only one URI in the "printer-uri" operation attribute. In other
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 141]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-words, even though the Printer supports more than one URI, the client
-only interacts with the Printer object using one if its URIs. This
-duality is not needed for Job objects, since the Printer objects is the
-factory for Job objects, and the Printer object will generate the
-correct URI for new Job objects depending on the Printer object's
-security configuration.
-
-
-8.3 URIs for each authentication mechanisms
-
-
-Each URI has an authentication mechanism associated with it. If the URI
-is the i'th element of "printer-uri-supported", then authentication
-mechanism is the "i th" element of "uri-authentication-supported". For a
-list of possible authentication mechanisms, see section 4.4.2.
-
-The Printer object uses an authentication mechanism to determine the
-name of the user performing an operation. This user is called the
-"authenticated user". The credibility of authentication depends on the
-mechanism that the Printer uses to obtain the user's name. When the
-authentication mechanism is 'none', all authenticated users are
-"anonymous".
-
-During job creation operations, the Printer initializes the value of the
-"job-originating-user-name" attribute (see section 4.3.6) to be the
-authenticated user. The authenticated user is this case is called the
-"job owner".
-
-If an implementation can be configured to support more than one
-authentication mechanism (see section 4.4.2), then it MUST implement
-rules for determining equality of authenticated user names which have
-been authenticated via different authentication mechanisms. One
-possible policy is that identical names that are authenticated via
-different mechanisms are different. For example, a user can cancel his
-job only if he uses the same authentication mechanism for both Cancel-
-Job and Print-Job. Another policy is that identical names that are
-authenticated via different mechanism are the same if the authentication
-mechanism for the later operation is not less strong than the
-authentication mechanism for the earlier job creation operation. For
-example, a user can cancel his job only if he uses the same or stronger
-authentication mechanism for Cancel-Job and Print-Job. With this second
-policy a job submitted via 'requesting-user-name' authentication could
-be canceled via 'digest' authentication. With the first policy, the job
-could not be canceled in this way.
-
-A client is able to determine the authentication mechanism used to
-create a job. It is the i'th value of the Printer's "uri-authentication-
-supported" attribute (see section 4.4.2), where i is the index of the
-element of the Printer's "printer-uri-supported" attribute (see section
-4.4.1) equal to the job's "job-printer-uri" attribute (see section
-4.3.3).
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 142]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-8.4 Restricted Queries
-
-
-In many IPP operations, a client supplies a list of attributes to be
-returned in the response. For security reasons, an IPP object may be
-configured not to return all attributes (or all values) that a client
-requests. The job attributes returned MAY depend on whether the
-requesting user is the same as the user that submitted the job. The IPP
-object MAY even return none of the requested attributes. In such cases,
-the status returned is the same as if the object had returned all
-requested attributes. The client cannot tell by such a response whether
-the requested attribute was present or absent on the object.
-
-
-8.5 Operations performed by operators and system administrators
-
-For the three printer operations Pause-Printer, Resume-Printer, and
-Purge-Jobs (see sections 3.2.7, 3.2.8 and 3.2.9), the requesting user is
-intended to be an operator or administrator of the Printer object (see
-section 1). Otherwise, the IPP Printer MUST reject the operation and
-return: 'client-error-forbidden', 'client-error-not-authenticated', or
-'client-error-not-authorized' as appropriate. For operations on jobs,
-the requesting user is intended to be the job owner or may be an
-operator or administrator of the Printer object. The means for
-authorizing an operator or administrator of the Printer object are not
-specified in this document.
-
-8.6 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
-RECOMMENDED 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.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 143]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-9. References
-
-[ASME-Y14.1M]
- Metric Drawing Sheet Size and Format, ASME Y14.1M-1995. This
- standard defines metric sheet sizes and formats for engineering
- drawings.
-
-[ASCII]
- Coded Character Set - 7-bit American Standard Code for Information
- Interchange (ASCII), ANSI X3.4-1986. This standard is the
- specification of the US-ASCII charset.
-
-[BCP-11]
- Bradner S., Hovey R., "The Organizations Involved in the IETF
- Standards Process", 1996/10/29 (RFC 2028)
-
-[HTPP]
- J. Barnett, K. Carter, R. DeBry, "Initial Draft - Hypertext
- Printing Protocol - HTPP/1.0", October 1996,
- ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz
-
-[IANA-CON]
- Narte, T. and Alvestrand, H.T.: Guidelines for Writing an IANA
- Considerations Section in RFCs, Work in Progress, draft-iesg-iana-
- considerations-04.txt, May 21, 1998.
-
-[IANA-CS]
- IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-
- notes/iana/assignments/character-sets
-
-[IANA-MT]
- IANA Registry of Media Types: ftp://ftp.isi.edu/in-
- notes/iana/assignments/media-types/
-
-[IPP-IIG]
- Hastings, T., Manros, C., "Internet Printing Protocol/1.1: draft-
- ietf-ipp-implementers-guide-v11-00.txt, work in progress, September
- 27, 1999.
-
-[IPP-PRO]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 05.txt, March 1, 2000.
-
-[ISO10646-1]
- ISO/IEC 10646-1:1993, "Information technology -- Universal
- Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and
- Basic Multilingual Plane, JTC1/SC2."
-
-[ISO8859-1]
- ISO/IEC 8859-1:1987, "Information technology -- 8-bit One-Byte
- Coded Character Set - Part 1: Latin Alphabet Nr 1", 1987, JTC1/SC2.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 144]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-[ISO10175]
- ISO/IEC 10175 Document Printing Application (DPA), June 1996.
-
-[LDPA]
- T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P.
- Zehler, "LDPA - Lightweight Document Printing Application",
- October 1996,
- ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
-
-[P1387.4]
- Kirk, M. (editor), POSIX System Administration - Part 4: Printing
- Interfaces, POSIX 1387.4 D8, 1994.
-
-[PSIS] Herriot, R. (editor), X/Open A Printing System
- Interoperability Specification (PSIS), August 1995.
-
-[PWG]
- Printer Working Group, http://www.pwg.org.
-
-[RFC1035]
- P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
- RFC 1035, November 1987.
-
-[RFC1179]
- McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC
- 1179, August 1990.
-
-[RFC1759]
- Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog,
- J., "Printer MIB", RFC 1759, March 1995.
-
-[RFC1766]
- H. Alvestrand, "Tags for the Identification of Languages", RFC
- 1766, March 1995.
-
-[RFC1951]
- P. Deutsch, "DEFLATE Compressed Data Format Specification version
- 1.3 ", RFC 1951, May 1996.
-
-[RFC1952]
- P. Deutsch, "GZIP file format specification version 4.3", RFC 1952,
- May 1996.
-
-[RFC1977]
- V. Schryver, "PPP BSD Compression Protocol", RFC 1977, August 1996.
-
-[RFC2026]
- S. Bradner, "The Internet Standards Process -- Revision 3", RFC
- 2026, October 1996.
-
-[RFC2045]
- N. Fried, N. Borenstein, ", Multipurpose Internet Mail Extensions
- (MIME) Part One: Format of Internet Message Bodies " RFC 2045,
- November 1996.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 145]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-[RFC2046]
- Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
- N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521,
- RFC1522, RFC1590), RFC 2046.
-
-[RFC2048]
- N. Freed, J. Klensin & J. Postel, "Multipurpose Internet Mail
- Extension (MIME) Part Four: Registration Procedures". RFC 2048,
- November 1996.
-
-[RFC2119]
- S. Bradner, "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119 , March 1997
-
-[RFC2228]
- M. Horowitz, S. Lunt, "FTP Security Extensions", RFC 2228, October
- 1997.
-
-[RFC2246]
- T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
- January 1999.
-
-[RFC2277]
- H. Alvestrand, "IETF Policy on Character Sets and Languages" RFC
- 2277, January 1998.
-
-[RFC2278]
- N. Freed, J. Postel: "IANA CharSet Registration Procedures", RFC
- 2278, January 1998.
-
-[RFC2279]
- F. Yergeau , "UTF-8, a transformation format of ISO 10646", RFC
- 2279. January 1998.
-
-[RFC2316]
- S. Bellovin , "Report of the IAB Security Architecture Workshop",
- RFC 2316, April 1998.
-
-[RFC2396]
- Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
-[RFC2565]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
-
-[RFC2566]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April 1999.
-
-[RFC2567]
- Wright, D., "Design Goals for an Internet Printing Protocol", RFC
- 2567, April 1999.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 146]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-[RFC2568]
- Zilles, S., "Rationale for the Structure and Model and Protocol for
- the Internet Printing Protocol", RFC 2568, April 1999.
-
-[RFC2569]
- Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
- LPD and IPP Protocols", RFC 2569, April 1999.
-
-[RFC2579]
- K. McCloghrie, D. Perkins, J. Schoenwaelder, "Textual Conventions
- for SMIv2" RFC 2579 (Also STD0058), April 1999.
-
-[RFC2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-[RFC2617]
- J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.
- Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access
- Authentication", RFC 2617, June 1999.
-
-[SSL]
- Netscape, The SSL Protocol, Version 3, (Text version 3.02),
- November 1996.
-
-[SWP]
- P. Moore, B. Jahromi, S. Butler, "Simple Web Printing SWP/1.0", May
- 7, 1997, ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf
-
-
-
-10. Author's Address
-
- Scott A. Isaacson (Editor)
- Novell, Inc.
- 122 E 1700 S
- Provo, UT 84606
-
- Phone: 801-861-7366
- Fax: 801-861-2517
- e-mail: sisaacson@novell.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
- Robert Herriot
- Xerox Corp.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 147]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 3400 Hill View Ave, Building 1
- Palo Alto, CA 94304
-
- Phone: 650-813-7696
- Fax: 650-813-6860
- e-mail: robert.herriot@pahv.xerox.com
-
- Roger deBry
- Utah Valley State College
- Orem, UT 84058
-
- Phone: (801) 222-8000
- EMail: debryro@uvsc.edu
-
- Patrick Powell
- Astart Technologies
- 9475 Chesapeake Dr., Suite D
- San Diego, CA 95123
-
- Phone: (619) 874-6543
- Fax: (619) 279-8424
- e-mail: papowell@astart.com
-
- IPP Mailing List: ipp@pwg.org
- IPP Mailing List Subscription: ipp-request@pwg.org
- IPP Web Page: http://www.pwg.org/ipp/
-
-Implementers of this specification document are encouraged to join IPP
-Mailing List in order to participate in any discussions of clarification
-issues and review of registration proposals for additional attributes
-and values.
-
-Other Participants:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 148]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-Chuck Adams - Tektronix Shivaun Albright - HP
-Stefan Andersson - Axis Jeff Barnett - IBM
-Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
-Systems
-Keith Carter - IBM Angelo Caruso - Xerox
-Rajesh Chawla - TR Computing Nancy Chen - Okidata
-Solutions
-Josh Cohen - Microsoft Jeff Copeland - QMS
-Andy Davidson - Tektronix Roger deBry - IBM
-Maulik Desai - Auco Mabry Dozier - QMS
-Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
-Systems
-Steve Gebert - IBM Sue Gleeson - Digital
-Charles Gordon - Osicom Brian Grimshaw - Apple
-Jerry Hadsell - IBM Richard Hart - Digital
-Tom Hastings - Xerox Henrik Holst - I-data
-Stephen Holmstead Zhi-Hong Huang - Zenographics
-Scott Isaacson - Novell Babek Jahromi - Microsoft
-Swen Johnson - Xerox David Kellerman - Northlake
- Software
-Robert Kline - TrueSpectra Charles Kong - Panasonic
-Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
-Takami Kurono - Brother Rick Landau - Digital
-Scott Lawrence - Agranot Systems Greg LeClair - Epson
-Dwight Lewis - Lexmark Harry Lewis - IBM
-Tony Liao - Vivid Image Roy Lomicka - Digital
-Pete Loya - HP Ray Lutz - Cognisys
-Mike MacKay - Novell, Inc. David Manchala - Xerox
-Carl-Uno Manros - Xerox Jay Martin - Underscore
-Stan McConnell - Xerox Larry Masinter - Xerox
-Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
-Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
-Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
-Pat Nogay - IBM Ron Norton - Printronics
-Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
-Patrick Powell - Astart Jeff Rackowitz - Intermec
-Technologies
-Eric Random - Peerless Rob Rhoads - Intel
-Xavier Riley - Xerox Gary Roberts - Ricoh
-David Roach - Unisys Stuart Rowley - Kyocera
-Yuji Sasaki - Japan Computer Richard Schneider - Epson
-Industry
-Kris Schoff - HP Katsuaki Sekiguchi - Canon
- Information Systems
-Bob Setterbo - Adobe Gail Songer - Peerless
-Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
-Systems
-Mike Timperman - Lexmark Atsushi Uchino - Epson
-Shigeru Ueda - Canon Bob Von Andel - Allegro Software
-William Wagner - NetSilicon/DPI Jim Walker - DAZEL
-Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
-Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
-Jasper Wong - Xionics Don Wright - Lexmark
-Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 149]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-Michael Yeung - Canon Information Lloyd Young - Lexmark
-Systems
-Atsushi Yuki - Kyocera Peter Zehler - Xerox
-William Zhang- Canon Information Frank Zhao - Panasonic
-Systems
-Steve Zilles - Adobe Rob Zirnstein - Canon Information
- Systems
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 150]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-11. Formats for IPP Registration Proposals
-
-In order to propose an IPP extension for registration, the proposer must
-submit an application to IANA by email to "iana@iana.org" or by filling
-out the appropriate form on the IANA web pages (http://www.iana.org).
-This section specifies the required information and the formats for
-proposing registrations of extensions to IPP as provided in Section 6
-for:
-
- 1. type2 'keyword' attribute values
- 2. type3 'keyword' attribute values
- 3. type2 'enum' attribute values
- 4. type3 'enum' attribute values
- 5. attributes
- 6. attribute syntaxes
- 7. operations
- 8. status codes
- 9. out-of-band attribute values
-
-11.1 Type2 keyword attribute values registration
-
-Type of registration: type2 keyword attribute value
-Name of attribute to which this keyword specification is to be added:
-Proposed keyword name of this keyword value:
-Specification of this keyword value (follow the style of IPP Model
-Section 4.1.2.3):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For type2 keywords, the Designated Expert will be the point of
-contact for the approved registration specification, if any maintenance
-of the registration specification is needed.
-
-11.2 Type3 keyword attribute values registration
-
-Type of registration: type3 keyword attribute value
-Name of attribute to which this keyword specification is to be added:
-Proposed keyword name of this keyword value:
-Specification of this keyword value (follow the style of IPP Model
-Section 4.1.2.3):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For type3 keywords, the proposer will be the point of contact for
-the approved registration specification, if any maintenance of the
-registration specification is needed.
-
-11.3 Type2 enum attribute values registration
-
-Type of registration: type2 enum attribute value
-Name of attribute to which this enum specification is to be added:
-Keyword symbolic name of this enum value:
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 151]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-Numeric value (to be assigned by the IPP Designated Expert in
-consultation with IANA):
-Specification of this enum value (follow the style of IPP Model Section
-4.1.4):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For type2 enums, the Designated Expert will be the point of
-contact for the approved registration specification, if any maintenance
-of the registration specification is needed.
-
-11.4 Type3 enum attribute values registration
-
-Type of registration: type3 enum attribute value
-Name of attribute to which this enum specification is to be added:
-Keyword symbolic name of this enum value:
-Numeric value (to be assigned by the IPP Designated Expert in
-consultation with IANA):
-Specification of this enum value (follow the style of IPP Model Section
-4.1.4):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For type3 enums, the proposer will be the point of contact for
-the approved registration specification, if any maintenance of the
-registration specification is needed.
-
-11.5 Attribute registration
-
-Type of registration: attribute
-Proposed keyword name of this attribute:
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description):
-Operations to be used with if the attribute is an operation attribute:
-Object (Job, Printer, etc. if bound to an object):
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2):
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute:
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For attributes, the IPP Designated Expert will be the point of
-contact for the approved registration specification, if any maintenance
-of the registration specification is needed.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 152]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-11.6 Attribute Syntax registration
-
-Type of registration: attribute syntax
-Proposed name of this attribute syntax:
-Type of attribute syntax (integer, octetString, character-string, see
-[IPP-PRO]):
-Numeric tag according to [IPP-PRO] (to be assigned by the IPP Designated
-Expert in consultation with IANA):
-Specification of this attribute (follow the style of IPP Model Section
-4.1):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For attribute syntaxes, the IPP Designated Expert will be the
-point of contact for the approved registration specification, if any
-maintenance of the registration specification is needed.
-
-11.7 Operation registration
-
-Type of registration: operation
-Proposed name of this operation:
-Numeric operation-id value according to section 4.4.15 (to be assigned
-by the IPP Designated Expert in consultation with IANA):
-Object Target (Job, Printer, etc. that operation is upon):
-Specification of this operation (follow the style of IPP Model Section
-3):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For operations, the IPP Designated Expert will be the point of
-contact for the approved registration specification, if any maintenance
-of the registration specification is needed.
-
-11.8 Attribute Group registration
-
-Type of registration: attribute group
-Proposed name of this attribute group:
-Numeric tag according to [IPP-PRO] (to be assigned by the IPP Designated
-Expert in consultation with IANA):
-Operation requests and group number for each operation in which the
-attribute group occurs:
-Operation responses and group number for each operation in which the
-attribute group occurs:
-Specification of this attribute group (follow the style of IPP Model
-Section 3):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For attribute groups, the IPP Designated Expert will be the point
-of contact for the approved registration specification, if any
-maintenance of the registration specification is needed.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 153]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-11.9 Status code registration
-
-Type of registration: status code
-Keyword symbolic name of this status code value:
-Numeric value (to be assigned by the IPP Designated Expert in
-consultation with IANA):
-Operations that this status code may be used with:
-Specification of this status code (follow the style of IPP Model Section
-13 APPENDIX B: Status Codes and Suggested Status Code Messages):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For status codes, the Designated Expert will be the point of
-contact for the approved registration specification, if any maintenance
-of the registration specification is needed.
-
-11.10 Out-of-band Attribute Value registration
-
-Type of registration: out-of-band attribute value
-Proposed name of this out-of-band attribute value:
-Numeric tag according to [IPP-PRO] (to be assigned by the IPP Designated
-Expert in consultation with IANA):
-Operations that this out-of-band attribute value may be used with:
-Attributes that this out-of-band attribute value may be used with:
-Specification of this out-of-band attribute value (follow the style of
-the beginning of IPP Model Section 4.1):
-Name of proposer:
-Address of proposer:
-Email address of proposer:
-
-Note: For out-of-band attribute values, the IPP Designated Expert will
-be the point of contact for the approved registration specification, if
-any maintenance of the registration specification is needed.
-
-
-12. APPENDIX A: Terminology
-
-
-This specification document uses the terminology defined in this
-section.
-
-
-12.1 Conformance Terminology
-
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
-interpreted as described in RFC 2119 [RFC2119].
-
-
-12.1.1 NEED NOT
-
-This term is not included in RFC 2119. The verb "NEED NOT" indicates an
-action that the subject of the sentence does not have to implement in
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 154]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-order to claim conformance to the standard. The verb "NEED NOT" is used
-instead of "MAY NOT" since "MAY NOT" sounds like a prohibition.
-
-
-12.2 Model Terminology
-
-
-12.2.1 Keyword
-
-Keywords are used within this document as identifiers of semantic
-entities within the abstract model (see section 4.1.2.3). Attribute
-names, some attribute values, attribute syntaxes, and attribute group
-names are represented as keywords.
-
-
-12.2.2 Attributes
-
-An attribute is an item of information that is associated with an
-instance of an IPP object. An attribute consists of an attribute name
-and one or more attribute values. Each attribute has a specific
-attribute syntax. All object attributes are defined in section 4 and
-all operation attributes are defined in section 3.
-
-Job Template Attributes are described in section 4.2. The client
-optionally supplies Job Template attributes in a create request
-(operation requests that create Job objects). The Printer object has
-associated attributes which define supported and default values for the
-Printer.
-
-
-12.2.2.1 Attribute Name
-
-Each attribute is uniquely identified in this document by its attribute
-name. An attribute name is a keyword. The keyword attribute name is
-given in the section header describing that attribute. In running text
-in this document, attribute names are indicated inside double quotation
-marks (") where the quotation marks are not part of the keyword itself.
-
-
-12.2.2.2 Attribute Group Name
-
-Related attributes are grouped into named groups. The name of the group
-is a keyword. The group name may be used in place of naming all the
-attributes in the group explicitly. Attribute groups are defined in
-section 3.
-
-
-12.2.2.3 Attribute Value
-
-Each attribute has one or more values. Attribute values are represented
-in the syntax type specified for that attribute. In running text in this
-document, attribute values are indicated inside single quotation marks
-('), whether their attribute syntax is keyword, integer, text, etc.
-where the quotation marks are not part of the value itself.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 155]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-12.2.2.4 Attribute Syntax
-
-Each attribute is defined using an explicit syntax type. In this
-document, each syntax type is defined as a keyword with specific
-meaning. The "Encoding and Transport" document [IPP-PRO] indicates the
-actual "on-the-wire" encoding rules for each syntax type. Attribute
-syntax types are defined in section 4.1.
-
-
-12.2.3 Supports
-
-By definition, a Printer object supports an attribute only if that
-Printer object responds with the corresponding attribute populated with
-some value(s) in a response to a query for that attribute. A Printer
-object supports an attribute value if the value is one of the Printer
-object's "supported values" attributes. The device behind a Printer
-object may exhibit a behavior that corresponds to some IPP attribute,
-but if the Printer object, when queried for that attribute, doesn't
-respond with the attribute, then as far as IPP is concerned, that
-implementation does not support that feature. If the Printer object's
-"xxx-supported" attribute is not populated with a particular value (even
-if that value is a legal value for that attribute), then that Printer
-object does not support that particular value.
-
-A conforming implementation MUST support all REQUIRED attributes.
-However, even for REQUIRED attributes, conformance to IPP does not
-mandate that all implementations support all possible values
-representing all possible job processing behaviors and features. For
-example, if a given instance of a Printer supports only certain document
-formats, then that Printer responds with the "document-format-supported"
-attribute populated with a set of values, possibly only one, taken from
-the entire set of possible values defined for that attribute. This
-limited set of values represents the Printer's set of supported document
-formats. Supporting an attribute and some set of values for that
-attribute enables IPP end users to be aware of and make use of those
-features associated with that attribute and those values. If an
-implementation chooses to not support an attribute or some specific
-value, then IPP end users would have no ability to make use of that
-feature within the context of IPP itself. However, due to existing
-practice and legacy systems which are not IPP aware, there might be some
-other mechanism outside the scope of IPP to control or request the
-"unsupported" feature (such as embedded instructions within the document
-data itself).
-
-For example, consider the "finishings-supported" attribute.
-
- 1) If a Printer object is not physically capable of stapling, the
- "finishings-supported" attribute MUST NOT be populated with the
- value of 'staple'.
- 2) A Printer object is physically capable of stapling, however an
- implementation chooses not to support stapling in the IPP
- "finishings" attribute. In this case, 'staple' MUST NOT be a value
- in the "finishings-supported" Printer object attribute. Without
- support for the value 'staple', an IPP end user would have no means
- within the protocol itself to request that a Job be stapled.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 156]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- However, an existing document data formatter might be able to
- request that the document be stapled directly with an embedded
- instruction within the document data. In this case, the IPP
- implementation does not "support" stapling, however the end user is
- still able to have some control over the stapling of the completed
- job.
- 3) A Printer object is physically capable of stapling, and an
- implementation chooses to support stapling in the IPP "finishings"
- attribute. In this case, 'staple' MUST be a value in the
- "finishings-supported" Printer object attribute. Doing so, would
- enable end users to be aware of and make use of the stapling
- feature using IPP attributes.
-
-
-Even though support for Job Template attributes by a Printer object is
-OPTIONAL, it is RECOMMENDED that if the device behind a Printer object
-is capable of realizing any feature or function that corresponds to an
-IPP attribute and some associated value, then that implementation SHOULD
-support that IPP attribute and value.
-
-The set of values in any of the supported value attributes is set
-(populated) by some administrative process or automatic sensing
-mechanism that is outside the scope of this IPP/1.1 document. For
-administrative policy and control reasons, an administrator may choose
-to make only a subset of possible values visible to the end user. In
-this case, the real output device behind the IPP Printer abstraction may
-be capable of a certain feature, however an administrator is specifying
-that access to that feature not be exposed to the end user through the
-IPP protocol. Also, since a Printer object may represent a logical
-print device (not just a physical device) the actual process for
-supporting a value is undefined and left up to the implementation.
-However, if a Printer object supports a value, some manual human action
-may be needed to realize the semantic action associated with the value,
-but no end user action is required.
-
-For example, if one of the values in the "finishings-supported"
-attribute is 'staple', the actual process might be an automatic staple
-action by a physical device controlled by some command sent to the
-device. Or, the actual process of stapling might be a manual action by
-an operator at an operator attended Printer object.
-
-For another example of how supported attributes function, consider a
-system administrator who desires to control all print jobs so that no
-job sheets are printed in order to conserve paper. To force no job
-sheets, the system administrator sets the only supported value for the
-"job-sheets-supported" attribute to 'none'. In this case, if a client
-requests anything except 'none', the create request is rejected or the
-"job-sheets" value is ignored (depending on the value of "ipp-attribute-
-fidelity"). To force the use of job start/end sheets on all jobs, the
-administrator does not include the value 'none' in the "job-sheets-
-supported" attribute. In this case, if a client requests 'none', the
-create request is rejected or the "job-sheets" value is ignored (again
-depending on the value of "ipp-attribute-fidelity").
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 157]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-12.2.4 print-stream page
-
-A "print-stream page" is a page according to the definition of pages in
-the language used to express the document data.
-
-
-12.2.5 impression
-
-An "impression" is the image (possibly many print-stream pages in
-different configurations) imposed onto a single media page.
-
-
-
-13. APPENDIX B: Status Codes and Suggested Status Code Messages
-
-
-This section defines status code enum keywords and values that are used
-to provide semantic information on the results of an operation request.
-Each operation response MUST include a status code. The response MAY
-also contain a status message that provides a short textual description
-of the status. The status code is intended for use by automata, and the
-status message is intended for the human end user. Since the status
-message is an OPTIONAL component of the operation response, an IPP
-application (i.e., a browser, GUI, print driver or gateway) is NOT
-REQUIRED to examine or display the status message, since it MAY not be
-returned to the application.
-
-The prefix of the status keyword defines the class of response as
-follows:
-
- "informational" - Request received, continuing process
- "successful" - The action was successfully received, understood, and
- accepted
- "redirection" - Further action must be taken in order to complete the
- request
- "client-error" - The request contains bad syntax or cannot be
- fulfilled
- "server-error" - The IPP object failed to fulfill an apparently
- valid request
-
-
-As with type2 enums, IPP status codes are extensible. IPP clients are
-NOT REQUIRED to understand the meaning of all registered status codes,
-though such understanding is obviously desirable. However, IPP clients
-MUST understand the class of any status code, as indicated by the
-prefix, and treat any unrecognized response as being equivalent to the
-first status code of that class, with the exception that an unrecognized
-response MUST NOT be cached. For example, if an unrecognized status
-code of "client-error-xxx-yyy" is received by the client, it can safely
-assume that there was something wrong with its request and treat the
-response as if it had received a "client-error-bad-request" status code.
-In such cases, IPP applications SHOULD present the OPTIONAL message (if
-present) to the end user since the message is likely to contain human
-readable information which will help to explain the unusual status. The
-name of the enum is the suggested status message for US English.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 158]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-The status code values range from 0x0000 to 0x7FFF. The value ranges
-for each status code class are as follows:
-
- "successful" - 0x0000 to 0x00FF
- "informational" - 0x0100 to 0x01FF
- "redirection" - 0x0200 to 0x02FF
- "client-error" - 0x0400 to 0x04FF
- "server-error" - 0x0500 to 0x05FF
-
-
-The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0 to
-5) is reserved for vendor use within each status code class. Values
-0x0600 to 0x7FFF are reserved for future assignment by IETF standards
-track documents and MUST NOT be used.
-
-
-13.1 Status Codes
-
-
-Each status code is described below. Section 13.1.5.9 contains a table
-that indicates which status codes apply to which operations. The
-Implementer's Guide [IPP-IIG] describe the suggested steps for
-processing IPP attributes for all operations, including returning status
-codes.
-
-
-13.1.1 Informational
-
-This class of status code indicates a provisional response and is to be
-used for informational purposes only.
-
-There are no status codes defined in IPP/1.1 for this class of status
-code.
-
-
-13.1.2 Successful Status Codes
-
-This class of status code indicates that the client's request was
-successfully received, understood, and accepted.
-
-
-13.1.2.1 successful-ok (0x0000)
-
-The request has succeeded and no request attributes were substituted or
-ignored. In the case of a response to a create request, the
-'successful-ok' status code indicates that the request was successfully
-received and validated, and that the Job object has been created; it
-does not indicate that the job has been processed. The transition of
-the Job object into the 'completed' state is the only indicator that the
-job has been printed.
-
-
-13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)
-
-The request has succeeded, but some supplied (1) attributes were ignored
-or (2) unsupported values were substituted with supported values or were
-ignored in order to perform the operation without rejecting it.
-Unsupported attributes, attribute syntaxes, or values MUST be returned
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 159]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-in the Unsupported Attributes group of the response for all operations.
-There is an exception to this rule for the query operations: Get-
-Printer-Attributes, Get-Jobs, and Get-Job-Attributes for the "requested-
-attributes" operation attribute only. When the supplied values of the
-"requested-attributes" operation attribute are requesting attributes
-that are not supported, the IPP object MAY, but is NOT REQUIRED to,
-return the "requested-attributes" attribute in the Unsupported Attribute
-response group (with the unsupported values only). See sections 3.1.7
-and 3.2.1.2.
-
-
-13.1.2.3 successful-ok-conflicting-attributes (0x0002)
-
-The request has succeeded, but some supplied attribute values conflicted
-with the values of other supplied attributes. These conflicting values
-were either (1) substituted with (supported) values or (2) the
-attributes were removed in order to process the job without rejecting
-it. 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 for all operations as supplied by the
-client. See sections 3.1.7 and 3.2.1.2.
-
-
-13.1.3 Redirection Status Codes
-
-This class of status code indicates that further action needs to be
-taken to fulfill the request.
-
-There are no status codes defined in IPP/1.1 for this class of status
-code.
-
-
-13.1.4 Client Error Status Codes
-
-This class of status code is intended for cases in which the client
-seems to have erred. The IPP object SHOULD return a message containing
-an explanation of the error situation and whether it is a temporary or
-permanent condition.
-
-
-13.1.4.1 client-error-bad-request (0x0400)
-
-The request could not be understood by the IPP object due to malformed
-syntax (such as the value of a fixed length attribute whose length does
-not match the prescribed length for that attribute - see the
-Implementer's Guide [IPP-IIG] ). The IPP application SHOULD NOT repeat
-the request without modifications.
-
-
-13.1.4.2 client-error-forbidden (0x0401)
-
-The IPP object understood the request, but is refusing to fulfill it.
-Additional authentication information or authorization credentials will
-not help and the request SHOULD NOT be repeated. This status code is
-commonly used when the IPP object does not wish to reveal exactly why
-the request has been refused or when no other response is applicable.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 160]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-13.1.4.3 client-error-not-authenticated (0x0402)
-
-The request requires user authentication. The IPP client may repeat the
-request with suitable authentication information. If the request already
-included authentication information, then this status code indicates
-that authorization has been refused for those credentials. If this
-response contains the same challenge as the prior response, and the user
-agent has already attempted authentication at least once, then the
-response message may contain relevant diagnostic information. This
-status codes reveals more information than "client-error-forbidden".
-
-
-13.1.4.4 client-error-not-authorized (0x0403)
-
-The requester is not authorized to perform the request. Additional
-authentication information or authorization credentials will not help
-and the request SHOULD NOT be repeated. This status code is used when
-the IPP object wishes to reveal that the authentication information is
-understandable, however, the requester is explicitly not authorized to
-perform the request. This status codes reveals more information than
-"client-error-forbidden" and "client-error-not-authenticated".
-
-
-13.1.4.5 client-error-not-possible (0x0404)
-
-This status code is used when the request is for something that can not
-happen. For example, there might be a request to cancel a job that has
-already been canceled or aborted by the system. The IPP client SHOULD
-NOT repeat the request.
-
-
-13.1.4.6 client-error-timeout (0x0405)
-
-The client did not produce a request within the time that the IPP object
-was prepared to wait. For example, a client issued a Create-Job
-operation and then, after a long period of time, issued a Send-Document
-operation and this error status code was returned in response to the
-Send-Document request (see section 3.3.1). The IPP object might have
-been forced to clean up resources that had been held for the waiting
-additional Documents. The IPP object was forced to close the Job since
-the client took too long. The client SHOULD NOT repeat the request
-without modifications.
-
-
-13.1.4.7 client-error-not-found (0x0406)
-
-The IPP object has not found anything matching the request URI. No
-indication is given of whether the condition is temporary or permanent.
-For example, a client with an old reference to a Job (a URI) tries to
-cancel the Job, however in the mean time the Job might have been
-completed and all record of it at the Printer has been deleted. This
-status code, 'client-error-not-found' is returned indicating that the
-referenced Job can not be found. This error status code is also used
-when a client supplies a URI as a reference to the document data in
-either a Print-URI or Send-URI operation, but the document can not be
-found.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 161]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-In practice, an IPP application should avoid a not found situation by
-first querying and presenting a list of valid Printer URIs and Job URIs
-to the end-user.
-
-
-13.1.4.8 client-error-gone (0x0407)
-
-The requested object is no longer available and no forwarding address is
-known. This condition should be considered permanent. Clients with
-link editing capabilities should delete references to the request URI
-after user approval. If the IPP object does not know or has no facility
-to determine, whether or not the condition is permanent, the status code
-"client-error-not-found" should be used instead.
-
-This response is primarily intended to assist the task of maintenance by
-notifying the recipient that the resource is intentionally unavailable
-and that the IPP object administrator desires that remote links to that
-resource be removed. It is not necessary to mark all permanently
-unavailable resources as "gone" or to keep the mark for any length of
-time -- that is left to the discretion of the IPP object administrator
-and/or Printer implementation.
-
-
-13.1.4.9 client-error-request-entity-too-large (0x0408)
-
-The IPP object is refusing to process a request because the request
-entity is larger than the IPP object is willing or able to process. An
-IPP Printer returns this status code when it limits the size of print
-jobs and it receives a print job that exceeds that limit or when the
-attributes are so many that their encoding causes the request entity to
-exceed IPP object capacity.
-
-
-13.1.4.10 client-error-request-value-too-long (0x0409)
-
-The IPP object is refusing to service the request because one or more of
-the client-supplied attributes has a variable length value that is
-longer than the maximum length specified for that attribute. The IPP
-object might not have sufficient resources (memory, buffers, etc.) to
-process (even temporarily), interpret, and/or ignore a value larger than
-the maximum length. Another use of this error code is when the IPP
-object supports the processing of a large value that is less than the
-maximum length, but during the processing of the request as a whole, the
-object may pass the value onto some other system component which is not
-able to accept the large value. For more details, see the Implementer's
-Guide [IPP-IIG] .
-
-Note: For attribute values that are URIs, this rare condition is only
-likely to occur when a client has improperly submitted a request with
-long query information (e.g. an IPP application allows an end-user to
-enter an invalid URI), when the client has descended into a URI "black
-hole" of redirection (e.g., a redirected URI prefix that points to a
-suffix of itself), or when the IPP object is under attack by a client
-attempting to exploit security holes present in some IPP objects using
-fixed-length buffers for reading or manipulating the Request-URI.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 162]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-13.1.4.11 client-error-document-format-not-supported (0x040A)
-
-The IPP object is refusing to service the request because the document
-data is in a format, as specified in the "document-format" operation
-attribute, that is not supported by the Printer object. This error is
-returned independent of the client-supplied "ipp-attribute-fidelity".
-The Printer object MUST return this status code, even if there are other
-Job Template attributes that are not supported as well, since this error
-is a bigger problem than with Job Template attributes. See sections
-3.1.6.1, 3.1.7, and 3.2.1.1.
-
-
-13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
-
-In a create request, if the Printer object does not support one or more
-attributes, attribute syntaxes, or attribute values supplied in the
-request and the client supplied the "ipp-attribute-fidelity" operation
-attribute with the 'true' value, the Printer object MUST return this
-status code. The Printer object MUST also return in the Unsupported
-Attributes Group all the attributes and/or values supplied by the client
-that are not supported. See section 3.1.7. For example, if the request
-indicates 'iso-a4' media, but that media type is not supported by the
-Printer object. Or, if the client supplies a Job Template attribute and
-the attribute itself is not even supported by the Printer. If the "ipp-
-attribute-fidelity" attribute is 'false', the Printer MUST ignore or
-substitute values for unsupported Job Template attributes and values
-rather than reject the request and return this status code.
-
-For any operation where a client requests attributes (such as a Get-
-Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if the
-IPP object does not support one or more of the requested attributes, the
-IPP object simply ignores the unsupported requested attributes and
-processes the request as if they had not been supplied, rather than
-returning this status code. In this case, the IPP object MUST return
-the 'successful-ok-ignored-or-substituted-attributes' status code and
-MAY return the unsupported attributes as values of the "requested-
-attributes" in the Unsupported Attributes Group (see section 13.1.2.2).
-
-
-13.1.4.13 client-error-uri-scheme-not-supported (0x040C)
-
-The scheme of the client-supplied URI in a Print-URI or a Send-URI
-operation is not supported. See sections 3.1.6.1 and 3.1.7.
-
-
-13.1.4.14 client-error-charset-not-supported (0x040D)
-
-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). See sections 3.1.6.1 and 3.1.7.
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 163]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-13.1.4.15 client-error-conflicting-attributes (0x040E)
-
-The request is rejected because some attribute values conflicted with
-the values of other attributes which this document does not permit to be
-substituted or ignored. The Printer object MUST also return in the
-Unsupported Attributes Group the conflicting attributes supplied by the
-client. See sections 3.1.7 and 3.2.1.2.
-
-
-13.1.4.16 client-error-compression-not-supported (0x040F)
-
-The IPP object is refusing to service the request because the document
-data, as specified in the "compression" operation attribute, is
-compressed in a way that is not supported by the Printer object. This
-error is returned independent of the client-supplied "ipp-attribute-
-fidelity". The Printer object MUST return this status code, even if
-there are other Job Template attributes that are not supported as well,
-since this error is a bigger problem than with Job Template attributes.
-See sections 3.1.6.1, 3.1.7, and 3.2.1.1.
-
-
-13.1.4.17 client-error-compression-error (0x0410)
-
-The IPP object is refusing to service the request because the document
-data cannot be decompressed when using the algorithm specified by the
-"compression" operation attribute. This error is returned independent
-of the client-supplied "ipp-attribute-fidelity". The Printer object
-MUST return this status code, even if there are Job Template attributes
-that are not supported as well, since this error is a bigger problem
-than with Job Template attributes. See sections 3.1.7 and 3.2.1.1.
-
-
-13.1.4.18 client-error-document-format-error (0x0411)
-
-The IPP object is refusing to service the request because Printer
-encountered an error in the document data while interpreting it. This
-error is returned independent of the client-supplied "ipp-attribute-
-fidelity". The Printer object MUST return this status code, even if
-there are Job Template attributes that are not supported as well, since
-this error is a bigger problem than with Job Template attributes. See
-sections 3.1.7 and 3.2.1.1.
-
-
-13.1.4.19 client-error-document-access-error (0x0412)
-
-The IPP object is refusing to service the Print-URI or Send-URI request
-because Printer encountered an access error while attempting to validate
-the accessibility or access the document data specified in the
-"document-uri" operation attribute. The Printer MAY also return a
-specific document access error code using the "document-access-error"
-operation attribute (see section 3.1.6.4). This error is returned
-independent of the client-supplied "ipp-attribute-fidelity". The
-Printer object MUST return this status code, even if there are Job
-Template attributes that are not supported as well, since this error is
-a bigger problem than with Job Template attributes. See sections
-3.1.6.1 and 3.1.7.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 164]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-13.1.5 Server Error Status Codes
-
-This class of status codes indicates cases in which the IPP object is
-aware that it has erred or is incapable of performing the request. The
-IPP object SHOULD include a message containing an explanation of the
-error situation, and whether it is a temporary or permanent condition.
-
-
-13.1.5.1 server-error-internal-error (0x0500)
-
-The IPP object encountered an unexpected condition that prevented it
-from fulfilling the request. This error status code differs from
-"server-error-temporary-error" in that it implies a more permanent type
-of internal error. It also differs from "server-error-device-error" in
-that it implies an unexpected condition (unlike a paper-jam or out-of-
-toner problem which is undesirable but expected). This error status
-code indicates that probably some knowledgeable human intervention is
-required.
-
-
-13.1.5.2 server-error-operation-not-supported (0x0501)
-
-The IPP object does not support the functionality required to fulfill
-the request. This is the appropriate response when the IPP object does
-not recognize an operation or is not capable of supporting it. See
-sections 3.1.6.1 and 3.1.7.
-
-
-13.1.5.3 server-error-service-unavailable (0x0502)
-
-The IPP object is currently unable to handle the request due to a
-temporary overloading or maintenance of the IPP object. The implication
-is that this is a temporary condition which will be alleviated after
-some delay. If known, the length of the delay may be indicated in the
-message. If no delay is given, the IPP application should handle the
-response as it would for a "server-error-temporary-error" response. If
-the condition is more permanent, the error status codes "client-error-
-gone" or "client-error-not-found" could be used.
-
-
-13.1.5.4 server-error-version-not-supported (0x0503)
-
-The IPP object does not support, or refuses to support, the IPP protocol
-version that was supplied as the value of the "version-number" operation
-parameter in the request. The IPP object is indicating that it is
-unable or unwilling to complete the request using the same major and
-minor version number as supplied in the request other than with this
-error message. The error response SHOULD contain a "status-message"
-attribute (see section 3.1.6.2) describing why that version is not
-supported and what other versions are supported by that IPP object. See
-sections 3.1.6.1, 3.1.7, and 3.1.8.
-
-The error response MUST identify in the "version-number" operation
-parameter the closest version number that the IPP object does support.
-For example, if a client supplies version '1.0' and an IPP/1.1 object
-supports version '1.0', then it responds with version '1.0' in all
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 165]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-responses to such a request. If the IPP/1.1 object does not support
-version '1.0', then it should accept the request and respond with
-version '1.1' or may reject the request and respond with this error code
-and version '1.1'. If a client supplies a version '1.2', the IPP/1.1
-object should accept the request and return version '1.1' or may reject
-the request and respond with this error code and version '1.1'. See
-sections 3.1.8 and 4.4.14.
-
-
-13.1.5.5 server-error-device-error (0x0504)
-
-A printer error, such as a paper jam, occurs while the IPP object
-processes a Print or Send operation. The response contains the true Job
-Status (the values of the "job-state" and "job-state-reasons"
-attributes). Additional information can be returned in the OPTIONAL
-"job-state-message" attribute value or in the OPTIONAL status message
-that describes the error in more detail. This error status code is only
-returned in situations where the Printer is unable to accept the create
-request because of such a device error. For example, if the Printer is
-unable to spool, and can only accept one job at a time, the reason it
-might reject a create request is that the printer currently has a paper
-jam. In many cases however, where the Printer object can accept the
-request even though the Printer has some error condition, the
-'successful-ok' status code will be returned. In such a case, the
-client would look at the returned Job Object Attributes or later query
-the Printer to determine its state and state reasons.
-
-
-13.1.5.6 server-error-temporary-error (0x0505)
-
-A temporary error such as a buffer full write error, a memory overflow
-(i.e. the document data exceeds the memory of the Printer), or a disk
-full condition, occurs while the IPP Printer processes an operation.
-The client MAY try the unmodified request again at some later point in
-time with an expectation that the temporary internal error condition may
-have been cleared. Alternatively, as an implementation option, a
-Printer object MAY delay the response until the temporary condition is
-cleared so that no error is returned.
-
-
-13.1.5.7 server-error-not-accepting-jobs (0x0506)
-
-A temporary error indicating that the Printer is not currently accepting
-jobs, because the administrator has set the value of the Printer's
-"printer-is-accepting-jobs" attribute to 'false' (by means outside the
-scope of this IPP/1.1 document).
-
-
-13.1.5.8 server-error-busy (0x0507)
-
-A temporary error indicating that the Printer is too busy processing
-jobs and/or other requests. The client SHOULD try the unmodified request
-again at some later point in time with an expectation that the temporary
-busy condition will have been cleared.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 166]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-13.1.5.9 server-error-job-canceled (0x0508)
-
-An error indicating that the job has been canceled by an operator or the
-system while the client was transmitting the data to the IPP Printer.
-If a job-id and job-uri had been created, then they are returned in the
-Print-Job, Send-Document, or Send-URI response as usual; otherwise, no
-job-id and job-uri are returned in the response.
-
-
-13.1.5.10 server-error-multiple-document-jobs-not-supported (0x0509)
-
-The IPP object does not support multiple documents per job and a client
-attempted to supply document data with a second Send-Document or Send-
-URI operation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 167]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-13.2 Status Codes for IPP Operations
-
-PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document
-SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and
-Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
-
- IPP Operations
-IPP Status Keyword PJ PU CJ SD SU V GA GJ C
------------------- -- -- -- -- -- - -- -- -
-successful-ok x x x x x x x x x
-successful-ok-ignored-or-substituted- x x x x x x x x x
- attributes
-successful-ok-conflicting-attributes x x x x x x x x x
-client-error-bad-request x x x x x x x x x
-client-error-forbidden x x x x x x x x x
-client-error-not-authenticated x x x x x x x x x
-client-error-not-authorized x x x x x x x x x
-client-error-not-possible x x x x x x x x x
-client-error-timeout x x
-client-error-not-found x x x x x x x x x
-client-error-gone x x x x x x x x x
-client-error-request-entity-too-large x x x x x x x x x
-client-error-request-value-too-long x x x x x x x x x
-client-error-document-format-not- x x x x x x
- supported
-client-error-attributes-or-values-not- x x x x x x x x x
- supported
-client-error-uri-scheme-not-supported x x
-client-error-charset-not-supported x x x x x x x x x
-client-error-conflicting-attributes x x x x x x x x x
-client-error-compression-not-supported x x x x x
-client-error-compression-error x x x x
-client-error-document-format-error x x x x
-client-error-document-access-error x x
-server-error-internal-error x x x x x x x x x
-server-error-operation-not-supported x x x x
-server-error-service-unavailable x x x x x x x x x
-server-error-version-not-supported x x x x x x x x x
-server-error-device-error x x x x x
-server-error-temporary-error x x x x x
-server-error-not-accepting-jobs x x x x
-server-error-busy x x x x x x x x x
-server-error-job-canceled x x x
-server-error-multiple-document-jobs- x x
- not-supported
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 168]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-HJ = Hold-Job, RJ = Release-Job, RS = Restart-Job
-PP = Pause-Printer, RP = Resume-Printer, PJ = Purge-Jobs
-
- IPP Operations (cont.)
-IPP Status Keyword HJ RJ RS PP RP PJ
------------------- -- -- -- -- -- --
-successful-ok x x x x x x
-successful-ok-ignored-or-substituted- x x x x x x
- attributes
-successful-ok-conflicting-attributes x x x x x x
-client-error-bad-request x x x x x x
-client-error-forbidden x x x x x x
-client-error-not-authenticated x x x x x x
-client-error-not-authorized x x x x x x
-client-error-not-possible x x x x x x
-client-error-timeout
-client-error-not-found x x x x x x
-client-error-gone x x x x x x
-client-error-request-entity-too-large x x x x x x
-client-error-request-value-too-long x x x x x x
-client-error-document-format-not-
- supported
-client-error-attributes-or-values-not- x x x x x x
- supported
-client-error-uri-scheme-not-supported
-client-error-charset-not-supported x x x x x x
-client-error-conflicting-attributes x x x x x x
-client-error-compression-not-supported
-client-error-compression-error
-client-error-document-format-error
-client-error-document-access-error
-server-error-internal-error x x x x x x
-server-error-operation-not-supported x x x x x x
-server-error-service-unavailable x x x x x x
-server-error-version-not-supported x x x x x x
-server-error-device-error
-server-error-temporary-error x x x x x x
-server-error-not-accepting-jobs
-server-error-busy x x x x x x
-server-error-job-canceled
-server-error-multiple-document-jobs-
- not-supported
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 169]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-
-14. APPENDIX C: "media" keyword values
-
-14. APPENDIX C: "media" keyword values
-
-Standard keyword values are taken from several sources.
-
-Standard values are defined (taken from DPA[ISO10175] and the Printer
-MIB[RFC1759]):
-
- 'default': The default medium for the output device
- 'iso-a4-white': Specifies the ISO A4 white medium: 210 mm x 297 mm
- 'iso-a4-colored': Specifies the ISO A4 colored medium: 210 mm x 297
- mm
- 'iso-a4-transparent' Specifies the ISO A4 transparent medium: 210 mm
- x 297 mm
- 'iso-a3-white': Specifies the ISO A3 white medium: 297 mm x 420 mm
- 'iso-a3-colored': Specifies the ISO A3 colored medium: 297 mm x 420
- mm
- 'iso-a5-white': Specifies the ISO A5 white medium: 148 mm x 210 mm
- 'iso-a5-colored': Specifies the ISO A5 colored medium: 148 mm x 210
- mm
- 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm
- 'iso-b4-colored': Specifies the ISO B4 colored medium: 250 mm x 353
- mm
- 'iso-b5-white': Specifies the ISO B5 white medium: 176 mm x 250 mm
- 'iso-b5-colored': Specifies the ISO B5 colored medium: 176 mm x 250
- mm
- 'jis-b4-white': Specifies the JIS B4 white medium: 257 mm x 364 mm
- 'jis-b4-colored': Specifies the JIS B4 colored medium: 257 mm x 364
- mm
- 'jis-b5-white': Specifies the JIS B5 white medium: 182 mm x 257 mm
- 'jis-b5-colored': Specifies the JIS B5 colored medium: 182 mm x 257
- mm
-
-
-The following standard values are defined for North American media:
-
- 'na-letter-white': Specifies the North American letter white medium
- 'na-letter-colored': Specifies the North American letter colored
- medium
- 'na-letter-transparent': Specifies the North American letter
- transparent medium
- 'na-legal-white': Specifies the North American legal white medium
- 'na-legal-colored': Specifies the North American legal colored medium
-
-
-The following standard values are defined for envelopes:
-
- 'iso-b4-envelope': Specifies the ISO B4 envelope medium
- 'iso-b5-envelope': Specifies the ISO B5 envelope medium
- 'iso-c3-envelope': Specifies the ISO C3 envelope medium
- 'iso-c4-envelope': Specifies the ISO C4 envelope medium
- 'iso-c5-envelope': Specifies the ISO C5 envelope medium
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 170]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'iso-c6-envelope': Specifies the ISO C6 envelope medium
- 'iso-designated-long-envelope': Specifies the ISO Designated Long
- envelope medium
- 'na-10x13-envelope': Specifies the North American 10x13 envelope
- medium
- 'na-9x12-envelope': Specifies the North American 9x12 envelope medium
- 'monarch-envelope': Specifies the Monarch envelope
- 'na-number-10-envelope': Specifies the North American number 10
- business envelope medium
- 'na-7x9-envelope': Specifies the North American 7x9 inch envelope
- 'na-9x11-envelope': Specifies the North American 9x11 inch envelope
- 'na-10x14-envelope': Specifies the North American 10x14 inch envelope
- 'na-number-9-envelope': Specifies the North American number 9
- business envelope
- 'na-6x9-envelope': Specifies the North American 6x9 inch envelope
- 'na-10x15-envelope': Specifies the North American 10x15 inch envelope
-
-
-The following standard values are defined for the less commonly used
-media-:
-
- 'executive-white': Specifies the white executive medium
- 'folio-white': Specifies the folio white medium
- 'invoice-white': Specifies the white invoice medium
- 'ledger-white': Specifies the white ledger medium
- 'quarto-white': Specified the white quarto medium
- 'iso-a0-white': Specifies the ISO A0 white medium: 841 mm x 1189 mm
- 'iso-a0-transparent': Specifies the ISO A0 transparent medium: 841 mm
- x 1189 mm
- 'iso-a0-translucent': Specifies the ISO A0 translucent medium: 841 mm
- x 1189 mm
- 'iso-a1-white': Specifies the ISO A1 white medium: 594 mm x 841 mm
- 'iso-a1-transparent': Specifies the ISO A1 transparent medium: 594 mm
- x 841 mm
- 'iso-a1-translucent': Specifies the ISO A1 translucent medium: 594 mm
- x 841 mm
- 'iso-a2-white': Specifies the ISO A2 white medium: 420 mm x 594 mm
- 'iso-a2-transparent': Specifies the ISO A2 transparent medium: 420 mm
- x 594 mm
- 'iso-a2-translucent': Specifies the ISO A2 translucent medium: 420 mm
- x 594 mm
- 'iso-a3-transparent': Specifies the ISO A3 transparent medium: 297 mm
- x 420 mm
- 'iso-a3-translucent': Specifies the ISO A3 translucent medium: 297 mm
- x 420 mm
- 'iso-a4-translucent': Specifies the ISO A4 translucent medium: 210 mm
- x 297 mm
- 'iso-a5-transparent': Specifies the ISO A5 transparent medium: 148 mm
- x 210 mm
- 'iso-a5-translucent': Specifies the ISO A5 translucent medium: 148 mm
- x 210 mm
- 'iso-a6-white': Specifies the ISO A6 white medium: 105 mm x 148 mm
- 'iso-a7-white': Specifies the ISO A7 white medium: 74 mm x 105 mm
- 'iso-a8-white': Specifies the ISO A8 white medium: 52 mm x 74 mm
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 171]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'iso-a9-white': Specifies the ISO A9 white medium: 37 mm x 52 mm
- 'iso-10-white': Specifies the ISO A10 white medium: 26 mm x 37 mm
- 'iso-b0-white': Specifies the ISO B0 white medium: 1000 mm x 1414 mm
- 'iso-b1-white': Specifies the ISO B1 white medium: 707 mm x 1000 mm
- 'iso-b2-white': Specifies the ISO B2 white medium: 500 mm x 707 mm
- 'iso-b3-white': Specifies the ISO B3 white medium: 353 mm x 500 mm
- 'iso-b6-white': Specifies the ISO B6 white medium: 125 mm x 176 mm
- 'iso-b7-white': Specifies the ISO B7 white medium: 88 mm x 125 mm
- 'iso-b8-white': Specifies the ISO B8 white medium: 62 mm x 88 mm
- 'iso-b9-white': Specifies the ISO B9 white medium: 44 mm x 62 mm
- 'iso-b10-white': Specifies the ISO B10 white medium: 31 mm x 44 mm
- 'jis-b0-white': Specifies the JIS B0 white medium: 1030 mm x 1456 mm
- 'jis-b0-transparent': Specifies the JIS B0 transparent medium: 1030
- mm x 1456 mm
- 'jis-b0-translucent': Specifies the JIS B0 translucent medium: 1030
- mm x 1456 mm
- 'jis-b1-white': Specifies the JIS B1 white medium: 728 mm x 1030 mm
- 'jis-b1-transparent': Specifies the JIS B1 transparent medium: 728 mm
- x 1030 mm
- 'jis-b1-translucent': Specifies the JIS B1 translucent medium: 728 mm
- x 1030 mm
- 'jis-b2-white': Specifies the JIS B2 white medium: 515 mm x 728 mm
- 'jis-b2-transparent': Specifies the JIS B2 transparent medium: 515 mm
- x 728 mm
- 'jis-b2-translucent': Specifies the JIS B2 translucent medium: 515 mm
- x 728 mm
- 'jis-b3-white': Specifies the JIS B3 white medium: 364 mm x 515 mm
- 'jis-b3-transparent': Specifies the JIS B3 transparent medium: 364 mm
- x 515 mm
- 'jis-b3-translucent': Specifies the JIS B3 translucent medium: 364 mm
- x 515 mm
- 'jis-b4-transparent': Specifies the JIS B4 transparent medium: 257 mm
- x 364 mm
- 'jis-b4-translucent': Specifies the JIS B4 translucent medium: 257 mm
- x 364 mm
- 'jis-b5-transparent': Specifies the JIS B5 transparent medium: 182 mm
- x 257 mm
- 'jis-b5-translucent': Specifies the JIS B5 translucent medium: 182 mm
- x 257 mm
- 'jis-b6-white': Specifies the JIS B6 white medium: 128 mm x 182 mm
- 'jis-b7-white': Specifies the JIS B7 white medium: 91 mm x 128 mm
- 'jis-b8-white': Specifies the JIS B8 white medium: 64 mm x 91 mm
- 'jis-b9-white': Specifies the JIS B9 white medium: 45 mm x 64 mm
- 'jis-b10-white': Specifies the JIS B10 white medium: 32 mm x 45 mm
-
-
-The following standard values are defined for American Standard (i.e.
-ANSI) engineering media:
-
- 'a-white': Specifies the engineering ANSI A size white medium: 8.5
- inches x 11 inches
- 'a-transparent': Specifies the engineering ANSI A size transparent
- medium: 8.5 inches x 11 inches
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 172]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'a-translucent': Specifies the engineering ANSI A size translucent
- medium: 8.5 inches x 11 inches
- 'b-white': Specifies the engineering ANSI B size white medium: 11
- inches x 17 inches
- 'b-transparent': Specifies the engineering ANSI B size transparent
- medium: 11 inches x 17 inches)
- 'b-translucent': Specifies the engineering ANSI B size translucent
- medium: 11 inches x 17 inches
- 'c-white': Specifies the engineering ANSI C size white medium: 17
- inches x 22 inches
- 'c-transparent': Specifies the engineering ANSI C size transparent
- medium: 17 inches x 22 inches
- 'c-translucent': Specifies the engineering ANSI C size translucent
- medium: 17 inches x 22 inches
- 'd-white': Specifies the engineering ANSI D size white medium: 22
- inches x 34 inches
- 'd-transparent': Specifies the engineering ANSI D size transparent
- medium: 22 inches x 34 inches
- 'd-translucent': Specifies the engineering ANSI D size translucent
- medium: 22 inches x 34 inches
- 'e-white': Specifies the engineering ANSI E size white medium: 34
- inches x 44 inches
- 'e-transparent': Specifies the engineering ANSI E size transparent
- medium: 34 inches x 44 inches
- 'e-translucent': Specifies the engineering ANSI E size translucent
- medium: 34 inches x 44 inches
-
-
-The following standard values are defined for American Standard (i.e.
-ANSI) engineering media for devices that provide the "synchro-cut"
-feature (see section 14.1):
-
- 'axsynchro-white': Specifies the roll paper having the width of the
- longer edge (11 inches) of the engineering ANSI A size white medium
- and cuts synchronizing with data.
- 'axsynchro-transparent': Specifies the roll paper having the width of
- the longer edge (11 inches) of the engineering ANSI A size
- transparent medium and cuts synchronizing with data.
- 'axsynchro-translucent': Specifies the roll paper having the width of
- the longer edge (11 inches) of the engineering ANSI A size
- translucent medium and cuts synchronizing with data.
- 'bxsynchro-white': Specifies the roll paper having the width of the
- longer edge (17 inches) of the engineering ANSI B size white medium
- and cuts synchronizing with data.
- 'bxsynchro-transparent': Specifies the roll paper having the width of
- the longer edge (17 inches) of the engineering ANSI B size
- transparent medium and cuts synchronizing with data.
- 'bxsynchro-translucent': Specifies the roll paper having the width of
- the longer edge (17 inches) of the engineering ANSI B size
- translucent medium and cuts synchronizing with data.
- 'cxsynchro-white': Specifies the roll paper having the width of the
- longer edge (22 inches) of the engineering ANSI C size white medium
- and cuts synchronizing with data.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 173]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'cxsynchro-transparent': Specifies the roll paper having the width of
- the longer edge (22 inches) of the engineering ANSI C size
- transparent medium and cuts synchronizing with data.
- 'cxsynchro-translucent': Specifies the roll paper having the width of
- the longer edge (22 inches) of the engineering ANSI C size
- translucent medium and cuts synchronizing with data.
- 'dxsynchro-white': Specifies the roll paper having the width of the
- longer edge (34 inches) of the engineering ANSI D size white medium
- and cuts synchronizing with data.
- 'dxsynchro-transparent': Specifies the roll paper having the width of
- the longer edge (34 inches) of the engineering ANSI D size
- transparent medium and cuts synchronizing with data.
- 'dxsynchro-translucent': Specifies the roll paper having the width of
- the longer edge (34 inches) of the engineering ANSI D size
- translucent medium and cuts synchronizing with data.
- 'exsynchro-white': Specifies the roll paper having the width of the
- longer edge (44 inches) of the engineering ANSI E size white medium
- and cuts synchronizing with data.
- 'exsynchro-transparent': Specifies the roll paper having the width of
- the longer edge (44 inches) of the engineering ANSI E size
- transparent medium and cuts synchronizing with data.
- 'exsynchro-translucent': Specifies the roll paper having the width of
- the longer edge (44 inches) of the engineering ANSI E size
- translucent medium and cuts synchronizing with data.
-
-
-The following standard values are defined for American Architectural
-engineering media:
-
- 'arch-a-white': Specifies the Architectural A size white medium: 9
- inches x 12 inches
- 'arch-a-transparent': Specifies the Architectural A size transparent
- medium: 9 inches x 12 inches
- 'arch-a-translucent': Specifies the Architectural A size translucent
- medium: 9 inches x 12 inches
- 'arch-b-white': Specifies the Architectural B size white medium: 12
- inches x 18 inches
- 'arch-b-transparent': Specifies the Architectural B size transparent
- medium: 12 inches x 18 inches
- 'arch-b-translucent': Specifies the Architectural B size translucent
- medium: 12 inches x 18 inches
- 'arch-c-white': Specifies the Architectural C size white medium: 18
- inches x 24 inches
- 'arch-c-transparent': Specifies the Architectural C size transparent
- medium: 18 inches x 24 inches
- 'arch-c-translucent': Specifies the Architectural C size translucent
- medium: 18 inches x 24 inches
- 'arch-d-white': Specifies the Architectural D size white medium: 24
- inches x 36 inches
- 'arch-d-transparent': Specifies the Architectural D size transparent
- medium: 24 inches x 36 inches
- 'arch-d-translucent': Specifies the Architectural D size translucent
- medium: 24 inches x 36 inches
- 'arch-e-white': Specifies the Architectural E size white medium: 36
- inches x 48 inches
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 174]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'arch-e-transparent': Specifies the Architectural E size transparent
- medium: 36 inches x 48 inches
- 'arch-e-translucent': Specifies the Architectural E size translucent
- medium: 36 inches x 48 inches
-
-
-The following standard values are defined for American Architectural
-engineering media for devices that provide the "synchro-cut" feature
-(see section 14.1):
-
- 'arch-axsynchro-white': Specifies the roll paper having the width of
- the longer edge (12 inches) of the Architectural A size white
- medium and cuts synchronizing with data.
- 'arch-axsynchro-transparent': Specifies the roll paper having the
- width of the longer edge (12 inches) of the Architectural A size
- transparent medium and cuts synchronizing with data.
- 'arch-axsynchro-translucent': Specifies the roll paper having the
- width of the longer edge (12 inches) of the Architectural A size
- translucent medium and cuts synchronizing with data.
- 'arch-bxsynchro-white': Specifies the roll paper having the width of
- the longer edge (18 inches) of the Architectural B size white
- medium and cuts synchronizing with data.
- 'arch-bxsynchro-transparent': Specifies the roll paper having the
- width of the longer edge (18 inches) of the Architectural B size
- transparent medium and cuts synchronizing with data.
- 'arch-bxsynchro-translucent': Specifies the roll paper having the
- width of the longer edge (18 inches) of the Architectural B size
- translucent medium and cuts synchronizing with data.
- 'arch-cxsynchro-white': Specifies the roll paper having the width of
- the longer edge (24 inches) of the Architectural C size white
- medium and cuts synchronizing with data.
- 'arch-cxsynchro-transparent': Specifies the roll paper having the
- width of the longer edge (24 inches) of the Architectural C size
- transparent medium and cuts synchronizing with data.
- 'arch-cxsynchro-translucent': Specifies the roll paper having the
- width of the longer edge (24 inches) of the Architectural C size
- translucent medium and cuts synchronizing with data.
- 'arch-dxsynchro-white': Specifies the roll paper having the width of
- the longer edge (36 inches) of the Architectural D size white
- medium and cuts synchronizing with data.
- 'arch-dxsynchro-transparent': Specifies the roll paper having the
- width of the longer edge (36 inches) of the Architectural D size
- transparent medium and cuts synchronizing with data.
- 'arch-dxsynchro-translucent': Specifies the roll paper having the
- width of the longer edge (36 inches) of the Architectural D size
- translucent medium and cuts synchronizing with data.
- 'arch-exsynchro-white': Specifies the roll paper having the width of
- the longer edge (48 inches) of the Architectural E size white
- medium and cuts synchronizing with data.
- 'arch-exsynchro-transparent': Specifies the roll paper having the
- width of the longer edge (48 inches) of the Architectural E size
- transparent medium and cuts synchronizing with data.
- 'arch-exsynchro-translucent': Specifies the roll paper having the
- width of the longer edge (48 inches) of the Architectural E size
- translucent medium and cuts synchronizing with data.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 175]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-The following standard values are defined for Japanese and European
-Standard (i.e. ISO) engineering media, which are of a long fixed size
-[ASME-Y14.1M]:
-
- 'iso-a1x3-white': Specifies the ISO A1X3 white medium having the
- width of the longer edge (841 mm) of the ISO A1 medium
- 'iso-a1x3-transparent': Specifies the ISO A1X3 transparent medium
- having the width of the longer edge (841 mm) of the ISO A1
- medium
- 'iso-a1x3-translucent': Specifies the ISO A1X3 translucent medium
- having the width of the longer edge (841 mm) of the ISO A1
- medium
- 'iso-a1x4-white': Specifies the ISO A1X4 white medium having the
- width of the longer edge (841 mm) of the ISO A1 medium
- 'iso-a1x4-transparent': Specifies the ISO A1X4 transparent medium
- having the width of the longer edge (841 mm) of the ISO A1
- medium
- 'iso-a1x4- translucent': Specifies the ISO A1X4 translucent medium
- having the width of the longer edge (841 mm) of the ISO A1
- medium
- 'iso-a2x3-white': Specifies the ISO A2X3 white medium having the
- width of the longer edge (594 mm) of the ISO A2 medium
- 'iso-a2x3-transparent': Specifies the ISO A2X3 transparent medium
- having the width of the longer edge (594 mm) of the ISO A2
- medium
- 'iso-a2x3-translucent': Specifies the ISO A2X3 translucent medium
- having the width of the longer edge (594 mm) of the ISO A2
- medium
- 'iso-a2x4-white': Specifies the ISO A2X4 white medium having the
- width of the longer edge (594 mm) of the ISO A2 medium
- 'iso-a2x4-transparent': Specifies the ISO A2X4 transparent medium
- having the width of the longer edge (594 mm) of the ISO A2
- medium
- 'iso-a2x4-translucent': Specifies the ISO A2X4 translucent medium
- having the width of the longer edge (594 mm) of the ISO A2
- medium
- 'iso-a2x5-white': Specifies the ISO A2X5 white medium having the
- width of the longer edge (594 mm) of the ISO A2 medium
- 'iso-a2x5-transparent': Specifies the ISO A2X5 transparent medium
- having the width of the longer edge (594 mm) of the ISO A2
- medium
- 'iso-a2x5-translucent': Specifies the ISO A2X5 translucent medium
- having the width of the longer edge (594 mm) of the ISO A2
- medium
- 'iso-a3x3-white': Specifies the ISO A3X3 white medium having the
- width of the longer edge (420 mm) of the ISO A3 medium
- 'iso-a3x3-transparent': Specifies the ISO A3X3 transparent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x3-translucent': Specifies the ISO A3X3 translucent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 176]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'iso-a3x4-white': Specifies the ISO A3X4 white medium having the
- width of the longer edge (420 mm) of the ISO A3 medium
- 'iso-a3x4-transparent': Specifies the ISO A3X4 transparent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x4-translucent': Specifies the ISO A3X4 translucent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x5-white': Specifies the ISO A3X5 white medium having the
- width of the longer edge (420 mm) of the ISO A3 medium
- 'iso-a3x5-transparent': Specifies the ISO A3X5 transparent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x5-translucent': Specifies the ISO A3X5 translucent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x6-white': Specifies the ISO A3X6 white medium having the
- width of the longer edge (420 mm) of the ISO A3 medium
- 'iso-a3x6-transparent': Specifies the ISO A3X6 transparent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x6-translucent': Specifies the ISO A3X6 translucent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x7-white': Specifies the ISO A3X7 white medium having the
- width of the longer edge (420 mm) of the ISO A3 medium
- 'iso-a3x7-transparent': Specifies the ISO A3X7 transparent medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a3x7-translucent'': Specifies the ISO A3X7 translucent' medium
- having the width of the longer edge (420 mm) of the ISO A3
- medium
- 'iso-a4x3-white': Specifies the ISO A4X3 white medium having the
- width of the longer edge (297 mm) of the ISO A4 medium
- 'iso-a4x3-transparent': Specifies the ISO A4X3 transparent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x3-translucent'': Specifies the ISO A4X3 translucent' medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x4-white': Specifies the ISO A4X4 white medium having the
- width of the longer edge (297 mm) of the ISO A4 medium
- 'iso-a4x4-transparent': Specifies the ISO A4X4 transparent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x4-translucent': Specifies the ISO A4X4 translucent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x5-white': Specifies the ISO A4X5 white medium having the
- width of the longer edge (297 mm) of the ISO A4 medium
- 'iso-a4x5-transparent': Specifies the ISO A4X5 transparent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 177]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'iso-a4x5-translucent': Specifies the ISO A4X5 translucent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x6-white': Specifies the ISO A4X6 white medium having the
- width of the longer edge (297 mm) of the ISO A4 medium
- 'iso-a4x6-transparent': Specifies the ISO A4X6 transparent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x6-translucent': Specifies the ISO A4X6 translucent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x7-white': Specifies the ISO A4X7 white medium having the
- width of the longer edge (297 mm) of the ISO A4 medium
- 'iso-a4x7-transparent': Specifies the ISO A4X7 transparent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x7-translucent': Specifies the ISO A4X7 translucent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x8-white': Specifies the ISO A4X8 white medium having the
- width of the longer edge (297 mm) of the ISO A4 medium
- 'iso-a4x8-transparent': Specifies the ISO A4X8 transparent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x8-translucent': Specifies the ISO A4X8 translucent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x9-white': Specifies the ISO A4X9 white medium having the
- width of the longer edge (297 mm) of the ISO A4 medium
- 'iso-a4x9-transparent': Specifies the ISO A4X9 transparent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
- 'iso-a4x9-translucent': Specifies the ISO A4X9 translucent medium
- having the width of the longer edge (297 mm) of the ISO A4
- medium
-
-
-The following standard values are defined for Japanese and European
-Standard (i.e. ISO) engineering media, which are either a long fixed
-size [ASME-Y14.1M] or roll feed, for devices that provide the "synchro-
-cut" feature (see section 14.1):
-
- 'iso-a0xsynchro-white': Specifies the paper having the width of the
- longer edge (1189 mm) of the ISO A0 white medium and cuts
- synchronizing with data.
- 'iso-a0xsynchro-transparent': Specifies the paper having the width of
- the longer edge (1189 mm) of the ISO A0 transparent medium and
- cuts synchronizing with data.
- 'iso-a0xsynchro-translucent': Specifies the paper having the width of
- the longer edge (1189 mm) of the ISO A0 translucent medium and
- cuts synchronizing with data.
- 'iso-a1xsynchro-white': Specifies the paper having the width of the
- longer edge (841 mm) of the ISO A1 white medium and cuts
- synchronizing with data.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 178]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'iso-a1xsynchro-transparent': Specifies the paper having the width of
- the longer edge (841 mm) of the ISO A1 transparent medium and
- cuts synchronizing with data.
- 'iso-a1xsynchro-translucent': Specifies the paper having the width of
- the longer edge (841 mm) of the ISO A1 translucent medium and
- cuts synchronizing with data.
- 'iso-a2xsynchro-white': Specifies the paper having the width of the
- longer edge (594 mm) of the ISO A2 white medium and cuts
- synchronizing with data.
- 'iso-a2xsynchro-transparent': Specifies the paper having the width of
- the longer edge (594 mm) of the ISO A2 transparent medium and
- cuts synchronizing with data.
- 'iso-a2xsynchro-translucent': Specifies the paper having the width of
- the longer edge (594 mm) of the ISO A2 translucent medium and
- cuts synchronizing with data.
- 'iso-a3xsynchro-white': Specifies the paper having the width of the
- longer edge (420 mm) of the ISO A3 white medium and cuts
- synchronizing with data.
- 'iso-a3xsynchro-transparent': Specifies the paper having the width of
- the longer edge (420 mm) of the ISO A3 transparent medium and
- cuts synchronizing with data.
- 'iso-a3xsynchro-translucent': Specifies the paper having the width of
- the longer edge (420 mm) of the ISO A3 translucent medium and
- cuts synchronizing with data.
- 'iso-a4xsynchro-white': Specifies the paper having the width of the
- longer edge (297 mm) of the ISO A4 white medium and cuts
- synchronizing with data.
- 'iso-a4xsynchro-transparent': Specifies the paper having the width of
- the longer edge (297 mm) of the ISO A4 transparent medium and
- cuts synchronizing with data.
- 'iso-a4xsynchro-translucent': Specifies the paper having the width of
- the longer edge (297 mm) of the ISO A4 transparent medium and
- cuts synchronizing with data.
-
-
-The following standard values are defined for American Standard (i.e.
-ANSI) engineering media, American Architectural engineering media, and
-Japanese and European Standard (i.e. ISO) engineering media, which are
-either a long fixed size [ASME-Y14.1M] or roll feed, for devices that
-provide the "synchro-cut" feature and/or the "auto-select" feature (see
-section 14.1):
-
- 'auto-white': Specifies that the printer selects the white medium
- with the appropriate fixed size (e.g. a1, a2, etc.) or data-
- synchro size, and the selection is implementation-defined.
- 'auto-transparent': Specifies that the printer selects the
- transparent medium with the appropriate fixed size (e.g. a1, a2,
- etc.) or data-synchro size, and the selection is implementation-
- defined.
- 'auto-translucent': Specifies that the printer selects the
- translucent medium with the appropriate fixed size (e.g. a1, a2,
- etc.) or data-synchro size, and the selection is implementation-
- defined.
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 179]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'auto-fixed-size-white': Specifies that the printer selects the white
- medium with the appropriate fixed size (e.g. a1, a2, etc.) or
- the appropriate long fixed size listed above.
- 'auto-fixed-size-transparent': Specifies that the printer selects the
- transparent medium with the appropriate fixed size (e.g. a1, a2,
- etc.) or the appropriate long fixed size listed above.
- 'auto-fixed-size-translucent': Specifies that the printer selects the
- translucent medium with the appropriate fixed size (e.g. a1, a2,
- etc.) or the appropriate long fixed size listed above.
- 'auto-synchro-white': Specifies that the printer selects the white
- paper with the appropriate width and cuts it synchronizing with
- data.
- 'auto-synchro-transparent': Specifies that the printer selects the
- transparent paper with the appropriate width and cuts it
- synchronizing with data.
- 'auto-synchro-translucent': Specifies that the printer selects the
- translucent paper with the appropriate width and cuts it
- synchronizing with data.
-
-
-The following standard values are defined for input-trays (from ISO DPA
-and the Printer MIB):
-
- 'top': The top input tray in the printer.
- 'middle': The middle input tray in the printer.
- 'bottom': The bottom input tray in the printer.
- 'envelope': The envelope input tray in the printer.
- 'manual': The manual feed input tray in the printer.
- 'large-capacity': The large capacity input tray in the printer.
- 'main': The main input tray
- 'side': The side input tray
-
-
-The following standard values are defined for media sizes (from ISO
-DPA):
-
- 'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined in
- ISO 216
- 'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
- ISO 216
- 'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
- ISO 216
- 'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
- ISO 216
- 'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
- ISO 216
- 'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
- ISO 216
- 'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
- ISO 216
- 'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
- ISO 216
- 'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in ISO
- 216
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 180]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in ISO
- 216
- 'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
- ISO 216
- 'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined in
- ISO 216
- 'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined in
- ISO 216
- 'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
- ISO 216
- 'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
- ISO 216
- 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
- ISO 216
- 'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
- ISO 216
- 'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
- ISO 216
- 'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
- ISO 216
- 'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in ISO
- 216
- 'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in ISO
- 216
- 'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
- ISO 216
- 'na-letter': Specifies the North American letter size: 8.5 inches by
- 11 inches
- 'na-legal': Specifies the North American legal size: 8.5 inches by 14
- inches
- 'na-8x10': Specifies the North American 8 inches by 10 inches
- 'na-5x7': Specifies the North American 5 inches by 7 inches
- 'executive': Specifies the executive size (7.25 X 10.5 in)
- 'folio': Specifies the folio size (8.5 X 13 in)
- 'invoice': Specifies the invoice size (5.5 X 8.5 in)
- 'ledger': Specifies the ledger size (11 X 17 in)
- 'quarto': Specifies the quarto size (8.5 X 10.83 in)
- 'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
- ISO 269
- 'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
- ISO 269
- 'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
- ISO 269
- 'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
- ISO 269
- 'iso-designated-long': Specifies the ISO Designated Long size: 110 mm
- by 220 mm as defined in ISO 269
- 'na-10x13-envelope': Specifies the North American 10x13 size: 10
- inches by 13 inches
- 'na-9x12-envelope': Specifies the North American 9x12 size: 9 inches
- by 12 inches
- 'na-number-10-envelope': Specifies the North American number 10
- business envelope size: 4.125 inches by 9.5 inches
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 181]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'na-7x9-envelope': Specifies the North American 7x9 inch envelope
- size
- 'na-9x11-envelope': Specifies the North American 9x11 inch envelope
- size
- 'na-10x14-envelope': Specifies the North American 10x14 inch envelope
- size
- 'na-number-9-envelope': Specifies the North American number 9
- business envelope size
- 'na-6x9-envelope': Specifies the North American 6x9 envelope size
- 'na-10x15-envelope': Specifies the North American 10x15 envelope size
- 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
- in)
- 'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
- 'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
- 'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
- 'jis-b3': Specifies the JIS B3 size: 364mm x 515mm
- 'jis-b4': Specifies the JIS B4 size: 257mm x 364mm
- 'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
- 'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
- 'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
- 'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
- 'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
- 'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
-
-The following standard values are defined for American Standard (i.e.
-ANSI) engineering media sizes:
-
- 'a': Specifies the engineering ANSI A size medium: 8.5 inches x 11
- inches
- 'b': Specifies the engineering ANSI B size medium: 11 inches x 17
- inches
- 'c': Specifies the engineering ANSI C size medium: 17 inches x 22
- inches
- 'd': Specifies the engineering ANSI D size medium: 22 inches x 34
- inches
- 'e': Specifies the engineering ANSI E size medium: 34 inches x 44
- inches
-
-
-The following standard values are defined for American Architectural
-engineering media sizes:
-
- 'arch-a': Specifies the Architectural A size medium: 9 inches x 12
- inches
- 'arch-b': Specifies the Architectural B size medium: 12 inches x 18
- inches
- 'arch-c': Specifies the Architectural C size medium: 18 inches x 24
- inches
- 'arch-d': Specifies the Architectural D size medium: 24 inches x 36
- inches
- 'arch-e': Specifies the Architectural E size medium: 36 inches x 48
- inches
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 182]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-14.1.Examples
-
-Below are examples to supplement the engineering media value
-definitions.
-
-Example 1: "Synchro-Cut", a device cutting the roll paper in
-synchronization with the data
-
- data height: A1 height
- data width (shaded): A1 width < data width < (A1 width) x 2
- specified value: 'iso-a1xsynchro-white'
-
- | |
- |<--- data width --->|
- | |
- | | | |
- |<- A1 width ->|<- A1 width ->|
- | | | |
- cross ^ | | | |
- feed | +--------------------------------------------/
- direction | |//////////////|/////| | ^ /
- | |//////////////|/////| | | /
- | |//////////////|/////| | | /
- | |//////////////|/////| | | \
-<-----------+- |//////////////|/////| | A1 \ roll
-feed | |//////////////|/////| | height \ paper
-direction |//////////////|/////| | | \
- |//////////////|/////| | | /
- |//////////////|/////| | v /
- +------------------------------------------/
- |
- |
- |<------ CUT HERE (to synchronize
- | with data width)
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 183]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-Example 2: "Auto-Cut", a device cutting the roll paper at multiples of
-fixed-size media width
- data height: A1 height
- data width (shaded): A1 width < data width < (A1 width) x 2
- specified value: 'auto-fixed-size-white'
-
-
- | |
- |<--- data width --->|
- | |
- | | | |
- |<- A1 width ->|<- A1 width ->|
- | | | |
- cross ^ | | | |
- feed | +--------------------------------------------/
- direction | |//////////////|/////| | ^ /
- | |//////////////|/////| | | /
- | |//////////////|/////| | | /
- | |//////////////|/////| | | \
-<-----------+- |//////////////|/////| | A1 \ roll
-feed | |//////////////|/////| | height \ paper
-direction |//////////////|/////| | | \
- |//////////////|/////| | | /
- |//////////////|/////| | v /
- +------------------------------------------/
- |
- |
- |<--- CUT HERE
- | (to synchronize
- | with data width)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 184]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-
-Example 3: the 'iso-a4x4-white' fixed size paper
-
- paper height: A4 height
- paper width: (A4 width) x 4
- specified value: 'iso-a4x4-white'
-
-| | | | |
-|<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->|
-| | | | |
-| | | | |
-+-----------------------------------------------------------+
-| ^ | | | |
-| | | | | |
-| | | | | |
-| A4 | | | |
-| height | | | |
-| | | | | |
-| | | | | |
-| | | | | |
-| v | | | |
-+-----------------------------------------------------------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 185]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-
-Example 4: "Synchro-Cut", a device cutting the fixed size paper in
-synchronization with the data
-
- data height: A4 height
- data width (shaded): (A4 width) x 2 < data width < (A4 width) x 3
- specified value: 'iso-a4xsynchro-white'
-
- | |
- |<---------- data width ----------->|
- | |
- | | | | |
- |<- A4 width ->|<- A4 width ->|<- A4 width ->|
- | | | | |
- cross ^ | | | | |
- feed | +--------------------------------------------+
- direction | |//////////////|//////////////|/////| ^ |
- | |//////////////|//////////////|/////| | |
- | |//////////////|//////////////|/////| | |
- | |//////////////|//////////////|/////| | |
-<-----------+- |//////////////|//////////////|/////| A4 |
-feed | |//////////////|//////////////|/////| height |
-direction |//////////////|//////////////|/////| | |
- |//////////////|//////////////|/////| | |
- |//////////////|//////////////|/////| v |
- +--------------------------------------------+
- |
- CUT HERE ---->|
- (to synchronize |
- with data width) |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 186]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-Standard keyword values are taken from several sources.
-
-Standard values are defined (taken from DPA[ISO10175] and the Printer
-MIB[RFC1759]):
-
- 'default': The default medium for the output device
- 'iso-a4-white': Specifies the ISO A4 white medium
- 'iso-a4-colored': Specifies the ISO A4 colored medium
- 'iso-a4-transparent' Specifies the ISO A4 transparent medium
- 'iso-a3-white': Specifies the ISO A3 white medium
- 'iso-a3-colored': Specifies the ISO A3 colored medium
- 'iso-a5-white': Specifies the ISO A5 white medium
- 'iso-a5-colored': Specifies the ISO A5 colored medium
- 'iso-b4-white': Specifies the ISO B4 white medium
- 'iso-b4-colored': Specifies the ISO B4 colored medium
- 'iso-b5-white': Specifies the ISO B5 white medium
- 'iso-b5-colored': Specifies the ISO B5 colored medium
- 'jis-b4-white': Specifies the JIS B4 white medium
- 'jis-b4-colored': Specifies the JIS B4 colored medium
- 'jis-b5-white': Specifies the JIS B5 white medium
- 'jis-b5-colored': Specifies the JIS B5 colored medium
-
-
-The following standard values are defined for North American media:
-
- 'na-letter-white': Specifies the North American letter white medium
- 'na-letter-colored': Specifies the North American letter colored
- medium
- 'na-letter-transparent': Specifies the North American letter
- transparent medium
- 'na-legal-white': Specifies the North American legal white medium
- 'na-legal-colored': Specifies the North American legal colored medium
-
-
-The following standard values are defined for envelopes:
-
- 'iso-b4-envelope': Specifies the ISO B4 envelope medium
- 'iso-b5-envelope': Specifies the ISO B5 envelope medium
- 'iso-c3-envelope': Specifies the ISO C3 envelope medium
- 'iso-c4-envelope': Specifies the ISO C4 envelope medium
- 'iso-c5-envelope': Specifies the ISO C5 envelope medium
- 'iso-c6-envelope': Specifies the ISO C6 envelope medium
- 'iso-designated-long-envelope': Specifies the ISO Designated Long
- envelope medium
- 'na-10x13-envelope': Specifies the North American 10x13 envelope
- medium
- 'na-9x12-envelope': Specifies the North American 9x12 envelope medium
- 'monarch-envelope': Specifies the Monarch envelope
- 'na-number-10-envelope': Specifies the North American number 10
- business envelope medium
- 'na-7x9-envelope': Specifies the North American 7x9 inch envelope
- 'na-9x11-envelope': Specifies the North American 9x11 inch envelope
- 'na-10x14-envelope': Specifies the North American 10x14 inch envelope
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 187]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'na-number-9-envelope': Specifies the North American number 9
- business envelope
- 'na-6x9-envelope': Specifies the North American 6x9 inch envelope
- 'na-10x15-envelope': Specifies the North American 10x15 inch envelope
-
-
-The following standard values are defined for the less commonly used
-media (white-only):
-
- 'executive-white': Specifies the white executive medium
- 'folio-white': Specifies the folio white medium
- 'invoice-white': Specifies the white invoice medium
- 'ledger-white': Specifies the white ledger medium
- 'quarto-white': Specified the white quarto medium
- 'iso-a0-white': Specifies the ISO A0 white medium
- 'iso-a1-white': Specifies the ISO A1 white medium
- 'iso-a2-white': Specifies the ISO A2 white medium
- 'iso-a6-white': Specifies the ISO A6 white medium
- 'iso-a7-white': Specifies the ISO A7 white medium
- 'iso-a8-white': Specifies the ISO A8 white medium
- 'iso-a9-white': Specifies the ISO A9 white medium
- 'iso-10-white': Specifies the ISO A10 white medium
- 'iso-b0-white': Specifies the ISO B0 white medium
- 'iso-b1-white': Specifies the ISO B1 white medium
- 'iso-b2-white': Specifies the ISO B2 white medium
- 'iso-b3-white': Specifies the ISO B3 white medium
- 'iso-b6-white': Specifies the ISO B6 white medium
- 'iso-b7-white': Specifies the ISO B7 white medium
- 'iso-b8-white': Specifies the ISO B8 white medium
- 'iso-b9-white': Specifies the ISO B9 white medium
- 'iso-b10-white': Specifies the ISO B10 white medium
- 'jis-b0-white': Specifies the JIS B0 white medium
- 'jis-b1-white': Specifies the JIS B1 white medium
- 'jis-b2-white': Specifies the JIS B2 white medium
- 'jis-b3-white': Specifies the JIS B3 white medium
- 'jis-b6-white': Specifies the JIS B6 white medium
- 'jis-b7-white': Specifies the JIS B7 white medium
- 'jis-b8-white': Specifies the JIS B8 white medium
- 'jis-b9-white': Specifies the JIS B9 white medium
- 'jis-b10-white': Specifies the JIS B10 white medium
-
-
-The following standard values are defined for engineering media (white
-only):
-
- 'a-white': Specifies the engineering A size medium
- 'b-white': Specifies the engineering B size medium
- 'c-white': Specifies the engineering C size medium
- 'd-white': Specifies the engineering D size medium
- 'e-white': Specifies the engineering E size medium
-
-
-The following standard values are defined for input-trays (from ISO DPA
-and the Printer MIB):
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 188]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'top': The top input tray in the printer.
- 'middle': The middle input tray in the printer.
- 'bottom': The bottom input tray in the printer.
- 'envelope': The envelope input tray in the printer.
- 'manual': The manual feed input tray in the printer.
- 'large-capacity': The large capacity input tray in the printer.
- 'main': The main input tray
- 'side': The side input tray
-
-
-The following standard values are defined for media sizes (from ISO
-DPA):
-
- 'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined in
- ISO 216
- 'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
- ISO 216
- 'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
- ISO 216
- 'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
- ISO 216
- 'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
- ISO 216
- 'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
- ISO 216
- 'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
- ISO 216
- 'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
- ISO 216
- 'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in ISO
- 216
- 'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in ISO
- 216
- 'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
- ISO 216
- 'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined in
- ISO 216
- 'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined in
- ISO 216
- 'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
- ISO 216
- 'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
- ISO 216
- 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
- ISO 216
- 'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
- ISO 216
- 'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
- ISO 216
- 'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
- ISO 216
- 'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in ISO
- 216
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 189]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in ISO
- 216
- 'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
- ISO 216
- 'na-letter': Specifies the North American letter size: 8.5 inches by
- 11 inches
- 'na-legal': Specifies the North American legal size: 8.5 inches by 14
- inches
- 'executive': Specifies the executive size (7.25 X 10.5 in)
- 'folio': Specifies the folio size (8.5 X 13 in)
- 'invoice': Specifies the invoice size (5.5 X 8.5 in)
- 'ledger': Specifies the ledger size (11 X 17 in)
- 'quarto': Specifies the quarto size (8.5 X 10.83 in)
- 'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
- ISO 269
- 'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
- ISO 269
- 'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
- ISO 269
- 'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
- ISO 269
- 'iso-designated-long': Specifies the ISO Designated Long size: 110 mm
- by 220 mm as defined in ISO 269
- 'na-10x13-envelope': Specifies the North American 10x13 size: 10
- inches by 13 inches
- 'na-9x12-envelope': Specifies the North American 9x12 size: 9 inches
- by 12 inches
- 'na-number-10-envelope': Specifies the North American number 10
- business envelope size: 4.125 inches by 9.5 inches
- 'na-7x9-envelope': Specifies the North American 7x9 inch envelope
- size
- 'na-9x11-envelope': Specifies the North American 9x11 inch envelope
- size
- 'na-10x14-envelope': Specifies the North American 10x14 inch envelope
- size
- 'na-number-9-envelope': Specifies the North American number 9
- business envelope size
- 'na-6x9-envelope': Specifies the North American 6x9 envelope size
- 'na-10x15-envelope': Specifies the North American 10x15 envelope size
- 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
- in)
- 'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
- 'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
- 'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
- 'jis-b3': Specifies the JIS B3 size: 364mm x 515mm
- 'jis-b4': Specifies the JIS B4 size: 257mm x 364mm
- 'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
- 'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
- 'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
- 'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
- 'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
- 'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
-
-The following standard values are defined for engineering media sizes:
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 190]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 'a': Specifies the engineering A size: 8.5 inches x 11 inches
- 'b': Specifies the engineering B size: 11 inches x 17 inches
- 'c': Specifies the engineering C size: 17 inches x 22 inches
- 'd': Specifies the engineering D size: 22 inches x 34 inches
- 'e': Specifies the engineering E size: 34 inches x 44 inches
-
-
-
-15. APPENDIX D: Processing IPP Attributes
-
-
-When submitting a print job to a Printer object, the IPP model allows a
-client to supply operation and Job Template attributes along with the
-document data. These Job Template attributes in the create request
-affect the rendering, production and finishing of the documents in the
-job. Similar types of instructions may also be contained in the
-document to be printed, that is, embedded within the print data itself.
-In addition, the Printer has a set of attributes that describe what
-rendering and finishing options which are supported by that Printer.
-This model, which allows for flexibility and power, also introduces the
-potential that at job submission time, these client-supplied attributes
-may conflict with either:
-
- - what the implementation is capable of realizing (i.e., what the
- Printer supports), as well as
- - the instructions embedded within the print data itself.
-
-
-The following sections describe how these two types of conflicts are
-handled in the IPP model.
-
-
-15.1 Fidelity
-
-
-If there is a conflict between what the client requests and what a
-Printer object supports, the client may request one of two possible
-conflict handling mechanisms:
-
- 1) either reject the job since the job can not be processed exactly
- as specified, or
- 2) allow the Printer to make any changes necessary to proceed with
- processing the Job the best it can.
-
-
-In the first case the client is indicating to the Printer object: "Print
-the job exactly as specified with no exceptions, and if that can't be
-done, don't even bother printing the job at all." In the second case,
-the client is indicating to the Printer object: "It is more important to
-make sure the job is printed rather than be processed exactly as
-specified; just make sure the job is printed even if client supplied
-attributes need to be changed or ignored."
-
-The IPP model accounts for this situation by introducing an "ipp-
-attribute-fidelity" attribute.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 191]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-In a create request, "ipp-attribute-fidelity" is a boolean operation
-attribute that is OPTIONALLY supplied by the client. The value 'true'
-indicates that total fidelity to client supplied Job Template attributes
-and values is required. The client is requesting that the Job be
-printed exactly as specified, and if that is not possible then the job
-MUST be rejected rather than processed incorrectly. The value 'false'
-indicates that a reasonable attempt to print the Job is acceptable. If
-a Printer does not support some of the client supplied Job Template
-attributes or values, the Printer MUST ignore them or substitute any
-supported value for unsupported values, respectively. The Printer may
-choose to substitute the default value associated with that attribute,
-or use some other supported value that is similar to the unsupported
-requested value. For example, if a client supplies a "media" value of
-'na-letter', the Printer may choose to substitute 'iso-a4' rather than a
-default value of 'envelope'. If the client does not supply the "ipp-
-attribute-fidelity" attribute, the Printer assumes a value of 'false'.
-
-Each Printer implementation MUST support both types of "fidelity"
-printing (that is whether the client supplies a value of 'true' or
-'false'):
-
- - If the client supplies 'false' or does not supply the attribute,
- the Printer object MUST always accept the request by ignoring
- unsupported Job Template attributes and by substituting unsupported
- values of supported Job Template attributes with supported values.
- - If the client supplies 'true', the Printer object MUST reject the
- request if the client supplies unsupported Job Template attributes.
-
-
-Since a client can always query a Printer to find out exactly what is
-and is not supported, "ipp-attribute-fidelity" set to 'false' is useful
-when:
-
- 1) The End-User uses a command line interface to request attributes
- that might not be supported.
- 2) In a GUI context, if the End User expects the job might be moved
- to another printer and prefers a sub-optimal result to nothing at
- all.
- 3) The End User just wants something reasonable in lieu of nothing at
- all.
-
-
-15.2 Page Description Language (PDL) Override
-
-
-If there is a conflict between the value of an IPP Job Template
-attribute and a corresponding instruction in the document data, the
-value of the IPP attribute SHOULD take precedence over the document
-instruction. Consider the case where a previously formatted file of
-document data is sent to an IPP Printer. In this case, if the client
-supplies any attributes at job submission time, the client desires that
-those attributes override the embedded instructions. Consider the case
-were a previously formatted document has embedded in it commands to load
-'iso-a4' media. However, the document is passed to an end user that
-only has access to a printer with 'na-letter' media loaded. That end
-user most likely wants to submit that document to an IPP Printer with
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 192]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-the "media" Job Template attribute set to 'na-letter'. The job
-submission attribute should take precedence over the embedded PDL
-instruction. However, until companies that supply document data
-interpreters allow a way for external IPP attributes to take precedence
-over embedded job production instructions, a Printer might not be able
-to support the semantics that IPP attributes override the embedded
-instructions.
-
-The IPP model accounts for this situation by introducing a "pdl-
-override-supported" attribute that describes the Printer objects
-capabilities to override instructions embedded in the PDL data stream.
-The value of the "pdl-override-supported" attribute is configured by
-means outside the scope of this IPP/1.1 document.
-
-This REQUIRED Printer attribute takes on the following values:
-
- - 'attempted': This value indicates that the Printer object attempts
- to make the IPP attribute values take precedence over embedded
- instructions in the document data, however there is no guarantee.
- - 'not-attempted': This value indicates that the Printer object makes
- no attempt to make the IPP attribute values take precedence over
- embedded instructions in the document data.
-
-
-At job processing time, an implementation that supports the value of
-'attempted' might do one of several different actions:
-
- 1) Generate an output device specific command sequence to realize the
- feature represented by the IPP attribute value.
- 2) Parse the document data itself and replace the conflicting
- embedded instruction with a new embedded instruction that matches
- the intent of the IPP attribute value.
- 3) Indicate to the Printer that external supplied attributes take
- precedence over embedded instructions and then pass the external
- IPP attribute values to the document data interpreter.
- 4) Anything else that allows for the semantics that IPP attributes
- override embedded document data instructions.
-
-
-Since 'attempted' does not offer any type of guarantee, even though a
-given Printer object might not do a very "good" job of attempting to
-ensure that IPP attributes take a higher precedence over instructions
-embedded in the document data, it would still be a conforming
-implementation.
-
-At job processing time, an implementation that supports the value of
-'not-attempted' might do one of the following actions:
-
- 1) Simply pre-pend the document data with the PDL instruction that
- corresponds to the client-supplied PDL attribute, such that if the
- document data also has the same PDL instruction, it will override
- what the Printer object pre-pended. In other words, this
- implementation is using the same implementation semantics for the
- client-supplied IPP attributes as for the Printer object defaults.
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 193]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 2) Parse the document data and replace the conflicting embedded
- instruction with a new embedded instruction that approximates, but
- does not match, the semantic intent of the IPP attribute value.
-
-
-Note: The "ipp-attribute-fidelity" attribute applies to the Printer's
-ability to either accept or reject other unsupported Job Template
-attributes. In other words, if "ipp-attribute-fidelity" is set to
-'true', a Job is accepted if and only if the client supplied Job
-Template attributes and values are supported by the Printer. Whether
-these attributes actually affect the processing of the Job when the
-document data contains embedded instructions depends on the ability of
-the Printer to override the instructions embedded in the document data
-with the semantics of the IPP attributes. If the document data
-attributes can be overridden ("pdl-override-supported" set to
-'attempted'), the Printer makes an attempt to use the IPP attributes
-when processing the Job. If the document data attributes can not be
-overridden ("pdl-override-supported" set to 'not-attempted'), the
-Printer makes no attempt to override the embedded document data
-instructions with the IPP attributes when processing the Job, and hence,
-the IPP attributes may fail to affect the Job processing and output when
-the corresponding instruction is embedded in the document data.
-
-
-15.3 Using Job Template Attributes During Document Processing.
-
-
-The Printer object uses some of the Job object's Job Template attributes
-during the processing of the document data associated with that job.
-These include, but are not limited to, "orientation-requested", "number-
-up", "sides", "media", and "copies". The processing of each document in
-a Job Object MUST follow the steps below. These steps are intended only
-to identify when and how attributes are to be used in processing
-document data and any alternative steps that accomplishes the same
-effect can be used to implement this specification document.
-
- 1. Using the client supplied "document-format" attribute or some form
- of document format detection algorithm (if the value of "document-
- format" is not specific enough), determine whether or not the
- document data has already been formatted for printing. If the
- document data has been formatted, then go to step 2. Otherwise, the
- document data MUST be formatted. The formatting detection algorithm
- is implementation defined and is not specified by this document.
- The formatting of the document data uses the "orientation-
- requested" attribute to determine how the formatted print data
- should be placed on a print-stream page, see section 4.2.10 for the
- details.
-
- 2. The document data is in the form of a print-stream in a known
- media type. The "page-ranges" attribute is used to select, as
- specified in section 4.2.7, a sub-sequence of the pages in the
- print-stream that are to be processed and images.
-
- 3. The input to this step is a sequence of print-stream pages. This
- step is controlled by the "number-up" attribute. If the value of
- "number-up" is N, then during the processing of the print-stream
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 194]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- pages, each N print-stream pages are positioned, as specified in
- section 4.2.9, to create a single impression. If a given document
- does not have N more print-stream pages, then the completion of the
- impression is controlled by the "multiple-document-handling"
- attribute as described in section 4.2.4; when the value of this
- attribute is 'single-document' or 'single-document-new-sheet', the
- print-stream pages of document data from subsequent documents is
- used to complete the impression.
-
- The size(scaling), position(translation) and rotation of the print-
- stream pages on the impression is implementation defined. Note
- that during this process the print-stream pages may be rendered to
- a form suitable for placing on the impression; this rendering is
- controlled by the values of the "printer-resolution" and "print-
- quality" attributes as described in sections 4.2.12 and 4.2.13. In
- the case N=1, the impression is nearly the same as the print-stream
- page; the differences would only be in the size, position and
- rotation of the print-stream page and/or any decoration, such as a
- frame to the page, that is added by the implementation.
-
- 4. The collection of impressions is placed, in sequence, onto sides
- of the media sheets. This placement is controlled by the "sides"
- attribute and the orientation of the print-stream page, as
- described in section 4.2.8. The orientation of the print-stream
- pages affects the orientation of the impression; for example, if
- "number-up" equals 2, then, typically, two portrait print-stream
- pages become one landscape impression. Note that the placement of
- impressions onto media sheets is also controlled by the "multiple-
- document-handling" attribute as described in section 4.2.4.
-
- 5. The "copies" and "multiple-document-handling" attributes are used
- to determine how many copies of each media instance are created and
- in what order. See sections 4.2.5 and 4.2.4 for the details.
-
- 6. When the correct number of copies are created, the media instances
- are finished according to the values of the "finishings" attribute
- as described in 4.2.6. Note that sometimes finishing operations may
- require manual intervention to perform the finishing operations on
- the copies, especially uncollated copies. This document allows any
- or all of the processing steps to be performed automatically or
- manually at the discretion of the Printer object.
-
-
-16. APPENDIX E: Generic Directory Schema
-
-
-This section defines a generic schema for an entry in a directory
-service. A directory service is a means by which service users can
-locate service providers. In IPP environments, this means that IPP
-Printers can be registered (either automatically or with the help of an
-administrator) as entries of type printer in the directory using an
-implementation specific mechanism such as entry attributes, entry type
-fields, specific branches, etc. Directory clients can search or browse
-for entries of type printer. Clients use the directory service to find
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 195]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-entries based on naming, organizational contexts, or filtered searches
-on attribute values of entries. For example, a client can find all
-printers in the "Local Department" context. Authentication and
-authorization are also often part of a directory service so that an
-administrator can place limits on end users so that they are only
-allowed to find entries to which they have certain access rights. IPP
-itself does not require any specific directory service protocol or
-provider.
-
-Note: Some directory implementations allow for the notion of "aliasing".
-That is, one directory entry object can appear as multiple directory
-entry object with different names for each object. In each case, each
-alias refers to the same directory entry object which refers to a single
-IPP Printer object.
-
-The generic schema is a subset of IPP Printer Job Template and Printer
-Description attributes (sections 4.2 and 4.4). These attributes are
-identified as either RECOMMENDED or OPTIONAL for the directory entry
-itself. This conformance labeling is NOT the same conformance labeling
-applied to the attributes of IPP Printers objects. The conformance
-labeling in this Appendix is intended to apply to directory templates
-and to IPP Printer implementations that subscribe by adding one or more
-entries to a directory. RECOMMENDED attributes SHOULD be associated
-with each directory entry. OPTIONAL attributes MAY be associated with
-the directory entry (if known or supported). In addition, all directory
-entry attributes SHOULD reflect the current attribute values for the
-corresponding Printer object.
-
-The names of attributes in directory schema and entries SHOULD be the
-same as the IPP Printer attribute names as shown, as much as possible.
-
-In order to bridge between the directory service and the IPP Printer
-object, one of the RECOMMENDED directory entry attributes is the Printer
-object's "printer-uri-supported" attribute. The directory client
-queries the "printer-uri-supported" attribute (or its equivalent) in the
-directory entry and then the IPP client addresses the IPP Printer object
-using one of its URIs. The "uri-security-supported" attribute
-identifies the protocol (if any) used to secure a channel.
-
-The following attributes define the generic schema for directory entries
-of type PRINTER:
-
- printer-uri-supported RECOMMENDED Section 4.4.1
- uri-authentication-supported RECOMMENDED Section 4.4.2
- uri-security-supported RECOMMENDED Section 4.4.3
- printer-name RECOMMENDED Section 4.4.4
- printer-location RECOMMENDED Section 4.4.5
- printer-info OPTIONAL Section 4.4.6
- printer-more-info OPTIONAL Section 4.4.7
- printer-make-and-model RECOMMENDED Section 4.4.9
- ipp-versions-supported RECOMMENDED Section 4.4.14
- multiple-document-jobs-supported OPTIONAL Section 4.4.16
- charset-supported OPTIONAL Section 4.4.18
- generated-natural-language-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 196]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- supported OPTIONAL Section 4.4.20
- document-format-supported RECOMMENDED Section 4.4.22
- color-supported RECOMMENDED Section 4.4.26
- compression-supported RECOMMENDED Section 4.4.32
- pages-per-minute OPTIONAL Section 4.4.36
- pages-per-minute-color OPTIONAL Section 4.4.37
-
- finishings-supported OPTIONAL Section 4.2.6
- number-up-supported OPTIONAL Section 4.2.7
- sides-supported RECOMMENDED Section 4.2.8
- media-supported RECOMMENDED Section 4.2.11
- printer-resolution-supported OPTIONAL Section 4.2.12
- print-quality-supported OPTIONAL Section 4.2.13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 197]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-
-
-
-17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1 "Model and
-Semantics" Documents
-
-
-This Appendix is divided into two lists that summarize the differences
-between IPP/1.1 (this document) and IPP/1.0 [RFC2566]. The section
-numbers refer to the numbers in this document which in some cases have
-changed from RFC 2566. When a change affects multiple sections, the
-item is listed once in the order of the first section affected and the
-remaining affected section numbers are indicated.
-
-The first list contains extensions and clarifications and the second
-list contains changes in semantics or conformance. However, client and
-IPP object implementations of IPP/1.0 MAY implement any of the
-extensions and clarifications in this document.
-
-The following extensions and clarifications have been incorporated into
-this document:
-
- 1. Section 2.1 - clarified that the term "client" can be either
- contained in software controlled by an end user or a part of a
- print server that controls devices.
- 2. Section 2 - clarified that the term "IPP object" and "Printer
- object" can either be embedded in a device object or part of a
- print server that accepts IPP requests.
- 3. Section 2.4 - added the description of the new "uri-authentication-
- supported" Printer Description attribute.
- 4. Section 3.1.3, 3.1.6, 3.2.5.2, and 3.2.6.2 - clarified the error
- handling for operation attributes that have their own status code.
- 5. Section 3.1.3 - clarified that multiple occurrences of the same
- attribute in an attribute group is mal-formed. An IPP Printer MAY
- reject the request or choose one of the attributes.
- 6. Section 3.1.6 - reorganized this section into sub-sections to
- separately describe "status-code", "status-message", "detailed-
- status-message", and "document-access-error" attributes.
- 7. Section 3.1.6.1 - clarified the error status codes and their
- relationship to operation attributes.
- 8. Section 3.1.6.3 - Added the OPTIONAL "detailed-status-message
- (text(MAX))" operation attribute to provide additional more
- detailed information about a response.
- 9. Section 3.1.6.4 and 3.2.2 - Added the OPTIONAL "document-access-
- error (text(MAX))" operation attribute for use with Print-URI and
- Send-URI responses.
- 10. Sections 3.1.7 - Added this new section to clarify returning
- Unsupported Attributes for all operations, including only returning
- attributes that were in the request. Moved the text from section
- 3.2.1.2 Unsupported Attributes to this section.
- 11. Sections 3.1.7 and 4.1 - clarified the encoding of the "out-
- of-band" 'unsupported' and 'unknown' values.
- 12. Section 3.1.8 - clarified that only the version number
- parameter will be carried forward into future major or minor
- versions of the protocol.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 198]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 13. Section 3.1.8 - relaxed the requirements to increment the
- major version number in future versions of the Model and Semantics
- document.
- 14. Section 3.1.9, and 3.2.5 - added the 'processing' state to the
- list of job states that a job can be in after a Create-Job
- operation.
- 15. Section 3.1.9 - clarified that a non-spooling Printer MAY
- accept zero or more subsequent jobs while processing a job and flow
- control them down. Subsequent create requests are rejected with
- the 'server-error-busy' error status.
- 16. Section 3.2.1.1 - clarified the validation of the
- "compression" operation attribute and its relationship to the
- validation of the "document-format" attribute and returning
- Unsupported Attributes.
- 17. Sections 3.2.1.1, 4.3.8, 13.1.4.16, and 13.1.4.17 - added the
- 'client-error-compression-not-supported', 'client-error-
- compression-error' status codes and the 'unsupported-compression'
- and 'compression-error' job-state-reasons.
- 18. Sections 3.2.1.1 and 4.3.8 - added 'unsupported-document-
- format' and 'document-format-error' job-state-reasons.
- 19. Sections 3.2.2, 4.3.8 and 13.1.4.19 - added 'client-error-
- document-access-error' status code and 'document-access-error' job
- state reason.
- 20. Section 3.2.5.2 and 3.2.6.2 - clarified that the Unsupported
- Attributes group MUST NOT include attributes not requested in the
- Get-Printer-Attributes request.
- 21. Section 3.2.6 - clarified that "limit" takes precedence over
- "which-jobs" and "my-jobs'.
- 22. Section 3.2.6.2 - clarified that Get-Jobs returns 'successful-
- ok' when no jobs to return.
- 23. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause-
- Printer, Resume-Printer, and Purge-Jobs operations
- 24. Section 3.3.1 - clarified that the authorization required for
- a Send-Document request MUST be the same user as the Create-Job or
- an operator.
- 25. Section 3.3.1.1 - clarified that a Create-Job Send-Document
- with "last-document" = 'true' and no data is not an error; its a
- job with no documents.
- 26. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold-
- Job, Release-Job, and Restart-Job operations. Clarified the
- Restart-Job operation so that the Printer MUST re-fetch any
- documents passed by-reference (Print-URI or Send-URI).
- 27. Section 4.1 - clarified that the encoding of the out-of-band
- values are specified in the Encoding and Transport" document.
- 28. Section 4.1 - Clarified that the requirement that clients MUST
- NOT send "out-of-band" values in requests applies only to
- operations defined in this document. Other operations are allowed
- to define "out-of-band" values that clients can supply.
- 29. Sections 4.1.1 and 4.1.2 - clarified that the maximum 'text'
- and 'name' values of 1023 and 255 are for the 'textWithoutLanguage'
- portion of the 'textWithLanguage' form, so that the maximum number
- of octets for the actual text and name data is the same for the
- without and with language forms; the 'naturalLanguage' part is in
- addition.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 199]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 30. Section 4.1.9 - clarified that 'mimeMediaType' values can
- include any parameters from the IANA Registry, not just charset
- parameters.
- 31. Section 4.1.9.1 - clarified that 'application/octet-stream'
- auto-sensing can happen at create request time and/or job/document
- processing time.
- 32. Section 4.1.9.1 - clarified that auto-sensing involves the
- Printer examining some number of octets of document data using an
- implementation-dependent method.
- 33. Section 4.1.14 - clarified that the localization of dateTime
- by the client includes the time zone.
- 34. Section 4.2 - clarified that xxx-supported have multiple
- keywords and/or names by adding parentheses to the table to give:
- (1setOf (type3 keyword | name))
- 35. Section 4.2.2 - added the 'indefinite' keyword value to the
- "job-hold-until" attribute for use with the create operations and
- Hold-Job and Restart-Job operations.
- 36. Section 4.2.6 - added more enum values to the "finishings" Job
- Template attribute.
- 37. Section 4.2.6 - clarified that the landscape definition is a
- rotation of the image with respect to the medium.
- 38. Section 4.3.7 - added that a forwarding server that cannot get
- any job state MAY return the job's state as 'completed', provided
- that it also return the new 'queued-in-device' job state reason.
- 39. Section 4.3.7.2 - added the Partitioning of Job States section
- to clarify the concepts of Job Retention, Job History, and Job
- Removal.
- 40. Section 4.3.8 - added 'job-data-insufficient' job state reason
- to indicate whether sufficient data has arrived for the document to
- start to be processed.
- 41. Section 4.3.8 - added 'document-access-error' job state reason
- to indicate an access error of any kind.
- 42. Section 4.3.8 - added 'job-queued-for-marker' job state reason
- to indicate whether the job has completed some processing and is
- waiting for the marker.
- 43. Section 4.3.8 - added 'unsupported-compression' and
- 'compression-error' job state reasons to indicate compression not
- supported or compression processing error after the create has been
- accepted.
- 44. Section 4.3.8 - added 'unsupported-document-format' and
- 'document-format-error' job state reasons to indicate document not
- supported or document format processing error after the create has
- been accepted.
- 45. Section 4.3.8 - added 'queued-in-device' job state reason to
- indicate that a job as been forwarded to a print system or device
- that does not provide any job status.
- 46. Section 4.3.10 - added "job-detailed-status-messages (1setOf
- text(MAX)) for returning detailed error messages.
- 47. Section 4.3.11 - added the "job-document-access-errors (1setOf
- text(MAX))
- 48. Section 4.3.14.2 - clarified that the time recorded is the
- first time processing since the create operation or the Restart-Job
- operation.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 200]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 49. Section 4.3.14.2 and 4.3.14.3 - clarified that the out-of-band
- value 'no-value' is returned if the job has not started processing
- or has not completed, respectively.
- 50. Section 4.3.14 - Added the OPTIONAL "date-time-at-creation",
- "date-time-at-processing", and "date-time-at-completed" Event Time
- Job Description attributes
- 51. Section 4.4.3 - added the 'tls' value to "uri-security-
- supported" attribute.
- 52. Section 4.4.3 - clarified "uri-security-supported" is
- orthogonal to Client Authentication so that 'none' does not exclude
- Client Authentication.
- 53. Section 4.4.11 - simplified the "printer-state" descriptions
- while generalizing to allow high end devices that interpret one or
- more jobs while marking another. Indicated that 'spool-area-full'
- and 'stopped-partly' "printer-state-reasons" may be used to provide
- further state information.
- 54. Section 4.4.12 - added the 'moving-to-paused' keyword value to
- the "printer-state-reasons" attribute for use with the Pause-
- Printer operation.
- 55. Section 4.4.12 - replaced the duplicate 'marker-supply-low'
- keyword with the missing 'toner-empty' keyword for the "printer-
- state-reasons" attribute. (This correction was also made before
- RFC 2566 was published).
- 56. Section 4.4.12 - clarified 'spool-area-full' "printer-state-
- reasons" to include non-spooling printers to indicate when it can
- and cannot accept another job.
- 57. Section 4.4.15 - added the enum values to the "operations-
- supported" attribute for the new operations. Clarified that the
- values of this attribute are encoded as any enum, namely 32-bit
- values.
- 58. Section 4.4.30 - clarified that the dateTime value of
- "printer-current-time" is on a "best efforts basis". If a proper
- date-time cannot be obtained, the implementation returns the 'no-
- value' out-of-band value. Also clarified that the time zone NEED
- NOT be the time zone that the people near the device use and that
- the client SHOULD display the dateTime attributes in the user's
- local time.
- 59. Sections 4.4.36 and 4.4.37 - added the OPTIONAL "pages-per-
- minute" and "pages-per-minute-color" Printer Description
- attributes.
- 60. Section 5.1 - clarified that the client conformance
- requirements apply to clients controlled by an end user and clients
- in servers.
- 61. Section 5.1 - clarified that any response MAY contain
- additional attribute groups, attributes, attribute syntaxes, or
- attribute values.
- 62. Section 5.1 - clarified that a client SHOULD do its best to
- prevent a channel from being closed by a lower layer when the
- channel is flow controlled off by the IPP Printer.
- 63. Section 5.2 - clarified that the IPP object requirements apply
- to objects embedded in devices or that are parts of servers.
- 64. Section 5.2.2 - clarified that IPP objects MAY return
- operation responses that contain attribute groups, attribute names,
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 201]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- attribute syntaxes, attribute values, and status codes that are
- extensions to this standard.
- 65. Section 6 - changed the terminology of "private extensions" to
- "vendor extensions" and indicated that they are registered with
- IANA along with IETF standards track extensions.
- 66. Section 6.7 - inserted this section on registering out-of-band
- attribute values with IANA as extensions.
- 67. Section 8.3 - clarified the use of URIs for each Client
- Authentication mechanism.
- 68. Section 8.5 - added the security discussion around the new
- operator/administrator operations.
- 69. Section 13.1.4.16 - added client-error-compression-not-
- supported (0x040F)
- 70. Section 13.1.4.17 - added client-error-compression-error
- (0x0410)
- 71. Section 13.1.4.18 - added client-error-document-format-error
- (0x0411)
- 72. Section 13.1.4.19 - added client-error-document-access-error
- (0x0412)
- 73. Section 13.1.5.10 - added server-error-multiple-document-jobs-
- not-supported (0x0509)
- 74. Section 14 - added 'a-white', 'b-white', 'c-white', 'd-white',
- and 'e-white' and clarified that the existing 'a', 'b', 'c', 'd',
- and 'e' values are size values. Added American, Japanese, and
- European Engineering sizes, filled out -transparent and -
- translucent media names and drawings for the synchro cut sizes.
- 75. Section 16 - softened the RECOMMENDATION for IPP Printer
- attributes in a Directory schema so that they can have equivalents.
- 76. Section 16 - added the OPTIONAL "pages-per-minute" and "pages-
- per-minute-color" Printer attributes to the Directory schema.
- 77. Section 16 - added OPTIONAL "multiple-document-jobs-supported"
- to the Directory schema.
- 78. Section 16 - added RECOMMENDED "uri-authentication-supported",
- "ipp-versions-supported", and "compression-supported" to the
- Directory schema.
-
-The following changes in semantics and/or conformance have been
-incorporated into this document:
-
- 1. Section 3.1.6.3 - allowed a Printer to localize the "detailed-
- status-message" operation response attribute, but indicated that
- such localization might obscure the technical meaning of such
- messages.
- 2. Section 3.1.8, 5.2.4, and 13.1.5.4 - Clients and IPP objects MUST
- support version 1.1 conformance requirements. It is
- recommended that they interoperate with 1.0. Also clarified
- that IPP Printers MUST accept '1.1' requests. It is
- recommended that they also accept '1.x' requests.
- 3. Section 3.2.1.1 and section 4.4.32 - changed the "compression"
- operation and the "compression-supported" Printer Description
- attribute from OPTIONAL to REQUIRED.
- 4. Sections 3.2.1.2 and 4.3.8 - changed "job-state-reasons" from
- RECOMMENDED to REQUIRED, so that "job-state-reasons" MUST be
- returned in create operation responses.
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 202]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 5. Sections 3.2.4, 3.3.1, 4.4.16, and 16 - changed Create-Job/Send-
- Document so that they MAY be implemented while only supporting
- one document jobs. Added the "multiple-document-jobs-supported"
- boolean Printer Description attribute to indicate whether
- Create-Job/Send-Document support multiple document jobs or not.
- Added to the Directory schema.
- 6. Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2',
- since binary is not legal with the 'text' type.
- 7. Section 4.1.9.1 - added the RECOMMENDATION that a Printer indicate
- by printing on the job's job-start-sheet that auto-sensing has
- occurred and what document format was auto-sensed.
- 8. Section 4.2.4 - indicated that the "multiple-document-handling"
- Job Template attribute MUST be supported with at least one value
- if the Printer supports multiple documents per job
- 9. Section 4.3.7.2 - indicated that the 'job-restartable' job state
- reason SHOULD be supported if the Restart-Job operation is
- supported.
- 10. Section 4.3.8 - changed "job-state-reasons" from RECOMMENDED to
- REQUIRED.
- 11. Section 4.3.8 - clarified the conformance of the values of the
- "job-state-reasons" attribute by copying conformance
- requirements from other sections of the document so that it is
- clear from reading the definition of "job-state-reasons" which
- values MUST or SHOULD be supported. The 'none', 'unsupported-
- compression', and 'unsupported-document-format' values MUST be
- supported. The ''job-hold-until-specified' SHOULD be specified
- if the "job-hold-until" Job Template is supported. The
- following values SHOULD be supported: 'job-canceled-by-user',
- 'aborted-by-system', and 'job-completed-successfully'. The
- 'job-canceled-by-operator' SHOULD be supported if the
- implementation permits canceling by other than the job owner.
- The 'job-canceled-at-device' SHOULD be supported if the device
- supports canceling jobs at the console. The 'job-completed-
- with-warnings' SHOULD be supported, if the implementation
- detects warnings. The 'job-completed-with-errors' SHOULD be
- supported if the implementation detects errors. The 'job-
- restartable' SHOULD be supported if the Restart-Job operation is
- supported.
- 12. Section 4.3.10 - allowed a Printer to localize the "job-detailed-
- status-message" Job Description attribute, but indicated that
- such localization might obscure the technical meaning of such
- messages.
- 13. Section 4.3.14 - changed the "time-at-creation", "time-at-
- processing", and "time-at-completed" Event Time Job Description
- attributes from OPTIONAL to REQUIRED.
- 14. Section 4.3.14.4 - added the REQUIRED "job-printer-up-time
- (integer(1:MAX))" Job Description attribute as an alias for
- "printer-up-time" to reduce number of operations to get job
- times.
- 15. Section 4.4.2 - added the REQUIRED "uri-authentication-supported
- (1setOf type2 keyword)" Printer Description attribute to
- describe the Client Authentication used by each Printer URI.
- 16. Section 4.4.12 - changed "printer-state-reasons" Printer
- Description attribute from OPTIONAL to REQUIRED.
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 203]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
- 17. Section 4.4.12 - changed 'paused' value of "printer-state-
- reasons" to MUST if Pause-Printer operation is supported.
- 18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported
- (1setOf keyword)" Printer Description attribute, since IPP/1.1
- Printers do not have to support version '1.0' conformance
- requirements. Section 4.4.16 - added the "multiple-document-
- jobs-supported (boolean)" Printer Description attribute so that
- a client can tell whether a Printer that supports Create-
- Job/Send-Document supports multiple document jobs or not. This
- attribute is REQUIRED if the Create-Job operation is supported.
- 19. Section 4.4.24 - changed the "queued-job-count" Printer
- Description attribute from RECOMMENDED to REQUIRED.
- 20. Section 4.4.32 - changed "compression-supported (1setOf type3
- keyword)" Printer Description attribute from OPTIONAL to
- REQUIRED.
- 21. Section 5.1 - changed the client security requirements from
- RECOMMENDED non-standards track SSL3 to MUST support Client
- Authentication as defined in the IPP/1.1 Encoding and Transport
- document [IPP-PRO]. A client SHOULD support Operation Privacy
- and Server Authentication as defined in the IPP/1.1 Encoding and
- Transport document [IPP-PRO].
- 22. Section 5.2.7 - changed the IPP object security requirements from
- OPTIONAL non-standards track SSL3 to SHOULD contain support for
- Client Authentication as defined in the IPP/1.1 Encoding and
- Transport document [IPP-PRO]. A Printer implementation MAY
- allow an administrator to configure the Printer so that all,
- some, or none of the users are authenticated. An IPP Printer
- implementation SHOULD contain support for Operation Privacy and
- Server Authentication as defined in the IPP/1.1 Encoding and
- Transport document [IPP-PRO]. A Printer implementation MAY
- allow an administrator to configure the degree of support for
- Operation Privacy and Server Authentication. Security MUST NOT
- be compromised when the client supplies a lower version-number
- in a request.
-
-See also the "IPP/1.1 Encoding and Transport" [IPP-PRO] document for
-differences between IPP/1.0 [RFC2565] and IPP/1.1 [IPP-PRO].
-
-
-
-18. Full Copyright Statement
-
-
-Copyright (C) The Internet Society (2000). 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
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 204]
- Expires November 22, 2000
-\f
-
-INTERNET-DRAFT IPP/1.1: Model and Semantics May 22, 2000
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-deBry, Hastings, Herriot, Isaacson, Powell [Page 205]
- Expires November 22, 2000
+++ /dev/null
-This Internet-Draft has expired and is no longer available.
-
-Unrevised documents placed in the Internet-Drafts directories have a
-maximum life of six months. After that time, they must be updated, or
-they will be deleted. This document was deleted on March 20, 2000.
--- /dev/null
+
+
+
+
+
+
+INTERNET DRAFT Roger K deBry
+<draft-ietf-ipp-not-05.txt> Utah Valley State College
+[Target Category: Informational] Harry Lewis
+ IBM Corporation
+ Tom Hastings (editor)
+ Xerox Corporation
+ January 23, 2001
+
+ Internet Printing Protocol (IPP): Requirements for IPP Notifications
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+
+STATUS OF THIS MEMO
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ''work in progress.''
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+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
+ on the Internet. There are multiple parts to IPP, but the primary
+ architectural components are the Model, the Protocol and an interface
+ to Directory Services. This document provides a statement of the
+ requirements for notifications as part of an IPP Service.
+
+
+
+
+
+
+
+
+
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 1]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ The full set of IPP documents include:
+
+ 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]
+ Internet Printing Protocol/1.0: Implementer's Guide [RFC 2639]
+ Mapping between LPD and IPP Protocols [RFC2569]
+
+ The 'Design Goals for an Internet Printing Protocol' document 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. It 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 'Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol' document 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 'Internet Printing Protocol/1.0: Encoding and Transport' document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1. It defines the encoding rules
+ for a new Internet media type called 'application/ipp'.
+
+ The 'Internet Printing Protocol/1.0: Implementer's Guide' document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them 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 'Mapping between LPD and IPP Protocols' document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+ Table of Contents
+
+
+ 1 Scope ...........................................................4
+
+ 2 Terminology .....................................................4
+
+ 3 Scenarios .......................................................8
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 2]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ 4 Requirements ...................................................11
+
+ 5 Security considerations for IPP Notifications requirements .....13
+
+ 6 Internationalization Considerations ............................14
+
+ 7 IANA Considerations ............................................14
+
+ 8 References .....................................................14
+
+ 9 Author's Address ...............................................15
+
+ 10 Appendix A: Full Copyright Statement...........................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 3]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+1 Scope
+
+ The scope of this requirements document covers functionality used by
+ the following kinds of IPP Users: End Users, Print Administrators and
+ Operators.
+
+2 Terminology
+
+ It is necessary to define a set of terms in order to be able to
+ clearly express the requirements for notification services in an IPP
+ System.
+
+2.1 Job Submitting End User
+
+ A human end user who submits a print job to an IPP Printer. This
+ person may or may not be within the same security domain as the
+ Printer. This person may or may not be geographically near the
+ printer.
+
+2.2 Administrator
+
+ A human user who established policy for and configures the print
+ system.
+
+2.3 Operator
+
+ A human user who carries out the policy established by the
+ Administrator and controls the day to day running of the print
+ system.
+
+2.4 Job Submitting Application
+
+ An application (for example, a batch application), acting on behalf
+ of a Job Submitting End User, which submits a print job to an IPP
+ Printer. The application may or may not be within the same security
+ domain as the Printer. This application may or may not be
+ geographically near the printer.
+
+2.5 Security Domain
+
+ For the purposes of this discussion, the set of network components
+ which can communicate without going through a proxy or firewall. A
+ security domain may be geographically very large, for example -
+ anyplace within IBM.COM.
+
+2.6 IPP Client
+
+ The software component that sends IPP requests to an IPP Printer
+ object and accepts IPP responses from an IPP Printer.
+
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 4]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+2.7 Job Recipient
+
+ A human who is the ultimate consumer of the print job. In many cases
+ this will be the same person as the Job Submitting End User, but this
+ need not always be the case. For example, if I use IPP to print a
+ document on a printer in a business partner's office, I am the Job
+ Submitting End User, while the person I intend the document for in my
+ business partner's office is the Job Recipient. Since one of the
+ goals of IPP is to be able to print near the Job Recipient of the
+ printed output, we would normally expect that person to be in the
+ same security domain as, and geographically near, the Printer.
+ However, this may not always be the case. For example, I submit a
+ print job across the Internet to a Kinko's print shop. I am both the
+ Submitting end User and the Job Recipient, but I am neither near nor
+ in the same security domain as the Printer.
+
+2.8 Job Recipient Proxy
+
+ A person acting on behalf of the Job Recipient. In particular, the
+ Job Recipient Proxy physically picks up the printed document from the
+ Printer, if the Job Recipient cannot perform that function. The Proxy
+ is by definition geographically near and in the same security domain
+ as the printer. For example, I submit a print job from home to be
+ printed on a printer at work. I'd like my secretary to pick up the
+ print job and put it on my desk. In this case, I am acting as both
+ Job Submitting End User and Job Recipient. My secretary is acting as
+ a Job Recipient Proxy.
+
+2.9 Notification Subscriber
+
+ A client that requests the IPP Printer to send Event Notifications to
+ one or more Notification Recipients. A Notification Subscriber may
+ be a Job Submitting End User or an End User, an Operator, or an
+ Administrator that is not submitting a job.
+
+2.10 Notification Source
+
+ The entity that sends Event Notifications.
+
+2.11 Notification Recipient
+
+ The entity that receives IPP Notifications about Job and/or Printer
+ events. A Notification Recipient may be a: Job Submitting End User,
+ Job Submitting Application, Job Recipient, Job Recipient Proxy,
+ Operator, or Administrator, etc., and their representatives or log
+ file or usage statistics gathering application or other active or
+ passive entities.
+
+2.12 Notification Recipient Agent
+
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 5]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ A program which receives Event Notifications on behalf of the
+ Notification Recipient. The agent may take some action on behalf of
+ the recipient, forward the notification to the recipient via some
+ alternative means (for example, page the recipient), or queue the
+ notification for later retrieval by the recipient.
+
+2.13 Event
+
+ A Event is some occurrence (either expected or unexpected) within the
+ printing system of a change of state, condition, or configuration of
+ a Job or Printer object.
+
+2.14 Event Notification
+
+ When an event occurs, an Event Notification is generated that fully
+ describes the event (what the event was, where it occurred, when it
+ occurred, etc.). Event Notifications are delivered to all the
+ Notification Recipients that are subscribed to that Event, if any.
+ The Event Notification is delivered to the address of the
+ Notification Recipient using the notification delivery method defined
+ in the subscription. However, an Event Notification is sent ONLY if
+ there is a corresponding subscription.
+
+2.15 Notification Subscription
+
+ A Notification Subscription is a request by a Notification Subscriber
+ to the IPP Printer to send Event Notifications to specified
+ Notification Recipient(s) when the event occur.
+
+2.16 Notification Attributes
+
+ IPP Objects (for example, a print job) from which notification are
+ being sent may have attributes associated with them. A user may want
+ to have one or more of these associated attributes returned along
+ with a particular notification. In general, these may include any
+ attribute associated with the object emitting the notification.
+ Examples include:
+
+ number-of-intervening jobs
+ job-k-octets
+ job-k-octets processed
+ job impressions
+ job-impressions-interpreted
+ job-impressions-completed
+ impressionsCompletedCurrentCopy (job MIB)
+ sheetCompletedCopyNumber (job MIB)
+ sheetsCompletedDocumentNumber (job MIB)
+ Copies-requested
+ Copy-type
+ Output-destination
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 6]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ Job-state-reasons
+ Job ID
+ Printer URI
+ Subscription ID (for job independent subscription)
+
+2.17 Notification Delivery Method (or Delivery Method for short)
+
+ Event Notifications are delivered using a method, such as email,
+ TCP/IP, etc.
+
+2.18 Immediate Notification
+
+ Notifications sent to the Notification Recipient or the Notification
+ Recipient's agent in such a way that the notification arrives
+ immediately , within the limits of common addressing, routing,
+ network congestion and quality of service.
+
+2.19 Store and Forward Notification
+
+ Notifications which are not necessarily delivered to Notification
+ Recipients immediately, but are queued for delivery by some
+ intermediate network application, for later retrieval. Email is an
+ example of a store and forward notification delivery method.
+
+2.20 Reliable Delivery of Notifications
+
+ Notifications which are delivered by a reliable delivery of packets
+ or character stream, with acknowledgment and retry, such that
+ delivery of the notification is guaranteed within some determinate
+ time limits. For example, if the Notification Recipient has logged
+ off and gone home for the day, an immediate notification cannot be
+ guaranteed to be delivered, even when sent over a reliable transport,
+ because there is nothing there to catch it. Guaranteed delivery
+ requires both store and forward notification and a reliable
+ transport.
+
+2.21 Notification over Unreliable Transport
+
+ Notifications are delivered via the fundamental transport address and
+ routing framework, but no acknowledgment or retry is required.
+ Process to process communications, if involved, are unconstrained.
+
+
+2.22 Human Consumable Notification
+
+ Notifications which are intended to be consumed by human end users
+ only. Email would be an example of a Human consumable notification,
+ though it could also contain Machine Consumable Notification.
+
+2.23 Machine Consumable Notification
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 7]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+
+ Notifications which are intended for consumption by a program only,
+ such as an IPP Client. Machine Consumable notifications may not
+ contain human readable information. Do we need both human and
+ machine? Machine readable is intended for application to application
+ only. The Notification Recipient could process the machine readable
+ Event Notification into human readable format.
+
+2.24 Mixed Notification
+
+ A mixed notification contains both Human Consumable and Machine
+ Consumable information.
+
+3 Scenarios
+
+ 1.I am sitting in my office and submit a print job to the printer
+ down the hall. I am in the same security domain as the printer and
+ of course, geographically near. I want to know immediately when
+ my print job will be completed (or if there is a problem) because
+ the document I am working on is urgent. I submit the print job
+ with the following attributes:
+
+ . Notification Recipient - me
+ . Notification Events - all
+ . Notification Attributes - job-state-reason
+ . Notification Type - immediate
+
+ 2.I am working from home and submit a print job to the same printer
+ as in the previous example. However, since I am not at work, I
+ cannot physically get the print file or do anything with it. It
+ can wait until I get to work this afternoon. However, I'd like my
+ secretary to pick up the output and put it on my desk so it
+ doesn't get lost or miss-filed. I'd also like a store and forward
+ notification sent to my email so that when I get to work I can
+ tell if there was a problem with the print job. I submit a print
+ job with the following attributes:
+
+ . Notification Recipient - my secretary
+ . Notification Events - print complete
+ . Notification Type - immediate
+
+ . Notification Recipient - me
+ . Notification Events - print complete
+ . Notification Attributes - impressions completed
+ . Notification Type - store and forward
+
+ 3.I am sitting in my office and submit a print job to a client at an
+ engineering firm we work with on a daily basis. The engineering
+ firm is in Belgium. I would like my client to know when the print
+ job is complete, so that she can pick it up from the printer in
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 8]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ her building. It is important that she review it right away and
+ get her comments back to me. I submit the print job with the
+ following attributes:
+
+
+ . Notification Recipient - client at engineering firm
+ . Notification Events - print complete
+ . Notification Type - immediate
+ . Notification Language - French
+
+ 4.I am in a hotel room and send a print job to a Kinko's store in
+ the town I am working in, in order to get a printed report for the
+ meeting I am attending in the morning. Since I'm going out to
+ dinner after I get this job submitted, an immediate notification
+ won't do me much good. However, I'd like to check in the morning
+ before I drive to the Kinko's store to see if the file has been
+ printed. An email notification is sufficient for this purpose. I
+ submit the print job with the following attributes:
+
+ . Notification Recipient - me
+ . Notification Events - print complete
+ . Notification Type - store and forward
+
+ 5.I am printing a large, complex print file. I want to have some
+ immediate feedback on the progress of the print job as it prints.
+ I submit the print job with the following attributes:
+
+ . Notification Recipient - me
+ . Notification Type - immediate
+ . Notification Events - all state transitions
+ . Notification Attributes - impression completed
+
+ 6.I am an operator and my duties is to keep the printer running. I
+ subscribe independently from a job submission so that my
+ subscription outlasts any particular job. I subscribe with the
+ following attributes:
+
+ . Notification Recipient - me
+ . Notification Type - immediate
+ . Notification Events - all Printer state transitions
+ . Notification Attributes - Printer state, printer state reasons,
+ device powering up, device powering down.
+
+ 7.I am a usage statistics gathering application. I subscribe
+ independently from a job submission so that my subscription
+ outlasts any particular job. My subscription may persists across
+ power cycles. I subscribe with the following attributes:
+
+ . Notification Recipient - me
+ . Notification Type - immediate
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 9]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ . Notification Events - job completion
+ . Notification Attributes - impression completed, sheets
+ completed, time submitted, time started, time completed, job
+ owner, job size in octets, etc.
+
+ 8.I am a client application program that displays a list of jobs
+ currently queued for printing on a printer. I display the "job-
+ name", "job-state", "job-state-reasons", "page-count", and
+ "intervening-jobs" either for the user's jobs or for all jobs.
+ The window displaying the job list remains open for an independent
+ amount of time, and it is desired that it represent the current
+ state of the queue. It is desired that the application only need
+ to perform a slow poll in order to recover from any missed
+ notifications. So the event delivery mechanism provides the means
+ to update the screen on all needed changes, including querying for
+ some attributes that may not be delivered in the Notification.
+
+ 9.I am a client application program that displays a list of
+ printers. For each Printer I display the current state and
+ configuration. The window displaying the printer list remains
+ open for an independent amount of time, and it is desired that it
+ represent the current state of each printer. It is desired that
+ the application only need to perform a slow poll in order to
+ recover from any missed notifications. So the event delivery
+ mechanism provides the means to update the screen on all needed
+ changes, including querying for some attributes that may not be
+ delivered in the Notification.
+
+ 10. I am an IPP Server that controls one or more devices and
+ implements an IPP Printer object to represent each device. I want
+ to support IPP Notification for each of the IPP Printer objects
+ that I implement. Many of these devices do not support
+ notification (or IPP). So I need to support the IPP Notification
+ semantics specified for each IPP Printer object myself on behalf
+ of each of the devices that each of the IPP Printer objects
+ represent. When I accept IPP job creation requests, I convert the
+ request to what the device will accept. In some cases, I must
+ poll the devices in order to be informed of their job and device
+ state and state changes in order to be able to send IPP
+ Notifications to subscribed Notification Recipients.
+
+ 11. I am an IPP Server that controls one or more devices and
+ implements an IPP Printer object to represent each device. I want
+ to support IPP Notification for each of the IPP Printer objects
+ that I implement. These devices all support IPP, including IPP
+ Notification. I would like the design choice for supporting IPP
+ Notification for these IPP Printer objects that I implement either
+ (1) by forwarding the notification to the IPP Printers that I
+ alone control and have them send the notifications to the intended
+ Notification Recipients without my involvement or (2) replace the
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 10]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ notification submitted with the Job to indicate me as the
+ Notification Recipient and I will in turn forward Notifications to
+ the Notification Recipients requested by my clients. Most of the
+ rest of the contents of the IPP Job that I send to the IPP
+ Printers that I control will be the same as the IPP Job that I
+ receive from my IPP clients.
+
+ 12. I am an IPP Server that controls one or more devices and
+ implements an IPP Printer object to represent each device. I want
+ to support IPP Notification for each of the IPP Printer objects
+ that I implement. These devices all support IPP, including IPP
+ Notification. Because these IPP Printers MAY also be being
+ controlled by other servers (using IPP or other protocols), I only
+ want job events for the jobs that I send, but do want Printer
+ events all the time, so that I can show proper Printer state to my
+ clients. So I subscribe to these IPP Printers for Printer events
+ with a long standing subscription with myself to as the
+ Notification Recipient. When I get a Job Creation request, I
+ decide to which IPP Printer to send the job. When I do so, I also
+ add a job subscription for Job events with me as the Notification
+ Recipient to the job's job subscriptions supplied by my clients
+ (this usage is called "piggy-backing"). These IPP Printers
+ automatically remove their job subscriptions when the job
+ completes as for all job subscriptions so that I no longer get Job
+ events when my jobs are completed.
+
+4 Requirements
+
+ The following requirements are intended to be met by the IPP
+ Notification specification (not the implementation). The resulting
+ IPP Notification Specification document:
+
+ 1.must indicate which of these requirements are REQUIRED and which
+ are OPTIONAL for a conforming implementation to support. See
+ [RFC2911] section 12.1 for the definition of these important
+ conformance terms.
+
+ 2.must be designed to that an IPP Printer can transparently support
+ the IPP Notification semantics using third party notification
+ services that exist today or that may be standardized in the
+ future.
+
+ 3.must define means for a Job Submitting End User to specify zero or
+ more Notification Recipients when submitting a print job. A
+ Submitter will not be able to prevent out of band subscriptions
+ from authorized persons, such as Operators.
+
+ 4.must define means when specifying a Notification Recipient, for a
+ Notification Subscriber to be able to specify one or more
+ notification events for that Notification Recipient, subject to
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 11]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ administrative and security policy restrictions. Any of the
+ following constitute Job or Printer Events that a Job Submitting
+ End User can specify notifications be sent for:
+ . Any standard Printer MIB alert (i.e. device alerts) (critical
+ and warning?) (state change notifications)?
+ . Job Received (transition from Unknown to Pending)
+ . Job Started (Transition from Pending to Processing)
+ . Page Complete (Page is stacked)
+ . Collated Copy Complete (last sheet of collated copy is
+ stacked)
+ . Job Complete (transition from Processing or Processing-
+ stopped to Completed)
+ . Job aborted (transition from Pending, Pending-held,
+ Processing, or Processing-stopped to Aborted)
+ . Job canceled (transition from Pending, Pending-held,
+ Processing, or Processing-held to Canceled)
+ . Other job state changes like 'paused', purged?
+ . Device problems for which the job is destined
+ . Job (interpreter) issues
+
+
+ 5.must define how an End User or Operator subscribes for:
+ . Any set of Job Events for a specific job.
+ . Any set of Printer Events while a specific job is not
+ complete.
+
+ 6.must define how an End User or Operator subscribes for the
+ following without having to submit a Job:
+ . Any set of Printer Events for a defined period.
+ . Any set of Job Events for all jobs with no control over which
+ jobs.
+
+ 7.must define how the Notification Subscriber is able to specify
+ either immediate or store and forward notification independently
+ for each Notification Recipient. The means may be explicit, or
+ implied by the method of delivery chosen by the Job Submitting End
+ User.
+
+ 8.must define common delivery methods, e.g. email, must be defined.
+
+ 9.must define how an IPP Printer validates its ability to deliver an
+ Event using the specified delivery scheme. If it does not support
+ the specified scheme, or the specified scheme is invalid for some
+ reason, then the IPP Printer accepts and performs the request
+ anyway and responds indicating the unsupported attribute values.
+ There is no requirement for the IPP Printer receiving the print
+ request to validate the identity of an Notification Recipient, nor
+ the ability of the system to deliver an event to that recipient as
+ requested (for example, if the Notification Recipient is not at
+ work today).
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 12]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+
+ 10. must define a class of IPP event notification delivery methods
+ which can flow through corporate firewalls. However, an IPP
+ printer need not test to guarantee delivery of the notification
+ through a firewall before accepting a print job.
+ 11. may define means for delivering a notification to the
+ submitting client when the delivery of an event notification to a
+ specified Notification Recipient fails. Fall back means of
+ subscribers determining if notifications have failed, i.e.
+ polling, may be provided.
+
+ 12. must define a mechanism for localizing Human Consumable
+ notifications by the Notification Source.
+
+ 13. may define a way to specify whether or not event delivery
+ requires acknowledgement back to the Notification Source.
+
+ 14. There must be a mechanism defined so that job independent
+ subscriptions do not become stale and do not require human
+ intervention to remove stale subscriptions. However, stale must
+ not be the inability to deliver an Event Notification , since
+ temporary Notification delivery problems must be tolerated.
+
+ 15. A mechanism must be defined so that an Event Subscriber is
+ able to add an Event Subscription to a Job after the Job has been
+ submitted.
+
+ 16. A mechanism must be defined so that a client is able to cancel
+ an Event Subscription on a job or printer after the job has been
+ submitted.
+
+ 17. A mechanism must be defined so that a client can obtain the
+ set of current Subscriptions.
+
+5 Security considerations for IPP Notifications requirements
+
+ By far the biggest security concern is the abuse of notification:
+ sending unwanted notifications to third parties (i.e., spam). The
+ problem is made worse by notification addresses that may be
+ redistributed to multiple parties (e.g. mailing lists). There exist
+ scenarios where third party notification is required (see Scenario #2
+ and #3). The fully secure solution would require active agreement of
+ all recipients before sending out anything. However, requirement #9
+ ("There is no requirement for IPP Printer receiving the print request
+ to validate the identity of an event recipient") argues against this.
+ Certain systems may decide to disallow third party notifications (a
+ traditional fax model).
+
+ Clients submitting notification requests to the IPP Printer has the
+ same security issues as submitting an IPP/1.1 print job request. The
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 13]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ same mechanisms used by IPP/1.1 can therefore be used by the client
+ notification submission. Operations that require authentication can
+ use the HTTP authentication. Operations that require privacy can use
+ the HTTP/TLS privacy.
+
+ The notification access control model should be similar to the IPP
+ access control model. Creating a notification subscription is
+ associated with a user. Only the creator or an operator can cancel
+ the subscription. The system may limit the listing of items to only
+ those items owned by the user. Some subscriptions (e.g. those that
+ have a lifetime longer than a job) can be done only by privileged
+ users (operators and/or administrators), if that is the authorization
+ policy.
+
+ The standard security concerns (delivery to the right user, privacy
+ of content, tamper proof content) apply to the notification delivery.
+ IPP should use the security mechanism of the delivery method used.
+ Some delivery mechanisms are more secure than others. Therefore,
+ sensitive notifications should use the delivery method that has the
+ strongest security.
+
+6 Internationalization Considerations
+
+ The Human Consumable notification must be localized to the natural
+ language and charset that Notification Subscriber specifies within
+ the choice of natural languages and charsets that the IPP Printer
+ supports.
+
+ The Machine Consumable notification data uses the 'application/ipp'
+ MIME media type. It contains some attributes whose text values are
+ required to be in the natural language and charset that the
+ Notification Subscriber specifies within the choice of natural
+ languages and charsets that the IPP Printer supports. See [RFC2566].
+
+7 IANA Considerations
+
+ There will be some notification delivery methods registered with IANA
+ for use in URLs. These will be defined in other documents.
+
+8 References
+
+ [RFC2565]
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
+
+ [RFC2566]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
+ April 1999.
+
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 14]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+ [RFC2567]
+ Wright, D., "Design Goals for an Internet Printing Protocol",
+ draft-ietf-ipp-req-03.txt, November, 1998.
+
+ [RFC2568]
+ Zilles, S., "Rationale for the Structure and Model and Protocol for
+ the Internet Printing Protocol", draft-ietf-ipp-rat-04.txt,
+ November, 1998.
+
+ [RFC2569]
+ Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
+ LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-05.txt, November
+ 1998.
+
+ [RFC2639]
+ T. Hastings, C. Manros. "Internet Printing Protocol/1.0:
+ Implementer's Guide", RFC 2639, July 1999.
+
+ [RFC2911]
+ deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
+ "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911,
+ September 2000.
+
+9 Author's Address
+
+ Harry Lewis
+ HUC/003G
+ IBM Corporation
+ P.O. Box 1900
+ Boulder, CO 80301-9191
+
+ Phone: (303) 924-5337
+ Fax: (303) 924-9889
+ e-mail: harryl@us.ibm.com
+
+ Roger deBry
+ Utah Valley State College
+ Orem, UT 84058
+
+ Phone: (801) 222-8000
+ e-mail: debryro@uvsc.edu
+
+ Tom Hastings (editor)
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 15]
+\f
+
+INTERNET DRAFT IPP/1.1: Notification Requirements January 23, 2001
+
+
+
+ IPP Mailing List: ipp@pwg.org
+ IPP Mailing List Subscription: ipp-request@pwg.org
+ IPP Web Page: http://www.pwg.org/ipp/
+
+10 Appendix A: Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998,1999,2000,2001). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+deBry, Lewis, Hastings Expires July 23, 2001 [Page 16]
+++ /dev/null
-INTERNET-DRAFT
-<draft-ietf-ipp-not-http-delivery-00.txt>
- Hugo Parra
- Novell, Inc.
- October 19, 1999
-
- Internet Printing Protocol/1.1: HTTP-Based IPP Notification Delivery
- Protocol
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-The IPP notification specification [ipp-ntfy] requires the availability
-of one or more delivery methods for dispatching notification reports to
-interested parties. This document describes the semantics and syntax of
-a protocol that a delivery method may use to deliver IPP notifications
-using HTTP for a transport.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra [page 1]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
- Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting over HTTP a message
-body whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-
-Parra [page 2]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-
-
- Table of Contents
-
-
-1 Introduction......................................................4
-
-2 Model and Operation...............................................4
- 2.1HTTP NOTIFICATION OPERATIONS.....................................4
- 2.1.1 Report-Ipp-Notifications....................................5
- 2.2HTTP NOTIFICATION PROTOCOL URI SCHEME............................7
-
-3 Encoding of the Operation Layer...................................7
-
-4 Encoding of Transport Layer.......................................9
-
-5 IANA Considerations..............................................10
-
-6 Internationalization Considerations..............................10
-
-7 Security Considerations..........................................10
- 7.1SECURITY CONFORMANCE............................................10
-
-8 References.......................................................11
-
-9 Author's Addresses...............................................11
-
-10 Full Copyright Statement.........................................11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra [page 3]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-
-
-1 Introduction
-
-IPP printers that support IPP notification either a) accept, store, and
-use notification subscriptions to generate notification reports and
-implement one or more delivery methods for notifying interested parties,
-or b) support a subset of these tasks and farm out the remaining tasks
-to a Notification Delivery Service. The protocol specified in this
-document may be used in a variety of notification scenarios. Its primary
-intended use is for IPP printers to send notifications to notification
-recipients over HTTP. However, it may also be used by IPP printers to
-send notification to Notification Services and by Notification Delivery
-Services to send notifications to notification recipients.
-
-
-2 Model and Operation
-
-The HTTP-Based IPP Notification Protocol, hereafter referred to as HTTP
-notification protocol, is a client/server protocol. The "client" in this
-HTTP relationship is the notification source described in [ipp-ntfy]
-while the "server" is the notification recipient. The notification
-source invokes operations supported by the HTTP notification protocol to
-communicate IPP Notification contents to the notification recipient. The
-notification recipient only conveys information to the notification
-source in the form of responses to the operations initiated by the
-notification source.
-
-HTTP notification requests will be issued as HTTP POST operations and
-their corresponding HTTP notification responses will be returned in the
-responses to those HTTP POST operations. Hence, notification sources
-that implement the HTTP notification protocol will need to include an
-HTTP client stack while notification recipients that implement this
-protocol will need to support an HTTP server stack (see section 4 for
-more details).
-
-
-1.12.1 HTTP Notification Operations
-
-
-The job of an HTTP notification source is to use the contents of an IPP
-Notification as defined in [ipp-ntfy] to compose and invoke the
-appropriate HTTP notification operation and send it to the specified
-HTTP notification recipient.
-
-The HTTP notification protocol makes extensive use of the operations
-model defined by IPP [rfc2566]. This includes, the use of a URI as the
-identifier for the target of each operation, the inclusion of a version
-number, operation-id, and request-id in each request, and the definition
-of attribute groups. The HTTP notification protocol uses the Operation
-Attributes group, but currently has no need for the Unsupported
-
-
-Parra [page 4]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-Attributes, Printer Object Attributes, and Job-Object Attributes groups.
-However, it defines a new attribute group, the Notification Attributes
-group.
-
-In its 1.0 version, the HTTP notification protocol is composed of a
-single operation, but may be extended in the future as needed (e.g., to
-find out specific capabilities of an HTTP notification listener). The
-operation currently defined is Send-Notifications.
-
-
-1.1.12.1.1Report-Ipp-Notifications
-
-This REQUIRED operation allows a notification source to send one or more
-notifications to notification recipient using HTTP. The operation has
-been tailored to accommodate the current definition of IPP Notification.
-
-
-Both 'machine-consumable' and 'human-consumable' notifications may be
-sent to an HTTP notification recipient through this operation.
-
-1.1.1.12.1.1.1 Send-Notifications Request
-
-The following groups of attributes are part of the Send-Notifications
-Request:
-
-Group 1: Operation Attributes
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-
- Target:
- The URI of the HTTP notification recipient.
-
-Group 2 to N: Notification Attributes
-
- "human-readable-report" (text)
- The HTTP notification source OPTIONALLY supplies this attribute. A
- text string generated by the IPP printer or Notification Delivery
- Service from the contents of the IPP Notification suitable for
- human consumption.
-
- ISSUE 1 - Ok to extend Notification Model to allow a single
- notification to have both Human Consumable form and Machine
- Consumable form when the client asks for Human Consumable form by
- supplying the "notify-text-format" attribute.
-
-
-
-
-
-
-
-
-
-
-Parra [page 5]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
- "version-number" (integer (0:32767))
- "status-code" (integer (0:32767))
- "request-id" (integer (0:MAX))
- "attributes-charset" (charset)
- "attributes-natural-language" (naturalLanguage)
- "printer-uri" (uri)
- "printer-name" (name(127))
- "job-id" (integer(1:MAX))
- "job-name" (name(MAX))
- "trigger-event" (type2 keyword)
- "trigger-time" (integer(MIN:MAX))
- "trigger-date-time" (dateTime)
- "subscription-id" (integer(1:MAX))
- "subscriber-user-name" (name(MAX))
- "subscriber-user-data" (octetString(63))
- "job-state" (type1 enum)
- "job-state-reasons" (1setOf type2 keyword)
- "job-k-octets-processed" (integer(0:MAX))
- "job-impressions-completed" (integer(0:MAX))
- "job-media-sheets-completed" (integer(0:MAX))
- "job-collation-type" (type2 enum)
- "sheet-completed-copy-number" (integer(-2:MAX))
- "sheet-completed-document-number" (integer(-2:MAX))
- "impressions-interpreted" (integer(-2:MAX))
- "impressions-completed-current-copy" (integer(-2:MAX))
- "printer-state" (type1 enum)
- "printer-state-reasons" (1setOf type2 keyword)
- "printer-is-accepting-jobs" (boolean)
-
-These attributes communicate the same information as the notification
-attributes by the same name described in sections 7.4, 7.5, and 7.6 of
-[ipp-ntfy]. The rules that govern when each individual attribute MUST or
-MAY be included in this operation precisely mirror those specified in
-[ipp-ntfy].
-
-
-1.1.1.22.1.1.2 Send-Notifications Response
-
-The HTTP notification recipient returns a status code for the entire
-operation and one for each Notification Report in the request if the
-operation's status code is other than "success-ok". If the HTTP
-notification listener receives a Notification report that it can't pair
-up with a subscription it knows about, it can return an error status-
-code to indicate that events associated with that subscription should no
-longer be sent to it.
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes ads defined in [rfc 2566] section 3.1.4.1.
-Group 2 to N: Notification Attributes
-
-
-Parra [page 6]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-"notification-report-status-code" (type2 enum)
- Indicates whether the HTTP notification listener was able to consume
- the n-th Notification Report.
-
-1.22.2 HTTP Notification Protocol URI Scheme
-
-
-ISSUE 2 - Should the URI scheme for this protocol be "http://",
-"ipp://", or something else like "ipp-ntfy://". If we intent this
-proposal to go to the IESG, something along the lines of the third
-option might be our only alternative
-
-
-3 Encoding of the Operation Layer
-
-The HTTP notification protocol uses the same operation layer encoding
-model and syntax as IPP [ipp-pro] with two extensions:
-
- a) A new attribute tag is defined:
-
- notification-report-tag = %x07 ; tag of 7
-
- b) The following status codes are defined
-
- 0xYYYY - unknown-notification-recipient.
- 0xZZZZ - unable-to-delivery-notification-report
-
- ISSUE 3 - Should we add a success status code, say,
- 'successful-ok-but-cancel-subscription' which requests that
- the subscription be canceled. Then the Notification Recipient
- can cancel a subscription that another party established even
- though the Notification Recipient is not the owner of the
- Subscription.
-
-The encoding for the Report-IPP-Notification Request consists of:
-
- -----------------------------------
- | version-number | 2 byte
- -----------------------------------
- | operation-id | 2 bytes
- -----------------------------------
- | request-id | 4 bytes
- -----------------------------------
- | operation-attributes-tag | 1 byte
- -----------------------------------
- | natural-language-attribute | u bytes
- -----------------------------------
- | charset-attribute | v bytes
- -----------------------------------
- | target-attribute | w bytes
- ----------------------------------------------
- | notification-tag | 1 byte |
-
-
-Parra [page 7]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
- ----------------------------------- | - 1 or more
- | notification-attr-list | x bytes |
- ----------------------------------------------
- | end-of-attributes-tag | 1 byte
- -----------------------------------
-
-Where:
-
-version-number is made up of a major-version-number of %d1 and a minor-
-version-number of %d0 indicating the 1.0 version of the HTTP
-notification protocol.
-
-operation-id, in the 1.0 version of the protocol, can only be 0x00003,
-Report-IPP-Notification.
-
-request-id is any 4 byte number provided by the notification source and
-must be matched by the notification recipient in the corresponding
-response to a request. It assists the notification source in associating
-operation responses with their corresponding requests. Note that this
-request id is independent of the request id embedded in the notification
-report, which is opaque to the delivery method but assists the
-notification recipient order and identity missing or duplicate
-notification reports.
-
-operation-attribute tag, natural-language-attribute, charset-attribute,
-target-attribute, and end-of-attributes-tag have the same syntax and
-semantics as in [ipp-pro].
-
-notification-attr-list contains a list of the attributes that make up a
-single notification (see section 2 above) encoded using the syntax
-specified in [ipp-pro].
-
-The encoding for the Send-Notification Response consists of:
-
- -----------------------------------
- | version-number | 2 byte
- -----------------------------------
- | status-code | 2 bytes
- -----------------------------------
- | request-id | 4 bytes
- ----------------------------------- \
- | operation-attributes-tag | 1 byte |
- ----------------------------------- |
- | natural-language-attribute | u bytes | Not needed in 1.0
- ----------------------------------- > <ISSUE 4: Do we
- | charset-attribute | v bytes | want to keep it?>
- ----------------------------------- |
- | target-attribute | w bytes |
- ---------------------------------------------- /
- | notification-tag | 1 byte |
- ----------------------------------- | - 1 or more
-
-Parra [page 8]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
- | ntfy-status-code | 2 bytes |
- ----------------------------------------------
- | end-of-attributes-tag | 1 byte
- -----------------------------------
-
-4 Encoding of Transport Layer
-
-HTTP/1.1 [rfc2068] is the transport layer for this protocol.
-
-The operation layer has been designed with the assumption that the
-transport layer contains the following information:
-
- - the URI of the target job or printer operation.
-
- - the total length of the data in the operation layer, either as a
- single length or as a sequence of chunks each with a length.
-
-It is REQUIRED that an HTTP notification recipient implementation
-support HTTP over the IANA assigned Well Known Port XXX (the HTTP
-notification protocol default port), though a notification recipient
-implementation may support HTTP over some other port as well.
-
-Each HTTP operation MUST use the POST method where the request-URI is
-the object target of the operation, and where the "Content-Type" of the
-message-body in each request and response MUST be "application/ipp-
-ntfy". The message-body MUST contain the operation layer and MUST have
-the syntax described in section 3, "Encoding of Operation Layer". An
-HTTP notification source implementation MUST adhere to the rules for a
-client described for HTTP1.1 [rfc2068]. An HTTP notification recipient
-implementation MUST adhere the rules for an origin server described for
-HTTP1.1 [rfc2068].
-
-An HTTP notification source sends a response for each request that it
-receives. If a notification recipient detects an error, it MAY send a
-response before it has read the entire request. If the HTTP layer of the
-notification recipient completes processing the HTTP headers
-successfully, it MAY send an intermediate response, such as "100
-Continue", with no notification data before sending the notification
-response. HTTP notification sources MUST expect such a variety of
-responses from notification recipients. For further information on
-HTTP/1.1, consult the HTTP documents [rfc2068].
-
-An HTTP server MUST support chunking for HTTP notification requests, and
-an HTTP notification source MUST support chunking for HTTP notification
-responses according to HTTP/1.1[rfc2068]. Note: this rule causes a
-conflict with non-compliant implementations of HTTP/1.1 that don't
-support chunking for POST methods, and this rule may cause a conflict
-with non-compliant implementations of HTTP/1.1 that don't support
-chunking for CGI scripts
-
-
-
-Parra [page 9]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-5 IANA Considerations
-
-IANA will be asked to register this HTTP notification delivery scheme
-and assign a default port.
-
-
-6 Internationalization Considerations
-
-When the client requests Human Consumable form by supplying the "notify-
-text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or
-any Notification Service that the IPP Printer might be configured to
-use) localizes the text value of the "human-readable-report" attribute
-in the Notification according to the charset and natural language
-requested in the notification subscription.
-
-
-7 Security Considerations
-
-The IPP Model and Semantics document [ipp-mod] discusses high level
-security requirements (Client Authentication, Server Authentication and
-Operation Privacy). Client Authentication is the mechanism by which the
-client proves its identity to the server in a secure manner. Server
-Authentication is the mechanism by which the server proves its identity
-to the client in a secure manner. Operation Privacy is defined as a
-mechanism for protecting operations from eavesdropping.
-
-If we add the 'successful-ok-but-cancel-subscription' (see ISSUE 3 in
-section 3), then the Notification Recipient can cancel unwanted
-Subscriptions created by other parties without having to be the owner of
-the subscription.
-
-1.17.1 Security Conformance
-
-
-Notification sources MAY support:
-
- - Digest Authentication [rfc2069].
-
- - MD5 and MD5-sess MUST be implemented and supported.
-
- - The Message Integrity feature NEED NOT be used.
-
-Notification Recipient MAY support:
-
- - Digest Authentication [rfc2069].
-
- - MD5 and MD5-sess MUST be implemented and supported.
-
- - The Message Integrity feature NEED NOT be used.
-
-Notification recipients MAY support TLS for client authentication,
-server authentication and operation privacy. If a notification recipient
-
-
-Parra [page 10]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites
-are OPTIONAL. Notification recipients MAY support Basic Authentication
-(described in HTTP/1.1 [rfc2068]) for client authentication if the
-channel is secure. TLS with the above mandated cipher suite can provide
-such a secure channel.
-
-
-8 References
-
-[ipp-mod]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
- ipp-model-v11-04.txt>, June, 1999.
-
-[ipp-ntfy]
- Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
- Bergman, R., "Internet Printing Protocol/1.1: IPP Event
- Notification Specification", <draft-ietf-ipp-not-spec-01.txt>,
- October 14, 1999.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 03.txt, June, 1999.
-
-[rfc2068]
- R. Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1" RFC
- 2068, January 1997.
-
-[rfc2566]
- deBry, R., Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April 1999.
-
-
-9 Author's Addresses
-
- Hugo Parra
- Novell, Inc.
- 122 E 1700 S
- Provo, UT 84606
-
- Phone: 801-861-3307
- Fax: 801-861-2517
- e-mail: hparra@novell.com
-
-
-10 Full Copyright Statement
-
-Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-
-
-Parra [page 11]
-
- Expires: April 19, 2000
-\f
-
-
-INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Parra [page 12]
-
- Expires: April 19, 2000
+++ /dev/null
-
-Internet Printing Protocol Working Group Tom Hastings
-INTERNET DRAFT Xerox
-Expires 19 September 2000 Ira McDonald
- High North
- 19 March 2000
-
- Internet Printing Protocol (IPP):
- Notifications over SNMP via Job Monitoring MIB
- <draft-ietf-ipp-not-over-snmp-02.txt>
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-
-Abstract
-
- This document is a submission to the Internet Printing Protocol
- Working Group of the Internet Engineering Task Force (IETF).
- Comments should be submitted to the ipp@pwg.org mailing list.
-
- This document proposes a mapping of IPP notifications over SNMP via
- new device and job traps extensions defined for the Job Monitoring
- MIB [RFC-2707]. This mapping may be used to deliver printer
- notifications for any printer (not just IPP-capable ones) and also
- job notifications for any job (not just ones submitted via IPP).
-
- This document proposes: (4) SNMP traps; and (24) SNMP leaf objects
- (for use in various trap bindings).
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 1]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- Table of Contents
-
-1. Introduction ............................................... 4
- 1.1. Terminology for Conformance ............................ 4
-2. SNMP Network Management Framework .......................... 4
-3. Managed Object Mapping ..................................... 5
- 3.1. SNMP Mapping for IPP Printer Events .................... 5
- 3.2. SNMP Mapping for IPP Job Events ........................ 5
- 3.3. Rules for Encoding Notifications ....................... 6
- 3.4. Registration for IPP Notifications ..................... 7
- 3.4.1. Registration via IPP ............................... 7
- 3.4.2. Registration via SNMP .............................. 7
- 3.5. Relationship to other MIBs ............................. 8
- 3.5.1. MIB-II (RFC 1213) .................................. 8
- 3.5.2. Host Resources MIB (RFC 1514) ...................... 8
- 3.5.3. Printer MIB (RFC 1759) ............................. 8
-4. Managed Object Definitions ................................. 9
- 4.1. Device Basic Event Trap ................................ 9
- 4.1.1. jmDeviceBasicV2Event (notification) ................ 9
- 4.2. Job Basic Event Trap ................................... 10
- 4.2.1. jmJobBasicV2Event (notification) ................... 11
- 4.3. Job Completed Event Trap ............................... 11
- 4.3.1. jmJobCompletedV2Event (notification) ............... 12
- 4.4. Job Progress Event Trap ................................ 13
- 4.4.1. jmJobProgressV2Event (notification) ................ 13
- 4.5. Event Binding Group .................................... 14
- 4.5.1. jmEventTriggerEvent (object) ....................... 14
- 4.5.2. jmEventSubscriptionID (object) ..................... 15
- 4.5.3. jmEventSubscriberUserName (object) ................. 15
- 4.5.4. jmEventSubscriberUserData (object) ................. 16
- 4.5.5. jmEventDeviceURI (object) .......................... 16
- 4.5.6. jmEventDeviceName (object) ......................... 17
- 4.5.7. jmEventDeviceState (object) ........................ 17
- 4.5.8. jmEventDeviceStateReasons (object) ................. 17
- 4.5.9. jmEventDeviceIsAcceptingJobs (object) .............. 18
- 4.5.10. jmEventJobSetIndex (object) ....................... 18
- 4.5.11. jmEventJobIndex (object) .......................... 19
- 4.5.12. jmEventJobName (object) ........................... 19
- 4.5.13. jmEventJobState (object) .......................... 19
- 4.5.14. jmEventJobStateReasons (object) ................... 20
- 4.5.15. jmEventJobKOctets (object) ........................ 20
- 4.5.16. jmEventJobKOctetsProcessed (object) ............... 21
- 4.5.17. jmEventJobImpressions (object) .................... 21
- 4.5.18. jmEventJobImpressionsCompleted (object) ........... 21
- 4.5.19. jmEventJobMediaSheets (object) .................... 22
- 4.5.20. jmEventJobMediaSheetsCompleted (object) ........... 22
- 4.5.21. jmEventJobImpressionsCompletedCC (object) ......... 22
- 4.5.22. jmEventJobCollationType (object) .................. 23
- 4.5.23. jmEventJobSheetCompletedCopyNum (object) .......... 23
- 4.5.24. jmEventJobSheetCompletedDocNum (object) ........... 23
-5. IANA Considerations ........................................ 25
-
-Hastings, McDonald Expires 19 September 2000 [Page 2]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-6. Internationalization Considerations ........................ 25
-7. Security Considerations .................................... 25
-8. References ................................................. 26
-9. Change Log ................................................. 27
-10. Intellectual Property Notice .............................. 29
-11. Authors' Addresses ........................................ 29
-12. Full Copyright Statement .................................. 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 3]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-1. Introduction
-
- The IPP protocol [IPP-PRO] supports passive monitoring of IPP Printer
- and Job objects, via client polling of IPP object attributes using
- the 'Get-Printer-Attributes' and 'Get-Job-Attributes' operations.
-
- This IPP Notifications over SNMP mapping supports dynamic monitoring
- of IPP Printer and Job objects, via server generation of SNMP traps.
-
-
- 1.1. Terminology for Conformance
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted per [RFC-2119].
-
-
-2. SNMP Network Management Framework
-
- See: Section 1.1 'SNMPv1', section 1.2 'SNMPv2', and section 1.3
- 'SNMPv3' of [RFC-2576].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 4]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-3. Managed Object Mapping
-
-
-
- 3.1. SNMP Mapping for IPP Printer Events
-
- IPP Printer event attribute Job Monitoring MIB object mapping
- --------------------------- ---------------------------------
- version-number [no mapping - not useful]
- status-code [implicit in each generated trap]
- request-id [request-id in SNMP trap header]
- attributes-charset [no mapping - strings are UTF-8]
- attributes-natural-language [no mapping - no text bindings]
- printer-uri jmEventDeviceURI
- printer-name jmEventDeviceName
- job-id jmEventJobIndex
- [and jmEventJobSetIndex]
- job-name jmEventJobName
- trigger-event jmEventTriggerEvent
- trigger-time [sysUpTime in SNMP trap bindings]
- trigger-date-time [hrSystemDate in Host Res MIB]
- subscription-id jmEventSubscriptionID
- subscriber-user-name jmEventSubscriberUserName
- subscriber-user-data jmEventSubscriberUserData
- printer-state jmEventDeviceState
- printer-state-reasons jmEventDeviceStateReasons
- printer-is-accepting-jobs jmEventDeviceIsAcceptingJobs
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 5]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
- 3.2. SNMP Mapping for IPP Job Events
-
- IPP Job event attribute Job Monitoring MIB object mapping
- ----------------------- ---------------------------------
- version-number [no mapping - not useful]
- status-code [implicit in each generated trap]
- request-id [request-id in SNMP trap header]
- attributes-charset [no mapping - strings are UTF-8]
- attributes-natural-language [no mapping - no text bindings]
- printer-uri jmEventDeviceURI
- printer-name jmEventDeviceName
- job-id jmEventJobIndex
- [and jmEventJobSetIndex]
- job-name jmEventJobName
- trigger-event jmEventTriggerEvent
- trigger-time [sysUpTime in SNMP trap bindings]
- trigger-date-time [hrSystemDate in Host Res MIB]
- subscription-id jmEventSubscriptionID
- subscriber-user-name jmEventSubscriberUserName
- subscriber-user-data jmEventSubscriberUserData
- job-state jmEventJobState
- job-state-reasons jmEventJobStateReasons
-
- [job-completed - extra bindings]
- job-k-octets jmEventJobKOctets
- job-k-octets-processed jmEventJobKOctetsProcessed
- job-impressions jmEventJobImpressions
- job-impressions-completed jmEventJobImpressionsCompleted
- job-media-sheets jmEventJobMediaSheets
- job-media-sheets-completed jmEventJobMediaSheetsCompleted
-
- [job-progress - extra bindings]
- impressions-completed-current-copy jmEventJobImpressionsCompletedCC
- job-collation-type jmEventJobCollationType
- sheet-completed-copy-number jmEventJobSheetCompletedCopyNum
- sheet-completed-document-number jmEventJobSheetCompletedDocNum
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 6]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
- 3.3. Rules for Encoding Notifications
-
- Over some transports and/or media, the variable-bindings of these
- SNMP traps MAY not fit the MTU (maximum transmission unit) size.
- Conforming IPP Notification generators SHALL perform this procedure
- to ensure that all variable-bindings of these SNMP traps are always
- included in the generated SNMP trap packet:
-
- 1) Truncate all strings specified for variable-bindings
- to the reduced maximum sizes that are specified in their
- corresponding OBJECT clauses in their MODULE-COMPLIANCE.
- 1a) If all variable-bindings now fit within the MTU,
- then exit this procedure and generate the SNMP trap.
- 2) Truncate the next one of the following string objects to
- the empty string (zero length in the ASN.1 BER encoding),
- in the order listed:
- - 'jmEventSubscriberUserName'
- - 'jmEventSubscriberUserData'
- - 'jmEventDeviceURI'
- - 'jmEventDeviceName'
- - 'jmEventDeviceStateReasons'
- - 'jmEventJobName'
- - 'jmEventJobStateReasons'
- 2a) If all variable-bindings now fit within the MTU,
- then exit this procedure and generate the SNMP trap.
- 2b) If all variable-bindings do NOT fit within the MTU,
- then repeat step (2) for next string object.
- 3) If all variable-bindings do NOT fit within the MTU,
- then -> logic error (variable-bindings MUST now fit).
-
-
- 3.4. Registration for IPP Notifications
-
- IPP Clients may register for IPP Notifications delivered via SNMP by
- either of the following methods:
-
-
- 3.4.1. Registration via IPP
-
- IPP Create-Subscription and Job creation (Create-Job, Print-Job,
- Print-URI) operations MAY be used to create per-Printer or per-Job
- IPP Subscription objects and MAY specify
-
- 'notify-recipient' = 'snmpnotify://hostname[.port]'
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 7]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
- 3.4.2. Registration via SNMP
-
- SNMP Set-Request operations MAY be used to create appropriate rows in
- the SNMP Notification MIB defined in [RFC-2573] and MAY specify:
-
- 1) 'snmpNotifyTag'
- - tag of this notification - see 'snmpTargetAddrTagList' below
- - example "jmDeviceBasicV2Event" or "jmJobBasicV2Event"
- 2) 'snmpNotifyType'
- - notification sent using either SNMP Trap (unacknowledged)
- or SNMP Inform-Request (acknowledged)
- 3) 'snmpNotifyStorageType'
- - row persistence of this registration
-
-
- SNMP Set-Request operations MAY be used to create appropriate rows in
- the SNMP Target MIB defined in [RFC-2573] and MAY specify:
-
- 1) 'snmpTargetAddrTDomain' and 'snmpTargetAddrTAddress'
- - target transport protocol and address (equivalent to URI)
- 2) 'snmpTargetAddressTimeout' and 'snmpTargetAddrRetryCount'
- - retry timeout and limit (for acknowledged notifications
- delivered using SNMP Inform-Request rather than SNMP Trap)
- 3) 'snmpTargetAddrTagList'
- - tags of notifications to be sent to this target (client)
- - example "jmDeviceBasicV2Event" or "jmJobBasicV2Event"
- 4) 'snmpTargetAddrParamsEntry'
- - notification security and SNMP protocol version
- 5) 'snmpTargetAddrStorageType'
- - row persistence of this registration
-
-
- 3.5. Relationship to other MIBs
-
-
-
- 3.5.1. MIB-II (RFC 1213)
-
- All SNMPv1 trap messages include 'time-stamp' which is the value of
- the 'sysUpTime' object from MIB-II [RFC-1213].
-
- All SNMPv2 trap bindings include the 'sysUpTime' object from MIB-II
- [RFC-1213].
-
-
- 3.5.2. Host Resources MIB (RFC 1514)
-
- The 'jmDeviceBasicV2Event' trap defined in this document permits
- optional binding of the 'hrDeviceStatus', 'hrDevicePrinterStatus',
-
-Hastings, McDonald Expires 19 September 2000 [Page 8]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- and 'hrPrinterDetectedErrorState' objects from Host Resources MIB
- [RFC-1514].
-
-
- 3.5.3. Printer MIB (RFC 1759)
-
- The 'jmDeviceBasicV2Event' trap defined in this document permits
- optional binding of the 'hrDeviceStatus', 'hrDevicePrinterStatus',
- and 'hrPrinterDetectedErrorState' objects from Host Resources MIB
- [RFC-1514].
-
- The appropriate value of 'hrDeviceIndex' to use in the Printer MIB
- [RFC-1759] may be indicated by the instance suffix of the
- 'hrDeviceStatus' variable's OID.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 9]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-4. Managed Object Definitions
-
-
-
- 4.1. Device Basic Event Trap
-
- -- Device Basic Event Group (Cond Mandatory)
- --
- -- Implementation of this group is conditionally mandatory;
- -- mandatory for systems which send this Device event via SNMP.
-
- jmDeviceBasicV1Enterprise OBJECT-IDENTITY
- STATUS current
- DESCRIPTION
- "The value of the enterprise-specific OID in an SNMPv1 trap
- for a Device basic event' sent by this managed system."
- ::= { jobmonMIBNotifications 1 }
-
- jmDeviceBasicV2EventPrefix
- OBJECT IDENTIFIER ::= { jmDeviceBasicV1Enterprise 0 }
-
- jmDeviceBasicV2Event NOTIFICATION-TYPE
- OBJECTS {
- jmEventTriggerEvent,
- jmEventSubscriptionID,
- jmEventSubscriberUserName,
- jmEventSubscriberUserData,
- jmEventDeviceURI,
- jmEventDeviceName,
- jmEventJobSetIndex,
- jmEventJobIndex,
- jmEventJobName,
- jmEventDeviceState,
- jmEventDeviceStateReasons,
- jmEventDeviceIsAcceptingJobs
- }
- STATUS current
- DESCRIPTION
- "This SMIv2 trap corresponds to an IPP Printer basic event.
-
- This trap is sent when requested by a prior subscription.
- The event type is specified in 'jmEventTriggerEvent'.
-
- Event types reported via 'jmDeviceBasicV2Event' include:
- - 'printer-restarted'
- - 'printer-shutdown'
- - 'printer-state-changed'
- - 'printer-media-changed'
- - 'printer-config-changed'
-
-Hastings, McDonald Expires 19 September 2000 [Page 10]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- - 'printer-queue-changed'
- - 'printer-no-longer-full'
- - 'printer-almost-idle'
- - 'device-restarted'
- - 'device-shutdown'
- - 'device-state-changed'
- - 'device-media-changed'
- - 'device-config-changed'
- - 'device-queue-changed'
- - 'device-no-longer-full'
- - 'device-almost-idle'
- - and (optionally) vendor extension event types
-
- Additional variable-bindings SHOULD be appended to this trap
- for all device-level events:
- - Systems with the Host Resources MIB [RFC-1514] SHOULD add
- 'hrSystemDate'
- (compare to IPP 'printer-current-time') and
- 'hrDeviceStatus'
- (compare to IPP 'printer-state')
-
- Additional variable-bindings MAY be appended to this trap
- for all printer-specific events:
- - Systems with the Host Resources MIB [RFC-1514] MAY add
- 'hrPrinterStatus'
- (compare to IPP 'printer-state') and
- 'hrPrinterDetectedErrorState'
- (compare to IPP 'printer-state-reasons')
-
- Systems MAY add other variable-bindings from any MIB.
-
- See: Section 5.2 'notify-events' of [IPP-NOT];
- Section 7 'Notification Content' in [IPP-NOT]."
- ::= { jmDeviceBasicV2EventPrefix 1 }
-
-
- 4.2. Job Basic Event Trap
-
- -- Job Basic Event Group (Cond Mandatory)
- --
- -- Implementation of this group is conditionally mandatory;
- -- mandatory for systems which send this Job event via SNMP.
-
- jmJobBasicV1Enterprise OBJECT-IDENTITY
- STATUS current
- DESCRIPTION
- "The value of the enterprise-specific OID in an SNMPv1 trap
- for a Job basic event sent by this managed system."
- ::= { jobmonMIBNotifications 2 }
-
- jmJobBasicV2EventPrefix
-
-Hastings, McDonald Expires 19 September 2000 [Page 11]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- OBJECT IDENTIFIER ::= { jmJobBasicV1Enterprise 0 }
-
- jmJobBasicV2Event NOTIFICATION-TYPE
- OBJECTS {
- jmEventTriggerEvent,
- jmEventSubscriptionID,
- jmEventSubscriberUserName,
- jmEventSubscriberUserData,
- jmEventDeviceURI,
- jmEventDeviceName,
- jmEventJobSetIndex,
- jmEventJobIndex,
- jmEventJobName,
- jmEventJobState,
- jmEventJobStateReasons
- }
- STATUS current
- DESCRIPTION
- "This SMIv2 trap corresponds to an IPP Job basic event.
-
- This trap is sent when requested by a prior subscription.
- The event type is specified in 'jmEventTriggerEvent'.
-
- Event types reported via 'jmJobBasicV2Event' include:
- - 'job-created'
- - 'job-state-changed'
- - 'job-config-changed'
- - 'job-purged'
- - and (optionally) vendor extension event types
-
- Systems MAY add other variable-bindings from any MIB.
-
- See: Section 5.2 'notify-events' of [IPP-NOT];
- Section 7 'Notification Content' in [IPP-NOT]."
- ::= { jmJobBasicV2EventPrefix 1 }
-
-
- 4.3. Job Completed Event Trap
-
- -- Job Completed Event Group (Cond Mandatory)
- --
- -- Implementation of this group is conditionally mandatory;
- -- mandatory for systems which send this Job event via SNMP.
-
- jmJobCompletedV1Enterprise OBJECT-IDENTITY
- STATUS current
- DESCRIPTION
- "The value of the enterprise-specific OID in an SNMPv1 trap
- for a Job completed event sent by this managed system."
- ::= { jobmonMIBNotifications 3 }
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 12]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
- jmJobCompletedV2EventPrefix
- OBJECT IDENTIFIER ::= { jmJobCompletedV1Enterprise 0 }
-
- jmJobCompletedV2Event NOTIFICATION-TYPE
- OBJECTS {
- jmEventTriggerEvent,
- jmEventSubscriptionID,
- jmEventSubscriberUserName,
- jmEventSubscriberUserData,
- jmEventDeviceURI,
- jmEventDeviceName,
- jmEventJobSetIndex,
- jmEventJobIndex,
- jmEventJobName,
- jmEventJobState,
- jmEventJobStateReasons,
- jmEventJobKOctetsProcessed,
- jmEventJobImpressionsCompleted,
- jmEventJobMediaSheetsCompleted
- }
- STATUS current
- DESCRIPTION
- "This SMIv2 trap corresponds to an IPP 'job-completed' event.
-
- This trap is sent when requested by a prior subscription.
- The event type is specified in 'jmEventTriggerEvent'.
-
- Event types reported via 'jmJobCompletedV2Event' include:
- - 'job-completed'
- - and (optionally) vendor extension event types
-
- Additional variable-bindings SHOULD be appended to this trap
- for all 'job-completed' events:
- - Systems which support this job information SHOULD add
- 'jmEventJobKOctets'
- (compare to IPP 'job-k-octets' job size attribute
- and to Job Mon MIB 'jobKOctetsTransferred' attribute)
- 'jmEventJobImpressions'
- (compare to IPP 'job-impressions' job size attribute)
- 'jmEventJobMediaSheets'
- (compare to IPP 'job-media-sheets' job size attribute
- and to Job Mon MIB 'sheetsRequested' attribute)
-
- Systems MAY add other variable-bindings from any MIB.
-
- See: Section 5.2 'notify-events' of [IPP-NOT];
- Section 7 'Notification Content' in [IPP-NOT]."
- ::= { jmJobCompletedV2EventPrefix 1 }
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 13]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
- 4.4. Job Progress Event Trap
-
- -- Job Progress Event Group (Cond Mandatory)
- --
- -- Implementation of this group is conditionally mandatory;
- -- mandatory for systems which send this Job event via SNMP.
-
- jmJobProgressV1Enterprise OBJECT-IDENTITY
- STATUS current
- DESCRIPTION
- "The value of the enterprise-specific OID in an SNMPv1 trap
- for a Job progress event sent by this managed system."
- ::= { jobmonMIBNotifications 4 }
-
- jmJobProgressV2EventPrefix
- OBJECT IDENTIFIER ::= { jmJobProgressV1Enterprise 0 }
-
- jmJobProgressV2Event NOTIFICATION-TYPE
- OBJECTS {
- jmEventTriggerEvent,
- jmEventSubscriptionID,
- jmEventSubscriberUserName,
- jmEventSubscriberUserData,
- jmEventDeviceURI,
- jmEventDeviceName,
- jmEventJobSetIndex,
- jmEventJobIndex,
- jmEventJobName,
- jmEventJobState,
- jmEventJobStateReasons,
- jmEventJobKOctetsProcessed,
- jmEventJobImpressionsCompleted,
- jmEventJobMediaSheetsCompleted,
- jmEventJobImpressionsCompletedCC,
- jmEventJobCollationType,
- jmEventJobSheetCompletedCopyNum,
- jmEventJobSheetCompletedDocNum
- }
- STATUS current
- DESCRIPTION
- "This SMIv2 trap corresponds to an IPP 'job-progress' event.
-
- This trap is sent when requested by a prior subscription.
- The event type is specified in 'jmEventTriggerEvent'.
-
- Event types reported via 'jmJobProgressV2Event' include:
- - 'job-progress'
- - and (optionally) vendor extension event types
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 14]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
- Additional variable-bindings SHOULD be appended to this trap
- for all 'job-progress' events:
- - Systems which support this job information SHOULD add
- 'jmEventJobKOctets'
- (compare to IPP 'job-k-octets' job size attribute
- and to Job Mon MIB 'jobKOctetsTransferred' attribute)
- 'jmEventJobImpressions'
- (compare to IPP 'job-impressions' job size attribute)
- 'jmEventJobMediaSheets'
- (compare to IPP 'job-media-sheets' job size attribute
- and to Job Mon MIB 'sheetsRequested' attribute)
-
- Systems MAY add other variable-bindings from any MIB.
-
- See: Section 5.2 'notify-events' of [IPP-NOT];
- Section 7 'Notification Content' in [IPP-NOT]."
- ::= { jmJobProgressV2EventPrefix 1 }
-
-
- 4.5. Event Binding Group
-
- -- Event Binding Group (Cond Mandatory)
- --
- -- Implementation of this group is conditionally mandatory;
- -- mandatory for systems which send Device or Job events via SNMP.
- --
- -- Note: All of the objects in this group are defined ONLY for the
- -- purpose of providing instantaneous bindings for SNMP traps - it's
- -- NEVER suitable for an SNMP Manager to Get these objects directly.
-
- jmEventBinding OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 }
-
- jmEventTriggerEvent OBJECT-TYPE
- SYNTAX JmUTF8StringTC (SIZE (0..63)) -- 255 in [IPP-MOD]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The trigger event type associated with this event.
-
- Standard Printer event types defined in [IPP-NOT] are:
- - 'printer-restarted'
- - 'printer-shutdown'
- - 'printer-state-changed'
- - 'printer-media-changed'
- - 'printer-config-changed'
- - 'printer-queue-changed'
- - 'printer-no-longer-full'
- - 'printer-almost-idle'
-
- Standard Device event types generalized from [IPP-NOT] are:
-
-Hastings, McDonald Expires 19 September 2000 [Page 15]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- - 'device-restarted'
- - 'device-shutdown'
- - 'device-state-changed'
- - 'device-media-changed'
- - 'device-config-changed'
- - 'device-queue-changed'
- - 'device-no-longer-full'
- - 'device-almost-idle'
-
- Standard Job event types defined in [IPP-NOT] are:
- - 'job-created'
- - 'job-completed'
- - 'job-state-changed'
- - 'job-config-changed'
- - 'job-purged'
- - 'job-progress'
-
- Conformance: The natural language for keywords
- in trigger event type SHALL always be US English.
-
- Conformance: This trigger event type SHALL be valid
- and reported in ALL Job Monitoring MIB notifications.
-
- See: Section 5.2 'notify-events' and
- Section 7 'Notification Content' in [IPP-NOT]."
- -- DEFVAL intentionally omitted - reported value SHALL be valid
- ::= { jmEventBinding 1 }
-
- jmEventSubscriptionID OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The subscription identifier associated with this event
- or zero (if none).
-
- Conformance: This subscription identifier SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 5.8 'subscription-id' and
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { 0 } -- no subscription ID
- ::= { jmEventBinding 2 }
-
- jmEventSubscriberUserName OBJECT-TYPE
- SYNTAX JmUTF8StringTC (SIZE (0..63)) -- 1023 in [IPP-MOD]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The subscriber user name associated with this event
- or the empty string (if none).
-
-Hastings, McDonald Expires 19 September 2000 [Page 16]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
- Note: The natural language appropriate for text-to-speech
- of subscriber user name is orthogonal to the localized text
- context in IPP 'attributes-natural-language'. The subscriber
- user name MAY include an in-line 'language tag' using Plane
- 14 'language tag' characters approved for ISO 10646/Unicode.
-
- Conformance: This subscriber user name SHALL be valid
- and reported, if available on this managed system.
-
- See: 'Language Tagging in Unicode Plain Text', RFC 2482
- (January 1999);
- 'Plane 14 Characters for Language Tags', Unicode
- Technical Report #7 (January 1999);
- Section 4.3.6 'job-originating-user-name' and
- Section 4.4.2 'uri-authentication-supported'
- (usage of 'requesting-user-name') in [IPP-MOD];
- Section 5.11 'subscriber-user-name' and
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { ''H } -- no subscriber user name
- ::= { jmEventBinding 3 }
-
- jmEventSubscriberUserData OBJECT-TYPE
- SYNTAX OCTET STRING (SIZE (0..63)) -- 63 in [IPP-NOT]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The subscriber user data associated with this event
- or the empty string (if none).
-
- Conformance: This subscriber user data SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 5.4 'subscriber-user-data' and
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { ''H } -- no subscriber user data
- ::= { jmEventBinding 4 }
-
- jmEventDeviceURI OBJECT-TYPE
- SYNTAX OCTET STRING (SIZE (0..255)) -- 1023 in [IPP-MOD]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The device URI associated with this event
- or the empty string (if none).
-
- Conformance: This device URI SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 4.3.3 'job-printer-uri' in [IPP-MOD];
- Section 4.4.1 'printer-uri-supported' in [IPP-MOD];
-
-Hastings, McDonald Expires 19 September 2000 [Page 17]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { ''H } -- no device URI
- ::= { jmEventBinding 5 }
-
- jmEventDeviceName OBJECT-TYPE
- SYNTAX OCTET STRING (SIZE (0..127)) -- 127 in [IPP-MOD]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The device name associated with this event
- or the empty string (if none).
-
- Conformance: This device name SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 4.4.4 'printer-name' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { ''H } -- no device name
- ::= { jmEventBinding 6 }
-
- jmEventDeviceState OBJECT-TYPE
- SYNTAX INTEGER { -- enum in [IPP-MOD]
- unknown(2), -- unknown device state
- idle(3),
- processing(4),
- stopped(5)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The device state associated with this event
- or 'unknown'.
-
- Note: This object uses the keywords from the [IPP-MOD]
- enumerated type 'printer-state' for coherence.
-
- Conformance: This device state SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 4.4.11 'printer-state' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { unknown } -- unknown device state
- ::= { jmEventBinding 7 }
-
- jmEventDeviceStateReasons OBJECT-TYPE
- SYNTAX OCTET STRING (SIZE (0..255)) -- 255*n in [IPP-MOD]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The device state reasons associated with this event
- (as a comma-separated list) or the empty string (if none).
-
-Hastings, McDonald Expires 19 September 2000 [Page 18]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
- Conformance: The natural language for keywords
- in device state reasons SHALL always be US English.
-
- Conformance: These device state reasons SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 4.4.12 'printer-state-reasons' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { ''H } -- no device state reasons
- ::= { jmEventBinding 8 }
-
- jmEventDeviceIsAcceptingJobs OBJECT-TYPE
- SYNTAX TruthValue
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The device substate associated with this event
- or 'true' (if unknown).
-
- Conformance: This device substate SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 4.4.23 'printer-is-accepting-jobs'
- in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { true } -- device is accepting jobs
- ::= { jmEventBinding 9 }
-
- jmEventJobSetIndex OBJECT-TYPE
- SYNTAX Integer32 (0..32767)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job set index associated with this event
- or zero (if none).
-
- Conformance: This job set index SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jmGeneralJobSetIndex' object in [RFC-2707];
- Section 4.3.2 'job-id' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { 0 } -- no job set index
- ::= { jmEventBinding 10 }
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 19]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- jmEventJobIndex OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job index associated with this event
- or zero (if none).
-
- Conformance: This job index SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jmJobIndex' object in [RFC-2707];
- Section 4.3.2 'job-id' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { 0 } -- no job index
- ::= { jmEventBinding 11 }
-
- jmEventJobName OBJECT-TYPE
- SYNTAX OCTET STRING (SIZE (0..255)) -- 255 in [IPP-MOD]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job name associated with this event
- or the empty string (if none).
-
- Conformance: This job name SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jobName' attribute in [RFC-2707];
- Section 4.3.5 'job-name' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { ''H } -- no job name
- ::= { jmEventBinding 12 }
-
- jmEventJobState OBJECT-TYPE
- SYNTAX INTEGER { -- enum in [IPP-MOD]
- unknown(2), -- unknown job state
- pending(3),
- pendingHeld(4),
- processing(5),
- processingStopped(6),
- canceled(7),
- aborted(8),
- completed(9)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job state associated with this event
- or 'unknown'.
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 20]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
- Note: This object uses the keywords from the [IPP-MOD]
- enumerated type 'job-state' for coherence.
-
- Conformance: This job state SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jmJobState' object in [RFC-2707];
- Section 4.3.7 'job-state' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { unknown } -- unknown job state
- ::= { jmEventBinding 13 }
-
- jmEventJobStateReasons OBJECT-TYPE
- SYNTAX OCTET STRING (SIZE (0..255)) -- 255*n in [IPP-MOD]
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job state reasons associated with this event
- (as a comma-separated list) or the empty string (if none).
-
- Conformance: The natural language for keywords
- in job state reasons SHALL always be US English.
-
- Conformance: These job state reasons SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jmJobStateReasons1' object in [RFC-2707];
- 'jobStateReasons2', 'jobStateReasons3', and
- 'jobStateReasons4' attributes in [RFC-2707];
- Section 4.3.8 'job-state-reasons' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { ''H } -- no job state reasons
- ::= { jmEventBinding 14 }
-
- jmEventJobKOctets OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job size in K octets associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job size SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jobKOctetsTransferred' attribute in [RFC-2707];
- Section 4.3.17.1 'job-k-octets' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown job size
- ::= { jmEventBinding 15 }
-
-Hastings, McDonald Expires 19 September 2000 [Page 21]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
- jmEventJobKOctetsProcessed OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job progress in K octets associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job progress SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jmJobKOctetsProcessed' object in [RFC-2707];
- Section 4.3.18.1 'job-k-octets-processed'
- in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown job progress
- ::= { jmEventBinding 16 }
-
- jmEventJobImpressions OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job size in impressions associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job size SHALL be valid
- and reported, if available on this managed system.
-
- See: Section 4.3.17.2 'job-impressions' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown job size
- ::= { jmEventBinding 17 }
-
- jmEventJobImpressionsCompleted OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job progress in impressions associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job progress SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jmJobImpressionsCompleted' object in [RFC-2707];
- Section 4.3.18.2 'job-impressions-completed'
- in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown job progress
-
-Hastings, McDonald Expires 19 September 2000 [Page 22]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- ::= { jmEventBinding 18 }
-
- jmEventJobMediaSheets OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job size in media sheets associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job size SHALL be valid
- and reported, if available on this managed system.
-
- See: 'sheetsRequested' attribute in [RFC-2707];
- Section 4.3.17.3 'job-media-sheets' in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown job size
- ::= { jmEventBinding 19 }
-
- jmEventJobMediaSheetsCompleted OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job progress in media sheets associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job progress SHALL be valid
- and reported, if available on this managed system.
-
- See: 'sheetsCompleted' attribute in [RFC-2707];
- Section 4.3.18.3 'job-media-sheets-completed'
- in [IPP-MOD];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown job progress
- ::= { jmEventBinding 20 }
-
- jmEventJobImpressionsCompletedCC OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job progress in impressions completed
- on the current copy associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job progress SHALL be valid
- and reported, if available on this managed system.
-
- See: 'jmJobImpressionsCompleted' object in [RFC-2707];
- 'impressions-completed-current-copy' in [IPP-PROG];
-
-Hastings, McDonald Expires 19 September 2000 [Page 23]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { unknown } -- unknown job progress
- ::= { jmEventBinding 21 }
-
- jmEventJobCollationType OBJECT-TYPE
- SYNTAX JmJobCollationTypeTC
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job collation type associated with this event
- or 'unknown' (if unknown).
-
- Conformance: This job collation type be valid
- and reported, if available on this managed system.
-
- See: 'jobCollationType' attribute in [RFC-2707];
- 'job-collation-type' in [IPP-PROG];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { unknown } -- unknown job collation type
- ::= { jmEventBinding 22 }
-
- jmEventJobSheetCompletedCopyNum OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job progress number of the copy currently being
- stacked for the document associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job progress SHALL be valid
- and reported, if available on this managed system.
-
- See: 'sheetCompletedCopyNumber' attribute
- in [RFC-2707];
- 'sheet-completed-copy-number' in [IPP-PROG];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown copy number
- ::= { jmEventBinding 23 }
-
- jmEventJobSheetCompletedDocNum OBJECT-TYPE
- SYNTAX Integer32 (-2..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The job progress number of the document currently being
- stacked associated with this event
- or zero (if none) or '-2' (if unknown).
-
- Conformance: This job progress SHALL be valid
- and reported, if available on this managed system.
-
-Hastings, McDonald Expires 19 September 2000 [Page 24]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
- See: 'sheetCompletedDocumentNumber' attribute
- in [RFC-2707];
- 'sheet-completed-document-number' in [IPP-PROG];
- Section 7 'Notification Content' in [IPP-NOT]."
- DEFVAL { -2 } -- unknown document number
- ::= { jmEventBinding 24 }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 25]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-5. IANA Considerations
-
- None.
-
-
-6. Internationalization Considerations
-
- The 'jmEventTriggerEvent', 'jmEventDeviceState', and
- 'jmEventDeviceStateReasons' text objects defined in this document are
- of type 'JmUTF8StringTC' (UTF-8 stream-encoded ISO 10646/Unicode
- text) defined in the Job Monitoring MIB [RFC-2707]. The natural
- language of these objects is US English.
-
- The 'jmEventSubscriberUserName' text object defined in this document
- is of type 'JmUTF8StringTC' (UTF-8 stream-encoded ISO 10646/Unicode
- text) defined in the Job Monitoring MIB [RFC-2707]. The natural
- language of this object is inherently ambiguous (as it usually
- contains some transform of a personal name).
-
-
-7. Security Considerations
-
- This IPP Notifications over SNMP mapping defines only 'read-only'
- objects. It is suitable for use with any version of SNMP, as no
- update security is required (because no configuration updates are
- supported).
-
- No sensitive information is available via IPP Notifications over
- SNMP.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 26]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-8. References
-
- [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell.
- IPP/1.1 Model and Semantics, <draft-ietf-ipp-model-v11-06.txt>
- (work-in-progress), March 2000.
-
- [IPP-NOT] S. Isaacson, J. Martin, R. deBry, T. Hastings, M. Shepherd,
- R. Bergman. IPP Event Notification Specification,
- <draft-ietf-ipp-not-spec-02.txt> (work-in-progress), March 2000.
-
- [IPP-PROG] T. Hastings, R. Bergman, H. Lewis. Proposed Job Progress
- Attributes for IPP, <draft-ietf-ipp-job-prog.txt> (work-in-progress),
- February 2000.
-
- [RFC-1213] K. McCloghrie, M. Rose. MIB-II, RFC 1213, March 1991.
-
- [RFC-1514] P. Grillo, S. Waldbusser. Host Resources MIB, RFC 1514,
- September 1993.
-
- [RFC-1759] R. Smith, F. Wright, T. Hastings, S. Zilles,
- J. Gyllenskog. Printer MIB, RFC 1759, March 1995.
-
- [RFC-2573] D. Levi, P. Meyer, B. Stewart. SNMP Applications, RFC
- 2573, April 1999.
-
- [RFC-2576] R. Frye, D. Levi, S. Routhier, B. Wijnen. Coexistence
- between Version 1, Version 2, and Version 3 of the Internet-standard
- Network Management Framework, RFC 2576, March 2000.
-
- [RFC-2707] R. Bergman, T. Hastings, S. Isaacson, H. Lewis. Job
- Monitoring MIB v1.0, RFC 2707, November 1999
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 27]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-9. Change Log
-
- Changes in reverse chronological order (most recent first).
-
- <draft-ietf-ipp-not-over-snmp-02.txt> - 19 March 2000
- 1) Renamed Printer Event notification group to Device Basic Event
- and 'jmPrinterEventV2Event' notification to
- 'jmDeviceBasicV2Event', to better align with IPP and to support
- non-printing jobs.
- 2) Revised 'jmDeviceBasicV2Event' notification to remove
- 'hrDeviceStatus', 'hrPrinterStatus',
- 'hrPrinterDetectedErrorState' from mandatory trap bindings
- because they were redundant, per request of Ron Bergman.
- 3) Renamed Job Event notification group to Job Basic Event and
- 'jmJobEventV2Event' notification to 'jmJobBasicV2Event', to
- better align with IPP and to support variant job events.
- 4) Defined new Job Completed Event notification group and defined
- new Job Progress Event notification group, to better align with
- IPP and to support variant job events.
- 5) Renamed Event object group to Event Binding,
- 'jmEventPrinterState' to 'jmEventDeviceState',
- 'jmEventPrinterStateReasons' to 'jmEventDeviceStateReasons',
- 'jmEventPrinterIsAcceptingJobs' to
- 'jmEventDeviceIsAcceptingJobs', to support non-printing jobs.
- 6) Revised Event Binding object group, adding explicit objects
- 'jmEventDeviceURI', 'jmEventDeviceName', 'jmEventJobSetIndex',
- 'jmEventJobIndex', 'jmEventJobName', 'jmEventJobState',
- 'jmEventJobStateReasons', 'jmEventJobKOctets',
- 'jmEventJobKOctetsProcessed', 'jmEventJobImpressions',
- 'jmEventJobImpressionsCompleted', 'jmEventJobMediaSheets',
- 'jmEventJobMediaSheetsCompleted',
- 'jmEventJobImpressionsCompletedCC', 'jmEventJobCollationType',
- 'jmEventJobSheetCompletedCopyNum',
- 'jmEventJobSheetCompletedDocNum', per request of Ron Bergman.
- 7) Revised SYNTAX of 'jmEventTriggerEvent' object from from
- 'JmUTF8StringTC' (string) to IPP-aligned enumeration, per request
- of Ron Bergman.
- 8) Removed all references to Printer MIB v2, as they were of limited
- value, per request of Ron Bergman.
- 9) Revised 'SNMP Mapping for IPP Printer Events' section for renamed
- event binding objects, per request of Ron Bergman.
- 10) Revised 'Rules for Encoding Notifications' section to truncate
- additional string bindings, per request of Ron Bergman.
- 11) Revised 'Registration via IPP' section, to change scheme name
- from 'ipp-snmp:' to 'snmpnotify:', per request of Ron Bergman.
-
- <draft-ietf-ipp-not-over-snmp-01.txt> - 1 December 1999
- 1) Deleted 'JmTriggerEventTC' textual convention (see below).
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 28]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
- 2) Revised SYNTAX of 'jmEventTriggerEvent' object from
- 'JmTriggerEventTC' (enumeration) to 'JmUTF8StringTC' (string), to
- support use of IPP standard keywords.
- 3) Added 'jmEventPrinterState', 'jmEventPrinterStateReasons', and
- 'jmEventPrinterIsAcceptingJobs' objects for consistency w/
- [IPP-NOT] and to reduce ambiguity about printer states inherent
- in RFC 1759.
- 4) Revised DESCRIPTION of 'jmPrinterEventV2Event' notification to
- add SHOULD (recommendation) for 'jmEventPrinterState',
- 'jmEventPrinterStateReasons', and 'jmEventPrinterIsAcceptingJobs'
- objects.
- 5) Revised 'SNMP Mapping for IPP Printer Events' section to add
- direct mapping of IPP notification attributes to
- 'jmEventPrinterState', 'jmEventPrinterStateReasons', and
- 'jmEventPrinterIsAcceptingJobs' objects.
- 6) Revised 'Rules for Encoding Notifications' section to add
- 'jmEventPrinterState' and 'jmEventPrinterStateReasons'.
- 7) Revised 'IANA Considerations' section to specify there are none -
- no enumerated or keyword textual conventions are now defined in
- this document.
- 8) Revised 'Internationalization Considerations' section to specify
- that US English keywords are used in 'jmEventTriggerEvent',
- 'jmEventPrinterState', and 'jmEventPrinterStateReasons' objects
- and thus no explicit natural language tagging is required.
-
- <draft-ietf-ipp-not-over-snmp-00.txt> - 10 October 1999
- 1) Initial version.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 29]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-10. Intellectual Property Notice
-
- 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. 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.
-
-
-11. Authors' Addresses
-
- Tom Hastings
- Xerox Corporation
- 701 S Aviation Blvd, MS 834-03E
- El Segundo, CA 90245
-
- Phone: +1 310-333-6413
- Email: hastings@cp10.es.xerox.com
-
-
- Ira McDonald
- High North Inc
- 221 Ridge Ave
- Grand Marais, MI 49839
-
- Phone: +1 906-494-2434 or +1 906-494-2697
- Email: imcdonald@sharplabs.com
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 30]
-
-
-Internet Draft IPP Notify over SNMP via Job Mon MIB 19 March 2000
-
-
-
-12. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hastings, McDonald Expires 19 September 2000 [Page 31]
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML><HEAD>
+<TITLE>404 Not Found</TITLE>
+</HEAD><BODY>
+<H1>Not Found</H1>
+The requested URL /internet-drafts/draft-ietf-ipp-not-over-snmp-04.txt was not found on this server.<P>
+<HR>
+<ADDRESS>Apache/1.3.11 Server at www2.ietf.org Port 80</ADDRESS>
+</BODY></HTML>
+++ /dev/null
-
-INTERNET-DRAFT
-<draft-ietf-ipp-not-spec-02.txt> S. Isaacson
- Novell, Inc.
- J. Martin
- Underscore
- R. deBry
- Utah Valley State College
- T. Hastings
- Xerox Corporation
- M. Shepherd
- Xerox Corporation
- R. Bergman
- Hitachi Koki Imaging Solutions
- March 8, 2000
- Internet Printing Protocol (IPP):
- IPP Event Notification Specification
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-Abstract
-
-This document describes an extension to the IPP/1.0, IPP/1.1, and future
-versions that allows a client to subscribe to printing related events.
-Subscriptions include "Per-Job subscriptions" and "Per-Printer
-subscriptions". One or more Per-Job Submission subscriptions are
-specified by the client when submitting a job. Additional Per-Job and
-Per-Printer subscriptions are created by performing separate explicit
-Create-Job-Subscription Create-Printer-Subscription operations,
-respectively. Subscriptions are modeled as Subscription objects. Four
-other operations are defined for Subscription objects: Get-Attributes,
-Get-Subscriptions, Renew-Subscription, and Cancel-Subscription.
-
-A subscription request and the Subscription object includes: the names
-of Job and/or Printer events, the Notification Recipient URL, the
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 1]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-Notification Content format, if several are supported, possibly some
-opaque data, and the charset and natural language. In addition, the
-subscription request includes: the requested lease time and persistency
-for the subscription. When the event occurs, a notification is
-generated and delivered using the information specified in the
-subscription.
-
- 1 ISSUE is included in the text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 2]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-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.1: Model and Semantics [IPP-MOD]
- Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-The "Design Goals for an Internet Printing Protocol" document 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. It 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. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document 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 "Internet Printing Protocol/1.1: Model and Semantics", describes a
-simplified model with abstract objects, their attributes, and their
-operations that are independent of encoding and transport. It introduces
-a Printer and a Job object. The Job object optionally supports multiple
-documents per Job. It also addresses security, internationalization, and
-directory issues.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1. It defines the encoding rules for a
-new Internet MIME media type called "application/ipp". This document
-also defines the rules for transporting over HTTP a message body whose
-Content-Type is "application/ipp". This document defines a new scheme
-named 'ipp' for identifying IPP printers and jobs. Finally, this
-document defines interoperability rules for supporting IPP/1.0 clients.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 3]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-
- Table of Contents
-
-
-1 Introduction.......................................................7
- 1.1 Notification Overview.........................................8
-
-2 Model for Per-Job and Per-Printer Subscription and Event Notification
- 11
- 2.1 Model for Per-Job Subscription and Notification..............11
- 2.2 Model for Per-Printer Subscription and Notification..........13
- 2.3 Relationship between the Printer object and the Notification
- Delivery Service..................................................13
- 2.3.1 Use of a Notification Service transparently to clients...13
- 2.3.2 Use of Notification Service transparently to the IPP Printer
- 14
-
-3 Terminology.......................................................15
- 3.1 Conformance Terminology......................................15
- 3.2 Other terminology............................................16
-
-4 Object Model for Notification.....................................19
- 4.1 Object relationships.........................................20
- 4.1.1 Printer object and Per-Printer Subscription objects......20
- 4.1.2 Job object and Per-Job Subscription objects..............21
-
-5 Subscription Object attributes....................................21
- 5.1 notify-recipient (uri).......................................23
- 5.2 notify-events (1setOf type2 keyword).........................25
- 5.3 notify-format (mimeMediaType)................................28
- 5.4 subscriber-user-data (octetString(63)).......................29
- 5.5 notify-charset (charset).....................................30
- 5.6 notify-natural-language (naturalLanguage)....................30
- 5.7 subscription-request-id......................................30
- 5.8 subscription-id (integer (1:MAX))............................30
- 5.9 notify-lease-expiration-time (integer(0:MAX))................31
- 5.10 printer-uri (uri)............................................31
- 5.11 subscriber-user-name (name(MAX)).............................31
- 5.12 notify-server-up-time (integer(1:MAX)).......................32
- 5.13 notify-persistence-granted (boolean).........................32
-
-6 Printer Description Attributes related to Notification............32
- 6.1 notify-schemes-supported (1setOf uriScheme)..................33
- 6.2 notify-events-default (1setOf type2 keyword).................33
- 6.3 notify-events-supported (1setOf type2 keyword)...............33
- 6.4 max-events-supported (integer(5:MAX))........................34
- 6.5 notify-format-supported (1setOf mimeMediaType)...............34
- 6.6 max-job-subscriptions-supported (integer(0:MAX)).............34
- 6.7 max-printer-subscriptions-supported (integer(0:MAX)).........35
- 6.8 notify-lease-time-supported (rangeOfInteger(0:MAX))..........35
- 6.9 notify-lease-time-default (integer(0:MAX))...................35
- 6.10 persistent-jobs-supported (boolean)..........................35
- 6.11 persistent-subscriptions-supported (boolean).................36
- 6.12 printer-state-change-time (integer(1:MAX))...................36
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 4]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- 6.13 printer-state-change-date-time (dateTime)....................36
-
-7 Notification Content..............................................36
- 7.1 Notification content MIME media type formats.................37
- 7.1.1 Human Consumable form....................................37
- 7.1.2 Machine Consumable form..................................37
- 7.2 Notification content attributes common to Job and Printer events
- 38
- 7.2.1 "trigger-event" (type2 keyword)..........................41
- 7.2.2 "trigger-time" (integer(MIN:MAX))........................41
- 7.2.3 "trigger-date-time" (dateTime)...........................41
- 7.2.4 "human-readable-report" (text(MAX))......................41
- 7.3 Additional Notification content attributes for Job events only41
- 7.4 Additional Notification content attributes for Printer events
- only 42
-
-8 Operations for notification.......................................43
- 8.1 Operations for Per-Job Subscriptions only....................43
- 8.1.1 Job Creation Operations (Create-Job, Print-Job, Print-URI)
- and Validate-Job................................................43
- 8.1.2 Create-Job-Subscription operation........................47
- 8.2 Operations for Per-Printer Subscriptions only................49
- 8.2.1 Create-Printer-Subscription operation....................49
- 8.3 Common Operations for Per-Job and Per-Printer Subscriptions..53
- 8.3.1 Get-Subscription-Attributes operation....................53
- 8.3.2 Get-Subscriptions operation..............................54
- 8.3.3 Renew-Subscription operation.............................56
- 8.3.4 Cancel-Subscription operation............................57
-
-9 Comparison of Per-Job versus Per-Printer Subscriptions............58
-
-10Out of Band Values................................................59
- 10.1 'none'.......................................................59
-
-11Conformance Requirements..........................................59
-
-12IANA Considerations...............................................60
-
-13Internationalization Considerations...............................60
-
-14Security Considerations...........................................60
-
-15Status Codes......................................................61
- 15.1 'successful-ok-ignored-subscriptions' (0x0003)...............61
- 15.2 client-error-uri-notification-scheme-not-supported (0x0414)..62
- 15.3 client-error-too-many-subscriptions (0x0415).................62
- 15.4 client-error-too-many-events (0x0416)........................62
-
-16Addition attribute tag encodings..................................62
-
-17References........................................................63
-
-18Author's Addresses................................................65
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 5]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-A.Appendix: Change History.........................................66
- 18.1 Changes to the March 6, 2000 version to create the March 8, 2000
- version66
- 18.2 Changes to the February 2, 2000 version to create the March 6,
- 2000 version......................................................66
- 18.3 Changes to the October 14, 1999 version to create the February
- 2, 2000 version...................................................68
-
-B.Appendix: Full Copyright Statement................................70
-
-
- Tables
-Table 1 - Summary of Per-Job and Per-Printer Subscription operations.10
-Table 2 - Subscription object attributes.............................22
-Table 3 - Printer Description attributes associated with Notification33
-Table 4 - Common Job and Printer Notification content attributes.....39
-Table 5 - Additional Notification content attributes for Job events only
- .................................................................41
-Table 6 - Additional Notification content attributes for Printer events
- only.............................................................42
-Table 7 - Member attributes of the "job-notify" collection operation
- attribute........................................................44
-Table 8 - "job-notify" supported and default attributes..............44
-Table 9 - Conformance Requirements for Operations....................60
-
- Figures
-Figure 1 - Client-Printer Per-Job Subscription and Notification Model11
-Figure 2 - Client-Server-Printer Per-Job Subscription and Notification
- Model............................................................12
-Figure 3 - Client-Printer Per-Printer Subscription and Notification
- Model............................................................13
-Figure 4 - Opaque Use of a Notification Service Transparent to the
- Client...........................................................14
-Figure 5 - Use of a Notification Service transparent to the IPP Printer
- .................................................................15
-Figure 6 - Object Model for Notification.............................20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 6]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-
-
-1 Introduction
-
-
-This IPP notification specification is an extension to IPP/1.0 [RFC2568,
-RFC2569] and IPP/1.1 [ipp-mod, ipp-pro]. This document in combination
-with the following documents is intended to meet the notification
-requirements described in [ipp-not-req]:
-
- Internet Printing Protocol/1.0 & 1.1: "Collection Attribute
- Syntax" [ipp-coll]
- Internet Printing Protocol/1.0 & 1.1: "Job Progress Attributes"
- [ipp-prog]
- Internet Printing Protocol/1.0 & 1.1: "Notification Change
- History" [ipp-not-hist]
-
-In addition, each notification delivery method, whether REQUIRED or
-OPTIONAL, is described in separate documents:
-
- Internet Printing Protocol/1.0 & 1.1: "Notification Delivery
- Method xxx [TBD]
- Internet Printing Protocol/1.0 & 1.1: "Notification Delivery
- Method yyy [TBD]
-
-
-The rest of this document is laid out as follows:
-
- - The rest of Section 1.1 is an overview of IPP Notification.
-
- - Section 2 is the model for network entities that use IPP
- notification, including clients (desktop and servers), IPP Printers
- (servers and devices), and Notification Recipients.
-
- - Section 3 is the terminology used throughout the document.
-
- - Section 4 is the object model for notification, including Job,
- Printer, and Subscription objects.
-
- - Section 5 defines the Subscription object and its attributes.
-
- - Section 6 defines the Printer Description attributes
-
- - Section 7 defines the Notification content of Human Consumable
- and Machine Consumable Event formats.
-
- - Sections 8 and 9 define the Per-Job and Per-Printer Subscription
- operations.
-
- - Section 10 defines the out-of-band values.
-
- - Section 11 and 12 define the conformance requirements and IANA
- requirements, respectively.
-
- - Section 13 - 15 cover Internationalization, Security, and Status
- codes.
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 7]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- - Appendix A is a summary of the Notification Attribute usage
-
- - Appendix B is a Change History
-
-
-1.1 Notification Overview
-
-A client can establish an event notification subscription so that when
-one of the specified events occurs, an asynchronous Notification is sent
-to a specified Notification Recipient.
-
-One or more Per-Job Submission subscriptions are specified by the client
-when submitting a job. One or more Per-Job or Per-Printer subscriptions
-are created by performing separate explicit Create-Job-Subscription or
-Create-Printer-Subscriptions operations, respectively.
-
-A Per-Job or Per-Printer subscription request includes:
-
- 1. the names of Job and/or Printer events that are of interest to the
- Notification Recipient
-
- 2. the delivery method and address to use to deliver the notification
- to one Notification Recipient
-
- 3. if Human Consumable notification content is to be sent, which text
- format
-
- 4. some opaque data that the subscriber wants to be sent to the
- Notification Recipient in the Notification, perhaps to identify
- either the subscriber or the ultimate recipient
-
- 5. the charset to use in the Notification, if it is to be different
- than the one used in the request that created the subscription
-
- 6. the natural language to use in the Human Consumable Notification,
- if it is to be different than the one used in the request that
- created the subscription
-
- 7. the requested lease time in seconds for the subscription
-
- 8. whether or not the subscription is requested to be persistent
- across power cycles.
-
-For Per-Job subscriptions, a client requests job and printer event
-notification using the "job-notify" operation attribute when creating a
-job with any of the Job Creation operation: Print-Job, Print-URI, and
-Create-Job. The "job-notify" operation attributes may be submitted to
-the Validate-Job in order to be validated. The "job-notify" operation
-attribute contains one or more collection values, each consisting of a
-number of member attributes that specify a subscription, so that a Job
-can have more than one Per-Job subscription. The 'collection' is a new
-attribute syntax (see [ipp-coll]). The member attributes of each
-collection value are copied to separate Subscription objects to populate
-the corresponding Subscription Description attributes.
-
-For Per-Printer subscriptions and Per-Job subscriptions created after
-the Job has been created, a client requests job and printer event
-notification using new operations independent of any job. The Printer
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 8]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-keeps each subscription in a separate Subscription object. The Create-
-Job-Subscription and Create-Printer-Subscription operations create an
-instance of the Subscription object supplying these new operation
-attributes and returns a subscription-id (analogous to a job-id for a
-Job object). These operation attributes are copied to the Subscription
-object as Subscription Description attributes and so may be queried
-using the Get-Subscription-Attributes and Get-Subscriptions operations.
-The subscriber requests a lease time for each Per-Printer subscription
-which MAY be infinite. The Printer grants a lease time according to its
-configured policy. A client MUST renew the Subscription before the
-granted lease time expires using the Renew-Subscription operation.
-
-Table 1 summarizes the Per-Job and Per-Printer Subscription operations,
-assigns their operation-id (see [ipp-mod] section 4.4.15) and their
-salient input operation attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 9]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Table 1 - Summary of Per-Job and Per-Printer Subscription operations
-
-Operation: Oper. Per- Per- Brief Description
- ID Job Prin salient inputs beside printer-
- ter uri:
-
-Print-Job, Print- see yes no Create one or more Per-Job
-URI, Create-Job [ipp- Subscriptions as part of the Job
- mod] Creation operations
- 1setOf {recipient, [events,]
- [format,] [user-data,]
- [charset,] [natural-language]}
-
-Validate-Job see yes no Check that the Job Creation
- [ipp- operation would be accepted
- mod] including the Subscription
- 1setOf {recipient, [events,]
- [format,] [user-data,]
- [charset,] [natural-language]}
-
-Create-Printer- 0x0016 no yes Create a Per-Printer
-Subscription Subscription
- recipient, [events,] [format,]
- [user-data,] [charset,]
- [natural-language,] [lease-time-
- requested,] [persistence-
- requested]
-
-Create-Job- 0x0017 yes no Create a Per-Job Subscription
-Subscription recipient, job-id, [events,]
- [format,] [user-data,]
- [charset,] [natural-language,]
-
-Get-Subscription- 0x0018 yes yes Get specified Subscription
-Attributes attributes of the specified
- Subscription object
- subscription-id, [requested-
- attributes]
-
-Get-Subscriptions 0x0019 yes yes Get the specified Subscription
- attributes from all my or all of
- the Subscription objects
- [job-id], [my-subscriptions,]
- [requested-attributes]
-
-Renew-Subscription 0x001A yes yes Renew the Subscription lease
- subscription-id, [lease time-
- requested]
-
-Cancel- 0x001B yes yes Cancel the Subscription
-Subscription subscription-id
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 10]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-There are two steps that IPP notification must take regarding each event
-- an internal event recording, and an external notification:
-
- 1) As an events occurs, the printer internally records in the job
- objects and the printer objects those events which are required to
- be supported by the system and those that are subscribed to by a
- notification recipient.
-
- 2) As an events occurs, the Printer searches the set of
- subscriptions for any interest in that event. As the Printer finds
- that some notification recipient is interested in that event (the
- notification recipient is subscribed to the event), the Printer
- increments the Subscription object's "subscription-request-id"
- (integer (0:MAX)) attribute and a notification is generated and
- delivered using the methods and target addresses identified in the
- subscription, passing the incremented "request-id". The
- "subscription-request-id" sequence number permits a Notification
- Recipient to detect duplicate notifications due either to duplicate
- subscriptions or retries and to detect dropped notifications.
-
-
-2 Model for Per-Job and Per-Printer Subscription and Event Notification
-
-
-2.1 Model for Per-Job Subscription and Notification
-
-Per-Job subscriptions are created by a client (desktop or server acting
-as a client) as part of creation of the job in an IPP Printer (printing
-device or server). More than one subscription may be submitted with a
-job. Additional subscriptions may be associated with the job using the
-Create-Job-Subscription operation. The IPP Printer object delivers a
-Notifications to the Notification Recipient supplied by the Client in
-each subscription. A Notification Recipient can be the Job submitter or
-a third party.
-
-Figure 1 shows the Per-Job subscription notification model for a simple
-Client - Printer relationship.
-
-
-embedded printer:
- output device or server
- desktop or server +---------------+
- +--------+ | ########### |
- | client |---IPP job submission------># Printer # |
- +--------+ Per-Job subscription | # Object # |
- +------------+ | #####|##### |
- |Notification| +-------|-------+
- |Recipient |<-----IPP Notifications---------+
- +------------+ (Job and/or Printer events)
-
- Figure 1 - Client-Printer Per-Job Subscription and Notification Model
-
-Figure 2 shows a (spooling or non-spooling) Server that implements two
-Printer objects (1 and 2) that represent two devices. The devices A and
-B in turn each implement an IPP Printer object (3 and 4, respectively).
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 11]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-The Server implementation has three choices for how to support Per-Job
-subscriptions to the client (and itself):
-
- 1.forward the Per-Job subscriptions to the down stream IPP Printer
- and let it perform the notification directly to the Notification
- Recipients supplied by the Client (Notifications(C)) and use
- Per-Printer Subscriptions for the Server's own purposes.
-
- 2.save the client-supplied Per-Job subscription on the Job object
- in the server and substitute its own Per-Job subscription with
- the Server as the Notification Recipient (Notifications(B)).
- Then the Server relays Notifications to the client-supplied
- Notification Recipients (Notifications(A)).
-
- 3.A combination of 1 and 2 in which the Server adds its own Per-
- Job subscriptions to those supplied by the client. Thus the IPP
- Job that goes to Printer object 4 has a combination of
- subscription information from both the Client and the Server.
- This latter approach is sometimes called "piggy-backing" because
- the Server is adding its Per-Job subscription information to
- that supplied by the client. Piggy-backing is especially
- useful, if device B also accepts (IPP or non-IPP) requests from
- other servers. Then when all the jobs from Server S have been
- completed by device B, there will be no more Job events sent to
- Server S. (Server S could still maintain a long term Per-
- Printer subscription with Printer D to that Server S can have
- Printer B's state track (shadow) that of Printer D or Server S
- could poll Printer D when queried about Printer B).
-
-
- device A
- server S +------------+
- +------------+ | ###########|
-+--------+ IPP Job | ###########| IPP Job | # Printer #|
-| client |--submission---># Printer #|---submission-----># Object 3#|
-+--------+ Per-Job | # Object 1#| Per-Job | ###########|
- subscription | ###########| subscription +------------+
- | | device B
-+--------+ IPP Job | ###########| +------------+
-| client |--submission---># Printer #| IPP Job | ###########|
-+--------+ Per-Job | # Object 2#|---submission-----># Printer #|
- subscription | ###|#######| Per-Job | # Object 4#|
- +----|---^---+ subscription | ####|#|####|
-+--------+ | | +-----|-|----+
-|Notific-|<-Notifications(A)-+ +--- Notifications(B)-------+ |
-|ation Re|<----------------Notifications(C)--------------------+
-|cipient |
-+--------+
-
- Figure 2 - Client-Server-Printer Per-Job Subscription and Notification
- Model
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 12]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-2.2 Model for Per-Printer Subscription and Notification
-
-Per-Printer subscriptions are created by a client (an end user, an
-operator, or a server acting as a client) using a Create-Printer-
-Subscription operation that is independent of Job Submission. The
-Printer object (printing device or server) creates a Subscription object
-to hold the attributes supplied by the subscriber. The client creates
-separate Per-Printer subscriptions if more than one Notification
-Recipient is desired. The Printer delivers Notifications to the
-Notification Recipient specified by each Per-Printer subscription. A
-Notification Recipient may be the subscriber or a third party. Figure 3
-shows the Per-Printer subscription notification model for the Client -
-Printer relationship where the client may be an end user, an operator,
-or a server acting as a client.
-
-
- desktop or server server or printing device
- +---------------+
- +--------+ | ########### |
- | client |---Create-Printer-Subscription------># Printer # |
- +--------+ (Per-Printer subscription) | # Object # |
- | #####|##### |
- +------------+ +-------|-------+
- |Notification|<----------IPP Notifications-------------+
- |Recipient | (Job and/or Printer events)
- +------------+
-
- Figure 3 - Client-Printer Per-Printer Subscription and Notification
- Model
-
-
-2.3 Relationship between the Printer object and the Notification
- Delivery Service
-
-The IPP Notification model does not mandate that the IPP Printer object
-implement the full semantics of subscription, report generation, and
-multiple delivery methods itself. This section describes two methods of
-using third party notification services. The first is transparent to
-the client and the second is transparent to the IPP Printer.
-
-2.3.1 Use of a Notification Service transparently to clients
-
-An implementation may be configured to use some other notification
-service to either (1) delivery the Notifications to the Notification
-Recipient(s) specified in the IPP Subscription or (2) keep the
-Subscriptions, accept events, possibly format the notification in the
-natural language of the Notification Recipient when a Human Consumable
-text format is used, and deliver the Notifications to the Notification
-Recipient(s) indicated in the IPP Subscription. Figure 4 shows this
-partitioning.
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 13]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-
- output device or server
- desktop or server +---------------+
- +--------+ | ########### |
- | client |---IPP subscription--------># Printer # |
- +--------+ | # Object # |
- | #####|##### |
- +-------|-------+
- | Subscriptions
- *******| OR Events
- +------------+ * |
- |Notification| * +------v--------+
- |Recipient |<--IPP Notifications-----| Notification |
- +------------+ * | Service |
- * +---------------+
- *
- *
- *** = Implementation configuration opaque boundary
-
-
- Figure 4 - Opaque Use of a Notification Service Transparent to the
- Client
-
-In any case, the interface between the IPP Printer and the other
-notification service is outside the scope of this document and is
-intended to be transparent to the client and this specification.
-
-2.3.2 Use of Notification Service transparently to the IPP Printer
-
-Another way that a Notification Service can be used is if the
-Notification Recipient indicated in the IPP Subscription is a
-notification service (transparent to the IPP Printer), which in turn
-forwards the Notification to the Ultimate Notification Recipient using
-additional parameters in the IPP Subscription (URI parameters or
-subscriber user data). In such cases, the Ultimate Notification
-Recipient has also subscribed directly with the other notification
-service (by means outside this document). As far as the IPP Printer is
-concerned, the IPP Subscription indicated that the IPP Printer is to
-delivery Notifications to the Notification Recipient (Notification
-Service) using the specified notification delivery method. The method
-that the Notification Recipient uses for delivering the notification to
-the Ultimate Notification Recipient is beyond the scope of this document
-and is transparent to the IPP Printer. However, the client does have to
-know how to pass additional information to the Notification Recipient in
-the IPP Subscription using either extra parameters in the URI or
-subscriber user data. Examples of this latter approach are paging,
-immediate messaging services, and NOS vendors infrastructure. Figure 5
-shows this approach.
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 14]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-
- desktop or server server or printing device
- +---------------+
- +--------+ | ########### |
- | client |----------IPP Subscriptions---------># Printer # |
- +--------+ | # Object # |
- | #####|##### |
-+------------+ +------------+ +-------|-------+
-|Ultimate | |Notification|<---IPP Notifications-----+
-|Notification|<----|Recipient |
-|Recipient | +------------+
-+------------+ (Notification Service)
-
-Figure 5 - Use of a Notification Service transparent to the IPP Printer
-
-
-3 Terminology
-
-
-This section defines terminology used throughout this document.
-
-
-3.1 Conformance Terminology
-
- Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
- NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
- conformance to this specification. These terms are defined in
- [ipp-mod section 13.1 on conformance terminology, most of which is
- taken from RFC 2119 [RFC2119].
-
- REQUIRED - an adjective used to indicate that a conforming IPP
- Printer implementation MUST support the indicated operation,
- object, attribute, attribute value, status code, or out-of-band
- value in requests and responses. See [ipp-mod] "Appendix A -
- Terminology for a definition of "support". Since support of this
- entire notification specification is OPTIONAL for conformance to
- IPP/1.0 or IPP/1.1, the use of the term REQUIRED in this document
- means "REQUIRED if this OPTIONAL notification specification is
- implemented".
-
- RECOMMENDED - an adjective used to indicate that a conforming IPP
- Printer implementation is recommended to support the indicated
- operation, object, attribute, attribute value, status code, or out-
- of-band value in requests and responses. Since support of this
- entire notification specification is OPTIONAL for conformance to
- IPP/1.0 or IPP/1.1, the use of the term REQUIRED in this document
- means "RECOMMENDED if this OPTIONAL notification specification is
- implemented".
-
- OPTIONAL - an adjective used to indicate that a conforming IPP
- Printer implementation MAY, but is NOT REQUIRED to, support the
- indicated operation, object, attribute, attribute value, status
- code, or out-of-band value in requests and responses.
-
- settable - an adjective used to indicate that a Printer
- implementation supports setting the value(s) of an attribute using
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 15]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- the Set-Job-Attributes or Set-Printer-Attributes operations (see
- [ipp-set]).
-
- READ-ONLY - an adjective used in an attribute definition to indicate
- that an IPP Printer MUST NOT support the attribute as being
- settable using the Set-Job-Attributes or Set-Printer-Attributes
- operations (see [ipp-set]).
-
-
-3.2 Other terminology
-
- Job Submitting End User - A human end user who submits a print job
- to an IPP Printer. This person may or may not be within the same
- security domain as the Printer. This person may or may not be
- geographically near the printer.
-
- Administrator - A human user who established policy for and
- configures the print system.
-
- Operator - A human user who carries out the policy established by the
- Administrator and controls the day to day running of the print
- system.
-
- Job Submitting Application - An application (for example, a batch
- application), acting on behalf of a Job Submitting End User, which
- submits a print job to an IPP Printer. The application may or may
- not be within the same security domain as the Printer. This
- application may or may not be geographically near the printer.
-
- Security Domain - The set of network components which can communicate
- without going through a proxy or firewall. A security domain may be
- geographically very large, for example - anyplace within IBM.COM.
-
- IPP Client (or client) - The software component (desktop or server)
- that sends an IPP operation request to an IPP Printer object
- (server or printing device) and accepts the resulting operation
- response from the IPP Printer object.
-
- Job Recipient - A human who is the ultimate consumer of the print
- job. In many cases this will be the same person as the Job
- Submitting End User, but need not be.
- Example: If I use IPP to print a document on a printer in a
- business partner's office, I am the Job Submitting End User, while
- the person I intend the document for in my business partner's
- office is the Job Recipient. Since one of the goals of IPP is to
- be able to print near the Job Recipient of the printed output, we
- would normally expect that person to be in the same security domain
- as, and geographically near, the Printer. However, this may not
- always be the case. For example, I submit a print job across the
- Internet to a Kinko's print shop. I am both the Submitting End User
- and the Job Recipient, but I am neither near nor in the same
- security domain as the Printer.
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 16]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Job Recipient Proxy - A human acting on behalf of the Job Recipient.
- In particular, the Job Recipient Proxy physically picks up the
- printed document from the Printer, if the Job Recipient cannot
- perform that function. The Proxy is by definition geographically
- near and in the same security domain as the printer.
- Example: I submit a print job from home to be printed on a printer
- at work. I'd like my secretary to pick up the print job and put it
- on my desk. In this case, I am acting as both Job Submitting End
- User and Job Recipient. My secretary is acting as a Job Recipient
- Proxy
-
- Notification Subscriber (or Subscriber) - A client that requests the
- IPP Printer to send Event Notifications to one or more Notification
- Recipients. A Notification Subscriber may be:
-
- 1.a Job Submitting End User or Job Submitting Application (desktop
- or server) that is submitting a job or
-
- 2.an End User, an Operator, or an Administrator that is not
- submitting a job.
-
- Subscription - A request by a Notification Subscriber to the IPP
- Printer to send Event Notifications to a specified Notification
- Recipient when the event occur. A Subscription is represented as a
- set of attributes that indicate the "what, where, who, and how" for
- notification. Notifications are generated for certain events
- (what) and delivered using various delivery methods (how) to
- certain addresses (where and who).
-
- Per-Job Subscription - A Subscription that a client specifies as part
- of a create job operation (Print-Job, Print-URI, Create-Job), a
- Validate-Job operation, or an explicit Create-Job-Subscription
- operation with a Job object as the target.
-
- Per-Printer Subscription - A Subscription that a client specifies
- using an explicit Create-Printer-Subscription operation with a
- Printer object as the target.
-
- Notification Source - The entity that sends Event Notifications. It
- MAY be the IPP Printer itself or the IPP Printer MAY be configured
- to use a Notification Service to delivery Notifications
- transparently to the subscribing clients (see Figure 4).
-
- Notification Recipient - The entity identified as a recipient within
- a subscription that receives IPP Notifications about Job and/or
- Printer events (see Figure 4 and Figure 5). A Notification
- Recipient may be a: Job Submitting End User, Job Submitting
- Application (desktop or server), Job Recipient, Job Recipient
- Proxy, a Notification Service, an Operator, or Administrator, etc.,
- and their representative or log file or usage statistics gathering
- application or other active or passive entities. A Java Listener
- is an example of a Notification Recipient.
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 17]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Ultimate Notification Recipient - The entity to which the
- Notification Recipient (stores and) forwards an IPP Notification
- when the Notification Recipient is a Notification Service (see
- Figure 5).
-
- Event - An event is some occurrence (either expected or unexpected)
- within the printing system of a change of state, condition, or
- configuration of a Job or Printer object. A property of an event
- is that it only occurs at one instant in time and does not span the
- time the physical event takes place. For instance, jam-occurred
- and jam-cleared are two distinct events. The jam-occurred event is
- reported only when the jam initially occurs and only if there is
- one or more event subscriptions outstanding for that event.
-
- Events can be classified along two dimensions:
-
- - Either as Job Events or Printer Events, and
- - Either as Errors, Warnings, or Reports
-
- A Job event is some interesting state change in the Job object, and
- a Printer event is some interesting change in the Printer object.
-
- A report event is purely informational, such as 'job-completed' or
- 'accepting-jobs'. A warning is not serious and processing
- continues. An error is serious and either the job is aborted or
- the printer stops. These are typical uses of the terms report,
- warning, and error, although the actual usage is implementation
- dependent.
-
- An event occurs for a job or printer whether any entity has
- subscribed to be notified for that event or not. A notification is
- only generated depending on the set of subscriptions outstanding.
-
- Notification - When an event occurs, a Notification is generated
- that fully describes the event (what the event was, where it
- occurred, when it occurred, etc.). Notifications are delivered to
- each Notification Recipient that has a subscription that includes
- the event, if any. The Notification is delivered to the address of
- the Notification Recipient using the notification delivery method
- defined in the subscription. However, a Notification is sent ONLY
- if there is a corresponding subscription.
-
- Notification Delivery Method (or Delivery Method for short) -
- Notifications are delivered using a method, such as email, TCP/IP,
- etc.
-
- Immediate Notification - Notifications that are delivered using a
- delivery method which is not store-and-forward (e.g. TCP
- connection, UDP datagram). This can be on the order of several
- minutes subject to network latency.
-
- Store and Forward Notification - A Notification which are not
- necessarily delivered to Notification Recipients immediately, but
- is queued for delivery by some intermediate network application,
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 18]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- for later retrieval. Email and Instant Messaging services are
- examples of a store and forward notification delivery method.
-
- Human Consumable Notification - Notifications that are intended to be
- consumed by human End Users only. They are simple text that has
- been localized for the Notification Recipient as specified in the
- subscription. Programs are not intended to parse Human Consumable
- Notification, since it is localized and the content depends on
- implementation. There is no standardized format.
-
- Machine Consumable Notification - Notifications that are intended for
- consumption by a program only. They use the encoding of an IPP
- response. The Notification Recipient must localize the contents,
- if displaying it to a human.
-
- Subscription Creation operation - One of the operations that creates
- a Subscription object: Job Creation operations (Create-Job, Print-
- Job, and Print-URI), Create-Job-Subscription, and Create-Printer-
- Subscription.
-
-
-4 Object Model for Notification
-
-
-This section describes the notification object model that adds a
-REQUIRED Subscription object which together with the Job and Printer
-object provide the complete notification semantics.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 19]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-The object relationships can be seen pictorially as:
-
-
- Subscription objects (Per-Printer Subscriptions) Printer object
- +----+ +------------+
- | s1 |<---------------------------------------------->| |
- +----++ | |
- | s2 |<--------------------------------------------->| p1 |
- +----++ | |
- | s3 |<-------------------------------------------->| |
- +----+ +------------+
- Job objects
- +---------+
- | |
- +----+ | j1 |
- | s4 |<-------->| |
- +----+ | |
- | | s4 is a Per-Job subscription object
- ++--------++
- | |
- +----+ | j2 |
- | s5 |<------->| |
- +----++ | |
- | s6 |<------>| | s5 and s6 are Per-Job subscription
- +----+ ++--------++ objects
- | |
- | j3 |
- | |
- | | <----> indicates association
- +---------+
-
- Figure 6 - Object Model for Notification
-
- s1, s2, and s3 are Per-Printer Subscription objects and can
- identify Printer and/or Job events.
- s4, s5, and s6 are Per-Job subscription objects and can identify
- Printer and/or Job events.
-
-4.1 Object relationships
-
-This sub-section defines the object relationships between the Printer,
-Job, and Subscription objects. Whether Per-Printer Subscription objects
-are actually contained in a Printer object or are just bi-directionally
-associated with them in some way is IMPLEMENTATION DEPENDENT and is
-transparent to the client. Similarly, whether Per-Job Subscription
-objects are actually contained in a Job object or are just bi-
-directionally associated with them in some way is IMPLEMENTATION
-DEPENDENT and is transparent to the client. The object relationships
-are defined as follows:
-
-4.1.1 Printer object and Per-Printer Subscription objects
-
- 1. The Printer object contains (is associated with) zero or more Per-
- Printer Subscription objects (p1 contains s1-s3 Per-Printer
- Subscription objects).
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 20]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- 2. A Per-Printer Subscription object (s1-s3) cannot be contained in
- (or associated with) more than one Printer object (p1).
-
- 3. Each Per-Printer Subscription object (s1, s2, and s3) is contained
- in (or is associated with) one Printer object (p1) and each
- represents one Per-Printer subscription.
-
- 4. Each Per-Printer Subscription object identifies one or more Job
- and/or Printer events. Such Job events are for all jobs on the
- Printer. Such Printer events are for any Printer event, no matter
- which job is processing and when no jobs are processing.
-
-4.1.2 Job object and Per-Job Subscription objects
-
- 1. A Job object (j1, j2, j3) contains (is associated with) zero or
- more Per-Job subscription objects (s4-s6). Job j1 is associated
- with Per-Job subscription object s4, Job j2 is associated with Per-
- Job subscription objects s5 and s6, and Job j3 is not associated
- with any Per-Job subscription object.
-
- 2. A Per-Job Subscription object cannot be contained in (or associated
- with) more than one Job object.
-
- 3. Each Per-Job Subscription object is contained in (or associated
- with) one Job object and each represents one Per-Job Subscription.
-
- 4. Each Per-Job Subscription object identifies one or more Job and/or
- Printer events. Such Job events are only for this job (different
- than "per-Printer" Subscriptions). Such Printer events are for any
- Printer event, no matter which job and when no jobs are processing
- (same as for "per-Printer" Subscriptions).
-
-
-5 Subscription Object attributes
-
-
-Table 2 lists the Subscription object attributes defined in this section
-and the related Printer Description attributes defined in section 6, if
-any. The definitions of the object attributes are specified in this
-section so that they can be referred to from the subsequent definitions
-of the operations that set them. All of the Subscription object
-attributes are READ-ONLY. They can be set only by specific operations
-that create or perform operations on Subscription objects (see section
-8).
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 21]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Table 2 - Subscription object attributes
-
-Subscription object Printer Related Printer Description
-attributes: support attribute(s)
-
-Set by client input to a
-Subscription Creation
-operation
-
-notify-recipient (uri) REQUIRED notify-schemes-supported
- (1setOf uriScheme)
-
-notify-events (1setOf type2 REQUIRED notify-events-default (1setOf
- keyword) type2 keyword)
-
- notify-events-supported (1setOf
- type2 keyword)
-
- max-events-supported
- (integer(5:MAX))
-
-notify-format REQUIRED notify-format-supported (1setOf
- (mimeMediaType) mimeMediaType)
-
-subscriber-user-data REQUIRED n/a
- (octetString(63))
-
-notify-charset (charset) OPTIONAL charset-supported (1setOf
- charset)
-
-notify-natural-languages OPTIONAL generated-natural-language-
- (1setOf supported (1setOf
- naturalLanguage) naturalLanguage)
-
-
-
-Subscription object Printer Related Printer Description
-attributes: support attribute(s)
-
-Printer initializes to 0,
-increments at beginning of
-each event
-
-subscription-request-id REQUIRED n/a
- (integer(0:MAX))
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 22]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-Subscription object Printer Related Printer Description
-attributes: support attribute(s)
-
-Printer sets as part of
-Subscription Creation
-operation
-
-subscription-id REQUIRED max-job-subscriptions-supported
- (integer(1:MAX)) (integer(0:MAX))
-
- max-printer-subscriptions-
- supported (integer(0:MAX))
-
-notify-lease-expiration- REQUIRED notify-lease-time-default
- time (integer(0:MAX)) (integer(0:MAX))
-
- notify-lease-time-supported
- (rangeOfInteger(0:MAX))
-
-printer-uri (uri) REQUIRED printer-uri-supported
-
-subscriber-user-name REQUIRED n/a
- (name(MAX))
-
-
-
-Subscription object Printer Related Printer Description
-attributes: support attribute(s)
-Returned by Printer on
-Subscription Creation
-operation
-
-notify-server-up-time REQUIRED printer-up-time
- (integer(1:MAX)) (integer(1:MAX))
-
-notify-persistence-granted REQUIRED persistent-subscriptions-
- (boolean) supported (boolean)
-
-Note: The Subscription object does not contain the "job-id"
-Subscription Description attribute. The Get-Subscriptions operation has
-the "job-id" as an input operation attribute, so the "job-id" isn't
-returned in the response. If an implementation needs such a link
-between Subscription objects and Job objects, then it keeps such a link
-as in internal attribute. The intent is that whether Per-Job
-Subscription objects are actually contained in a Job object or are just
-associated with them in some way is IMPLEMENTATION DEPENDENT and is
-transparent to the client.
-
-
-5.1 notify-recipient (uri)
-
-This REQUIRED READ-ONLY Subscription object attribute describes both
-where (the address of the Notification Recipient) and how (the delivery
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 23]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-method) notifications are to be delivered to the Notification Recipient
-when any of the events specified in the "notify-events" attribute occur.
-
-There are potentially many different notification delivery methods for
-IPP notifications, standardized as well as proprietary. This document
-does not define any of these delivery mechanisms; they will each be
-described in separate supplementary documents.
-
-Each of the notification delivery method documents must provide at least
-the following information:
-
- 1) The URI scheme used.
-
- 2) The supported and default delivery format, and if not one of the
- specified types in Section 5.3, description of the notification
- content.
-
- 3)Any content length restrictions imposed by the delivery protocol.
-
- 4) The latency of the delivery protocol used.
-
- 5)The reliability of the transport and delivery protocol used.
-
- 6) The security aspects of the transport and delivery protocol used,
- e.g. how it is handled in firewalls.
-
- 7) How the delivery protocol is initiated, e.g. does it have to be
- initiated by the receiving user (pull), or is it initiated by the
- notification service (push).
-
-The following notification delivery schemes are defined in other
-documents for use as part of the URI value of this attribute:
-
- 'ipp:' - The Notification Recipient uses server directed polling to
- pull Notifications [ipp-method-poll]
-
- 'indp:' - The Notification Source sends Send-Notifications operations
- to the Notification Recipient [ipp-method-indp]
-
- 'mailto:' - The Notification Source sends a email message using SMTP
- with possible attachments containing Machine Consumable
- Notification Content [ipp-method-mailto]
-
- 'snmpnotify:' - The Notification Source sends SNMP traps and/or
- informs to the Notification Recipient [ipp-method-snmp]
-
-This list of notification delivery schemes will be added to as needed
-using the registration procedures defined in [ipp-mod].
-
-ISSUE 01 - Once a number of delivery solutions have been developed and
-evaluated, we may want to make one or several of them REQUIRED for
-implementation to ensure a minimum set of interoperability. Which one
-or ones should be REQUIRED?
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 24]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-5.2 notify-events (1setOf type2 keyword)
-
-This REQUIRED READ-ONLY Subscription object attribute identifies the job
-and/or printer events that are to be delivered to the Notification
-Recipient as Notifications as defined in section 7. If the client did
-not supply this attribute when supplying the subscription, the Printer
-object populates this attribute with its "notify-events-default"
-attribute value (see section 6.2).
-
-There are both job events and printer events. Each job and printer
-event is assigned a keyword to use in this attribute and in the
-Notification. Job and printer events have the following semantics
-depending on whether the subscription is a Per-Job or a Per-Printer
-subscription:
-
- Job events: The semantics for job events depends on whether the
- subscription is a Per-Job Subscription or a Per-Printer
- Subscription. For Per-Job Subscriptions, the Printer MUST
- generate Notifications only for the job events of the job with
- which the Subscription is associated. For Per-Printer
- Subscriptions, the Printer MUST generate Notifications for the
- job events for any job submitted to the Printer.
-
- For example, consider the event when there are 10 'pending'
- jobs, one 'processing' job, and 30 'completed' jobs and the
- 'processing' job completes. The Printer MUST generate a 'job-
- completed' job event Notification if the job has a Per-Job
- Subscription that contained the 'job-completed' event in this
- attribute. The Printer MUST NOT generate Notifications for
- any other jobs whose Per-Job Subscriptions contain the 'job-
- completed' event in this attribute.
-
- Printer events: The semantics for printer events does not depend
- on whether the subscription is a Per-Job or a Per-Printer
- Subscription. For both Per-Job Subscriptions and Per-Printer
- Subscriptions, the Printer MUST generate Notifications for
- printer events, no matter what job is processing, including
- when no jobs are processing.
-
- For example, consider the event when there are 10 'pending'
- jobs, one 'processing' job, and 30 'completed' jobs and the
- Printer enters the 'stopped' state. The Printer MUST generate
- a 'printer-state-changed' printer event Notification for each
- of the 11 'pending' and 'processing' jobs whose Per-Job
- Subscriptions contain the 'printer-state-changed' event in
- this attribute. The Printer MUST NOT generate Notifications
- for any of the 'completed' jobs' whose Per-Job Subscriptions
- contain the 'printer-state-changed' event in this attribute.
-
-The events are defined to be disjoint. For example, the 'job-state-
-changed' event does not include the 'job-created' and 'job-completed'
-events. In order to get all three events, the client supplies all three
-keywords in this attribute.
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 25]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-A Printer MUST support the events indicated as "REQUIRED" and MAY
-support of the events indicated as "OPTIONAL".
-
-The standard job event keyword values are:
-
- 'none': REQUIRED - no notifications of any events (an IPP object can
- use this value to indicate that it is configured not to support
- event notification; a client would not subscribe to this event).
-
- 'job-created': REQUIRED - the Printer object has accepted a Job
- Creation operation (Print-Job, Print-URI, or Create-Job) and the
- job's "time-at-creation" attribute value is set (see [ipp-mod]
- section 4.3.14.1). The Printer puts the job in the 'pending',
- 'pending-held' or 'processing' states.
- Note: This event is separate from the 'job-state-changed' event so
- that it can be subscribed to without having to get every job state
- change event for a Notification Recipient that is only interested
- in when the job is first created.
-
- 'job-completed': REQUIRED - the job has reached one of the completed
- states, i.e., the value of the job's "job-state" attribute has
- changed to: 'completed', 'aborted', or 'canceled'. The Job's
- "time-at-completed" and "date-time-at-completed" (if supported)
- attributes are set (see [ipp-mod] section 4.3.14).
- Note: This event is separate from 'job-state-changed' so that it
- can be subscribed to without having to get every job state change
- event for a Notification Recipient that is only interested in when
- the job is completed.
-
- 'job-state-changed': REQUIRED - the job has changed from any state
- to any other state and/or a value has been added or removed from
- the job's "job-state-reasons" attribute, except when the job is
- created or when the job moves to any of the "completed" job states
- ('completed', 'aborted', or 'canceled').
-
- This event also indicates that one or more values have been added
- to or removed from the Job's "job-state-reasons" attribute, such as
- 'job-queued' or 'job-printing', whether or not the job's state has
- changed. If job state reasons are added when the job is created,
- only the 'job-created' event is generated, in order to keep the
- events disjoint. If job state reasons are added or removed when
- the job is completed, only the 'job-completed' event is generated,
- in order to keep the events disjoint.
-
- A client that wants to subscribe to all job state changes,
- including creation and completion, includes the 'job-created',
- 'job-state-changed', and 'job-completed' in the notification
- subscription. When a job is finally removed from the Job History
- (see [ipp-mod] 4.3.7.1) no event is generated, i.e., neither a
- 'job-state-changed' event nor a 'job-purged' event is generated.
-
- 'job-config-changed': OPTIONAL - when the configuration of a job has
- changed, i.e., the value of the "job-message-from-operator" or any
- of the non-READ-ONLY Job attributes have changed, such as any of
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 26]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- the job template attributes or the "job-name" attribute. Often,
- such a change is the result of the user or the operator performing
- a Set-Job-Attributes operation (see [ipp-set]) on the Job object.
- The client performs a Get-Job-Attributes to find out the new values
- of the changed attributes. This event is useful for GUI clients
- and drivers to update the job information to the user.
-
- 'job-purged': OPTIONAL - when a 'not-completed' job (i.e., not
- 'completed', 'canceled', or 'aborted') was purged from the printer
- using the Purge-Jobs operation. No event, including this event, is
- generated when a job is aged out of the Job History or moved out
- explicitly with the Purge-Jobs operation.
-
- 'job-progress' - a sheet or copy has completed. See separate [ipp-
- prog] spec.
-
-The standard Printer event keywords values are:
-
- 'none': REQUIRED - no notification of any events (an IPP object can
- use this value to indicate that it is configured not to support
- event notification; a client would not subscribe to this event).
-
- 'printer-restarted': OPTIONAL - when the printer is powered up or
- the Restart-Printer operation is performed (see [ipp-mod]).
- Note: This event is separate from the 'printer-state-changed'
- event so that it can be subscribed to without having to get every
- printer state change event, for a Notification Recipient that is
- only interested in when the Printer first comes up.
-
- 'printer-shutdown': OPTIONAL - when the device is being powered down
- or the Shutdown-Printer operation has been performed (see [ipp-
- set2]).
- Note: This event is separate from 'printer-state-changed' so that
- it can be subscribed to without having to get every Printer state
- change event, for a Notification Recipient that is only interested
- in when the Printer is powered down or shutdown.
-
- 'printer-state-changed': REQUIRED - the Printer changed state, i.e.,
- the value of the Printer's "printer-state", "printer-state-reasons"
- (whether "printer-state" changed or not), and/or "printer-is-
- accepting-jobs" attributes changed, except when the Printer starts
- up or is shutdown. If printer state reasons are added when the
- Printer is started up, only the 'printer-restarted' event is
- generated, in order to keep the events disjoint. If printer state
- reasons are added or removed when the printer is powered-down or
- shutdown, only the 'printer-shutdown' event is generated, in order
- to keep the events disjoint.
-
- A client that wants to subscribe to all printer state changes,
- including restart and power-down/shutdown, includes the 'printer-
- restarted', 'printer-state-changed', and 'printer-shutdown' in the
- notification subscription.
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 27]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- 'printer-media-changed': OPTIONAL - when the media loaded on a
- printer has been changed, i.e., the "media-ready" attribute has
- changed. This event includes both an actual media change and
- filling an empty input tray with the same or different media. The
- client must check the "media-ready" Printer attribute (see [ipp-
- mod] section 4.2.11) separately to find out what new media was
- loaded or filled.
-
- 'printer-config-changed': OPTIONAL - when the configuration of a
- Printer has changed, i.e., the value of the "printer-message-from-
- operator" or any non-READ-ONLY Printer attribute has changed,
- except for "media-ready" (which has its own event), whether through
- the Set-Printer-Attributes operation or by other means and whether
- initiated by a human or not. For example, any "xxx-supported",
- "xxx-default", "printer-message-from-operator", etc. values have
- changed. The client has to perform a Get-Printer-Attributes to
- find out the new values of these changed attributes. This event is
- useful for GUI clients and drivers to update the available printer
- capabilities to the user.
-
- 'printer-queue-changed': OPTIONAL - the order of jobs in the
- Printer's queue has changed, so that an application that is
- monitoring the queue can perform a Get-Jobs operation to determine
- the new order. This event does not include when a job enters the
- queue (the 'job-created' event covers that) and does not include
- when a job leaves the queue (the 'job-completed' event covers
- that).
-
- 'printer-no-longer-full': OPTIONAL - when the Printer can now accept
- a Print-Job, Print-URI, Create-Job, Send-Document, or Send-URI
- request. This event is used when there is more than one client
- feeding a printer/server (fan-in), and the Printer may still be
- printing but has acquired more buffer space to accept jobs. This
- event only occurs when the Printer did not have room to accept jobs
- previously and rejected a Print-Job, Print-URI, Create-Job, Send-
- Document, or Send-URI operation.
-
- 'printer-almost-idle': OPTIONAL - when the Printer needs another Job
- in order to stay busy. This event is used when a spooler is
- feeding more than one printer/server (fan-out), and the spooler
- holds jobs until a Printer requests them, rather than committing
- jobs to IPP Printers before it is necessary. This event MAY be
- used by a Printer implementation to request a new job from any
- subscribers sufficiently ahead of time so that the device does not
- run out of work between jobs.
-
-
-5.3 notify-format (mimeMediaType)
-
-This REQUIRED READ-ONLY Subscription object attribute indicates the MIME
-Media type of Human Consumable and/or Machine Consumable format content
-that is to be sent in the Notifications for the Notification Content
-that is under control of the Subscriber. Depending on the delivery
-method definition document, this attribute MAY specify the MIME Media
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 28]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-type for the entire Notification Content, or just a portion that is
-controllable by the subscriber, if there is a fixed part as well. For
-example, if the entire Notification Content is always a fixed Machine
-Consumable MIME Media type, such as the 'ipp:' delivery method which
-uses the 'application/ipp' MIME Media type (see [indp-method]), then
-this attribute controls the format of the "human-readable-report"
-(text(MAX)) Notification Content attribute (see section 7.2) in the
-Machine Consumable form. As another example, if the Notification
-Content is always a Human Consumable format content with a MIME Media
-attachment, such as with the 'mailto:' delivery method [ipp-method-
-mailto], this attribute controls the format of the attachment.
-
-If the 'text' MIME media type registration permits a charset parameter,
-than such a specification MUST be used (instead of the "notify-charset"
-attribute - see section 5.5) in order to indicate the charset to be used
-in the notification content.
-
-If the Subscriber did not supply this attribute when requesting the
-subscription, the Printer object populates this Subscription object
-attribute with either the 'none' out-of-band value (see section 10.1) or
-one of the values of the Printer's "notify-format-supported" attribute
-(see section 6.5), depending on the delivery method and implementation,
-since there is no "notify-format-default" defined in this document.
-
-Standard mimeMediaType values are:
-
- 'none': This out-of-band value (see section 10.1) indicates that the
- Subscriber-controllable part of the Notification content is not to
- be sent.
- 'text/plain; charset=utf-8': Human Consumable plain text containing
- characters from ISO 10646 represented as UTF-8 [RFC2279] as defined
- in section 7.1.1.
- 'text/html': Human Consumable HTML data [RFC1866] as defined in
- section 7.1.1.
- 'text/xml': Machine Consumable XML data [RFC2376] as defined in
- section 7.1.2.
- 'application/ipp': Machine Consumable IPP request as defined in
- section 7.1.2 data encoded as in [ipp-pro].
- 'application/postscript': Human Consumable PostScript [RFC2046]
- 'image/tiff': Human Consumable image data [RFC2302]
-
-5.4 subscriber-user-data (octetString(63))
-
-This REQUIRED READ-ONLY Subscription object attribute holds opaque
-information being sent from the Subscriber to the Notification
-Recipient, such as the identify of the Subscriber or a path or index to
-some Subscriber information. Or it MAY contain a key that the
-Notification Recipient needs in order to process the Notification, such
-as the ultimate recipient, if the Notification Recipient is a general
-application that in turn forwards notifications and the ultimate
-recipient isn't included in the value of the "notify-recipient"
-attribute. An Instant Messaging Service is an example of such a general
-application where the "subscriber-user-data" might be the user's id for
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 29]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-that messaging service and the "notification-recipient" is the URL of
-the messaging service.
-
-
-5.5 notify-charset (charset)
-
-This OPTIONAL READ-ONLY Subscription object attribute specifies the
-charset to be used in the Notification content sent to the Notification
-Recipient, whether the notification content is Machine Consumable or
-Human Consumable. This attribute MUST NOT be used when the "notify-
-format" attribute value specifies the charset parameter in its MIME
-media type value, e.g., 'text/plain; charset=utf-8'.
-
-
-5.6 notify-natural-language (naturalLanguage)
-
-This OPTIONAL READ-ONLY Subscription object attribute specifies the
-natural language for the IPP object to use in the Notification content
-that is sent to the Notification Recipient, whether the notification
-content is Machine Consumable or Human Consumable.
-
-
-5.7 subscription-request-id
-
-This REQUIRED READ-ONLY Subscription object attribute holds the most
-recent request-id sequence number delivered in a Notification content to
-the Notification Recipient. A value of 0 indicates that no
-Notifications have been sent for this subscription. The first request-
-id sent for a subscription MUST be 1. Each Notification Recipient
-receives its own monotonically increasing series of request-ids
-operation parameters (see [ipp-mod] section 3.1.2), i.e., no gaps, in
-order to be able to detect a missing notification.
-
-
-5.8 subscription-id (integer (1:MAX))
-
-This REQUIRED READ-ONLY Subscription object attribute uniquely
-identifies this Subscription object instance on this Printer object or
-this Job object. The Printer object, on acceptance of a Create-Job-
-Subscription or Create-Printer-Subscription request, generates an ID
-which identifies the new Subscription object on that Printer or Job.
-The Printer returns the value of the "subscription-id" attribute as part
-of the response to a Create-Job-Subscription or Create-Printer-
-Subscription request. The 0 value is not included to allow for
-compatibility with "job-id" and with SNMP index values which also cannot
-be 0.
-
-It is RECOMMENDED that Per-Printer Subscription objects be persistent.
-Then the Subscription objects including the subscription-id remains
-unique across power-cycles. Even if an implementation does not make
-Per-Printer subscription objects persist, the implementation SHOULD make
-every attempt not to re-use subscription ids that subscribers might
-still think are valid. In other words, the Printer SHOULD at least keep
-the next subscription-id to be assigned in non-volatile memory. Note:
-it is assumed that Per-Job subscriptions are persistent if Jobs are
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 30]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-persistent, in order to be consistent with the persistency of Job
-objects. The [ipp-mod] RECOMMENDS that Job objects be persistent.
-
-
-5.9 notify-lease-expiration-time (integer(0:MAX))
-
-This REQUIRED READ-ONLY Subscription object attribute specifies the time
-in the future when the subscription lease will expire, i.e., the
-"printer-up-time" value at which the lease will expire. When the
-Printer object creates a Per-Printer Subscription object, it populates
-this attribute with the appropriate value. When the indicated time
-arrives, the Printer MUST delete the Per-Printer Subscription object.
-Per-Job Subscription objects always return a value of 0 since Per-Job
-Subscriptions don't have a lease, but exist for the life-time of the Job
-instead.
-
-A client is able to extend a lease of a Per-Printer subscription using
-the Renew-Subscription operation (see section 8.3.3). A value of 0
-indicates an infinite time, if such a policy is supported as indicated
-in the "notify-lease-time-supported" (integer(0:MAX)) Printer
-Description attribute (see section 6.8) and the subscriber is authorized
-to request an infinite lease. A Per-Job subscription cannot be renewed.
-
-Note: In order to compute the number of seconds remaining in a Per-
-Printer Subscription lease, a client can subtract the "notify-server-up-
-time" Subscription object attribute (see section 5.12) from the "notify-
-lease-expiration-time" Subscription object attribute.
-
-
-5.10printer-uri (uri)
-
-This REQUIRED READ-ONLY Subscription object attribute identifies the
-Printer object that created this Subscription object. When a Printer
-object creates a Subscription object, it populates this attribute with
-the Printer object URI that was used in the create request. This
-attribute permits a client to identify the Printer object URI that was
-used to create this Subscription object, i.e., what security scheme was
-used.
-
-
-5.11subscriber-user-name (name(MAX))
-
-This REQUIRED READ-ONLY Subscription object attribute contains the name
-of the user that created the Subscription object. The Printer object
-sets this attribute to the most authenticated printable name that it can
-obtain from the authentication service over which the IPP operation was
-received. This attribute is intended to help a human user determine for
-which Per-Printer Subscriptions they are the Subscriber. Only if such
-is not available, does the Printer object use the value supplied by the
-client in the "requesting-user-name" operation attribute of the create
-operation (see [IPP-MOD] Sections 4.4.2, 4.4.3, and 8). For Per-Job
-subscriptions created as part of the Job creation operation, the value
-of the "subscriber-user-name" is the same as the "job-originating-user-
-name" Job attribute (see [ipp-mod] section 4.3.6).
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 31]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-The value of the "subscriber-user-name" is implementation dependent when
-a server accepts a request and forwards it to a downstream IPP Printer
-(see Figure 2 and the [ipp-iig]).
-
-Note: The Printer object needs to keep an internal originating user id
-of some form, typically as a credential of a principal, with the
-Subscription object. Since such an internal attribute is
-implementation-dependent and not of interest to clients, it is not
-specified as a Subscription Description attribute. This originating
-user id is used for authorization checks (if any) on all subsequent
-operations.
-
-
-5.12notify-server-up-time (integer(1:MAX))
-
-This REQUIRED READ-ONLY Subscription object attribute indicates the
-amount of time (in seconds) that the Printer or Notification Delivery
-Service implementation has been up and running. This attribute is an
-alias for the Printer's "printer-up-time" attribute" (see [ipp-mod]
-section 4.4.29) if the Printer is keeping the Subscription objects or is
-the up time for the Notification Delivery Service if the Printer has
-delegated the responsibility for keeping Subscription objects to a
-notification delivery service, in an analogous way that the Job's "job-
-printer-up-time" is an alias for "printer-up-time" Printer attribute
-(see [ipp-mod] section 4.3.13.4).
-
-Note: The purpose of this attribute is so that a client can request
-this attribute in a Get-Subscription-Attributes or Get-Subscriptions
-request and use the value returned in combination with the "notify-
-lease-expiration-time" (see section 5.9) in order to display the wall
-clock time equivalent to the user. The difference between this
-attribute and the 'integer' value of the "notify-lease-expiration-time"
-attribute is the number of seconds in the future that the subscription
-will expire. A client can compute the wall-clock time at which the
-subscription will expire by adding this difference to the client.s wall-
-clock time.
-
-
-5.13notify-persistence-granted (boolean)
-
-This REQUIRED READ-ONLY Subscription object attribute indicates whether
-or not the Per-Job or Per-Printer Subscription is persistent, i.e.,
-saved across power cycles in an implementation-define manner.
-
-
-6 Printer Description Attributes related to Notification
-
-
-This section defines the Printer Description attributes that are related
-to Notification. Table 3 lists the Printer Description attributes and
-indicates the Printer support required for conformance and whether or
-not the attribute is READ-ONLY: .
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 32]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Table 3 - Printer Description attributes associated with Notification
-
-Printer object attributes: Printer READ-
- support ONLY?
-
-notify-schemes-supported (1setOf uriScheme) REQUIRED no
-
-notify-events-default (1setOf type2 keyword) REQUIRED no
-
-notify-events-supported (1setOf type2 keyword) REQUIRED no
-
-max-events-supported (integer(5:MAX)) REQUIRED no
-
-notify-format-supported (1setOf mimeMediaType) REQUIRED no
-
-max-job-subscriptions-supported (integer(0:MAX)) REQUIRED no
-
-max-printer-subscriptions-supported (integer(0:MAX)) REQUIRED no
-
-notify-lease-time-supported (rangeOfInteger(0:MAX)) REQUIRED no
-
-notify-lease-time-default (integer(0:MAX)) REQUIRED no
-
-persistent-jobs-supported (boolean) OPTIONAL no
-
-persistent-subscriptions-supported (boolean) OPTIONAL no
-
-printer-state-change-time (integer(1:MAX)) PTIONAL yes
-
-printer-state-change-date-time (dateTime) OPTIONAL yes
-
-
-6.1 notify-schemes-supported (1setOf uriScheme)
-
-This REQUIRED Printer attribute describes the notification delivery
-methods supported by this Printer object. Standard values are defined in
-Section 5.1.
-
-
-6.2 notify-events-default (1setOf type2 keyword)
-
-This REQUIRED Printer attribute identifies the event values if the
-client does not supply the "notify-events" operation attribute in a
-Subscription Creation operation. Any value in this attribute MUST also
-appear in the "notify-events-supported" attribute, i.e., be a supported
-event.
-
-
-6.3 notify-events-supported (1setOf type2 keyword)
-
-This REQUIRED Printer attribute identifies the events supported by this
-Printer object for both Per-Job and Per-Printer subscriptions which MUST
-be the same. Standard values are defined in Section 5.2.
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 33]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-6.4 max-events-supported (integer(5:MAX))
-
-This REQUIRED Printer attribute specifies the maximum number of events
-that are supported in a single Per-Job or Per-Printer subscription which
-must be the same. A Printer MUST support at least 5 events per
-subscription, so that clients can depend on at least 5 events in a
-single subscription. If the number of events supplied by a client in a
-subscription exceed this number, the Printer rejects the request and
-returns the 'client-error-too-many-events (see section 15.4). If
-notification is not supported, this attribute MUST NOT be supported.
-
-
-6.5 notify-format-supported (1setOf mimeMediaType)
-
-This REQUIRED Printer attributes identifies the MIME media types
-supported for Human Consumable and/or Machine Consumable notification
-content that the subscriber can control, if any. If the Notification
-content is fixed by the implementation, then the value of this attribute
-is that MIME media type, if is has been registered, or the 'none' out-
-of-band value (see section 10.1) otherwise. See the definition of the
-"notify-format" attribute in section 5.3 for details and some example
-values.
-
-Not all formats listed in the "notify-format-supported" attribute need
-be available with all delivery methods specified in the "notify-schemes-
-supported". However, all Human Consumable formats, if any, SHOULD be
-available with all delivery methods. It is much harder to support a
-Human Consumable format because of localization issues. Once the code
-is written to support a particular Human Consumable format, it is easy
-to transmit it on any of the supported notify-schemes. Thus, if a
-vendor decides to support a notify-scheme, it has already committed to
-implement the Machine Consumable format. This may be simple if existing
-code can be reused, e.g. application/ipp and or more difficult if new
-code must be written, e.g., it is SNMP.
-
-
-6.6 max-job-subscriptions-supported (integer(0:MAX))
-
-This REQUIRED Printer attribute specifies the maximum number of Per-Job
-subscriptions that are supported for a job, i.e., the maximum number of
-collection values for the "job-notify" operation attribute, and/or the
-maximum number of subsequent Create-Job-Subscription operation requests
-in combination for a job. A value of 0 indicates no effective maximum.
-A Printer MUST support at least 1 Per-Job subscription. If the number
-of Per-Job subscriptions supplied by a client in a Job Creation request
-exceeds the value of this attribute or would exceed some implementation-
-defined total number of Per-Job Subscriptions for the Printer, the
-Printer MUST accept the Job Creation and ignore the excess
-subscriptions. If a subsequent Create-Job-Subscription request would
-exceed this number, the Printer rejects the request and returns the
-'client-error-too-many-subscriptions' (see section 15.3).
-
-If a Printer does not support Per-Job Subscriptions, it MUST NOT support
-this attribute. The usual way for a client to determine whether an IPP
-Printer supports a feature is to query the Printer's "operations-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 34]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-supported" attribute. However, there is no new REQUIRED operation for
-Per-Job Subscriptions. Therefore, the RECOMMENDED way for a client to
-determine whether or not a Printer supports Per-Job Subscriptions is to
-query this attribute to see if it is supported (since the Create-Job-
-Subscriptions is an OPTIONAL operation).
-
-
-6.7 max-printer-subscriptions-supported (integer(0:MAX))
-
-This REQUIRED Printer attribute specifies the maximum number of Per-
-Printer subscriptions that are supported by multiple Create-Printer-
-Subscription requests, i.e., the maximum number of un-expired Per-
-Printer Subscription objects that the Printer supports at a time. A
-value of 0 indicates no effective maximum. A Printer MUST support at
-least 1 Per-Printer subscription. If the number of Per-Printer
-subscriptions exceeds the value of this attribute or would exceed some
-implementation-defined total number of Per-Printer Subscriptions for the
-Printer (if any), the Printer rejects the Create-Printer-Subscription
-request and returns the 'client-error-too-many-subscriptions' (see
-section 15.3).
-
-If a Printer does not support Per-Printer Subscriptions, then it MUST
-NOT support this attribute. None the less, the RECOMMENDED way for a
-client to determine whether or not a Printer supports Per-Printer
-Subscriptions is to query the "operations-supported" to see if the
-Create-Printer-Subscriptions operation is supported, rather than
-querying this attribute.
-
-
-6.8 notify-lease-time-supported (rangeOfInteger(0:MAX))
-
-This REQUIRED Printer attribute specifies the range of values in seconds
-that are supported for the "notify-lease-time-requested" operation
-attribute in a Create-Printer-Subscription or Renew-Subscription request
-for a Per-Printer subscription. When the lease time expires for a Per-
-Printer Subscription without renewing, the Printer MUST delete the
-Subscription object. If the client requests a value outside this range,
-the Printer MUST grant a value that is in this range (see section 5.9).
-A value of 0 indicates an infinite lease, i.e., one that does not
-expire.
-
-
-6.9 notify-lease-time-default (integer(0:MAX))
-
-This REQUIRED Printer attribute specifies the value of the lease time
-that the Printer object has been configured to assume if the client does
-not supply a "notify-lease-time-requested" operation attribute in the
-Create-Printer-Subscription or Renew-Subscription requests.
-
-
-6.10persistent-jobs-supported (boolean)
-
-This OPTIONAL Printer attribute indicates whether or not the Printer
-supports persistent Jobs, i.e., Jobs object that are preserved across
-power cycles. If Jobs are persistent, then Per-Job Subscriptions MUST
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 35]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-also be persistent, since they are part of the Job object. It is
-RECOMMENDED that Jobs (and Per-Job Subscriptions) be persistent.
-
-As with any settable attribute, if the Printer supports setting this
-attribute to more than one value, then the value being set MUST control
-whether or not the Printer keeps Jobs persistently as per the rules in
-[ipp-set]). As with any settable attribute, if the Printer only
-supports one value, it MAY support this attribute either (1) as settable
-to that one value, or as not-settable, depending on implementation (see
-[ipp-set]).
-
-
-6.11persistent-subscriptions-supported (boolean)
-
-This OPTIONAL Printer attribute indicates whether or not the Printer
-supports persistent Per-Printer Subscriptions, i.e., Subscription
-objects that are preserved across power cycles. When this value is
-'true' the implementation MAY support some that are persistent and some
-that are not. If the value is 'false' or the attribute is not
-supported, Per-Printer Subscriptions MUST NOT be persistent. It is
-RECOMMENDED that Per-Printer subscriptions be persistent.
-
-As with any settable attribute, if the Printer supports setting this
-attribute to more than one value, then the value being set MUST control
-whether or not the Printer keeps Jobs persistently as per the rules in
-[ipp-set]). As with any settable attribute, if the Printer only
-supports one value, it MAY support this attribute either (1) as settable
-to that one value, or as not-settable, depending on implementation (see
-[ipp-set]).
-
-
-6.12printer-state-change-time (integer(1:MAX))
-
-This OPTIONAL READ-ONLY Printer attribute records the time, i.e., copy
-of the Printer's "printer-up-time" attribute, that the Printer's
-"printer-state" attribute was last changed. On power-up, the Printer
-populates the "printer-state-change-time" from its "printer-up-time"
-attribute, so that it always has a value.
-
-
-6.13printer-state-change-date-time (dateTime)
-
-This OPTIONAL READ-ONLY Printer attribute records the date and time,
-i.e., copy of the Printer's "printer-current-time" (dateTime) attribute
-(see [ipp-mod] section 4.4.30), that the Printer's "printer-state"
-attribute was last changed. On power-up, the Printer populates the
-"printer-state-change-date-time" from its "printer-current-time"
-attribute, so that it always has a value.
-
-
-7 Notification Content
-
-
-This section defines the Notification content that is sent to a
-Notification Recipient when an event occurs. The Notification MAY be
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 36]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-sent by the IPP Printer or a third party Notification Service (see
-section 2.3).
-
-There are two notification content types: Machine Consumable and Human
-Consumable, i.e., 'text' MIME media type. For most notification
-delivery methods both content types are defined. Each Notification
-Content type will either define one specific Machine Consumable form
-(usual) or indicate that no Machine Consumable form is defined. In
-addition, each Notification Content type will indicates whether (usual)
-or not Human Consumable forms are permitted. But the definition will
-not define the Human Consumable forms. For those Human Consumable forms
-that a Printer implementation supports as indicated in the Printer's
-"notify-format-supported" attribute, it MUST support for all
-Notification Content formats supported that permit Human Consumable
-form.
-
-
-7.1 Notification content MIME media type formats
-
-This section defines the Notification content that the Notification
-Source sends asynchronously to each Notification Recipient based on the
-subscription information stored with the subscription. The Notification
-is either in a Human Consumable or Machine Consumable form.
-
-7.1.1 Human Consumable form
-
-If the notification delivery method is defined to permit Human
-Consumable forms such as the entire Notification Content or a portion of
-the Notification Content, such as either an attachment or the "human-
-readable-report" attribute (see section 7.2) then the following
-RECOMMENDATIONS apply:
-
-The text message SHOULD include information about the attributes in
-sections 7.2 and 7.3 for job events or in sections 7.2 and 7.4 for
-printer events. This information is localized according to the
-information about natural language and charset in the subscription.
-
-An implementation MAY extend the contents of a Human Consumable
-notification by adding additional information.
-
-7.1.2 Machine Consumable form
-
-If the notification delivery method is defined to have a Machine
-Consumable form and that form is defined to be the 'application/ipp'
-MIME media type [ipp-mod], then the following rules apply:
-
- 1.The notification content MUST use the 'application/ipp' MIME
- media type [ipp-mod] using one of: (1) the Get-Job-Attributes
- response encoding for job events, (2) Get-Printer-Attributes
- response for printer events, or (3) a new Sent-Notifications
- operation for both job and printer events.
-
- 2.The attributes listed in sections 7.2 and 7.3 are sent in a
- Notification for Job events.
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 37]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- 3.The attributes listed in sections 7.2 and 7.4 are sent in a
- Notification for Printer events.
-
- 4.For any 'text' or 'name' attribute value in any notification,
- the charset and natural language rules that apply to all IPP
- operations apply to these attributes as well, since they are
- represented as operation responses.
-
- 5.The "human-readable-report" attribute can be defined to be
- REQUIRED, OPTIONAL, or MUST NOT be sent.
-
- 6.If the values of any of the attributes sent in an notification
- content are not known, the value sent in the report content is
- the out-of-band 'unknown' value, rather than omitting the
- attribute (see the beginning of [ipp-mod] section 4.1).
-
-An implementation MAY extend the contents of the Machine Consumable
-notification by adding additional attributes. Notification Recipients
-MUST be able to accept Notifications containing attributes they do not
-recognize. What a Notification Recipient does with an unrecognized
-attribute is implementation-dependent. Notification Recipients MAY
-attempt to display unrecognized attributes anyway or MAY ignore them.
-
-
-7.2 Notification content attributes common to Job and Printer events
-
-This section lists the parameters and attributes that are included in
-both Job and Printer event Notifications.
-
-The notification delivery method either models the Notification as a (1)
-request if the IPP Printer sends the Notification to the Notification
-Recipient when the event occurs or as a (2) response if the IPP Printer
-is queried for the Notification by a Notification Recipient:
-
- Request: If the delivery method defines that the IPP Printer sends
- the Notification, then the delivery method also defines whether or
- not the Notification Recipient returns a response. If the IPP
- Printer sends a Notification request, it uses the "operation-id
- alternative for item #0 in Table 4:
-
- Response: If the delivery method defines that the IPP Printer
- supports an operation that returns a Notification as a response to
- the Notification Recipient, it uses the "status-code" alternative
- for item #0 in Table 4.
-
-Some events do not include all of these attributes as shown in Table 4.
-Each notification content contains a single Job or Printer event,
-whether that event was subscribed using the Job Submission Subscription
-mechanism or the Per-Printer subscription mechanism. If either kind of
-Subscription subscribed to both Job and Printer events, then the Printer
-will send or return them as separate Job Notification content and
-Printer Notification contents to the same Notification Recipient.
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 38]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-Table 4 lists the attributes that are defined for use in Notifications
-and indicates the Printer support required for conformance: References
-of the form "mod m.n.o" refer to [ipp-mod] sections.
-
- Table 4 - Common Job and Printer Notification content attributes
-
- Attributes Reference Events
-
- 'job- all others
- progress'
-
-The following attributes MUST occur in this order:
-
-version-number (integer mod 3.1.1 REQUIRED REQUIRED
-(0:32767))
-
-operation-id (integer (0:32767)) mod 3.1.1 REQUIRED REQUIRED
-or
-status-code (integer (0:32767))
-
-request-id (integer (0:MAX)) 5.7 & mod REQUIRED REQUIRED
- 3.1.1
-
-attributes-charset (charset) 5.5 & mod REQUIRED REQUIRED
- 3.1.4
-
-attributes-natural-language 5.6 & mod REQUIRED REQUIRED
-(naturalLanguage) 3.1.4
-
-printer-uri (uri) 5.10 REQUIRED REQUIRED
-
-The following attribute MAY occur in any order:
-
-printer-name (name(127)) mod 4.4.4 n/a REQUIRED
-
-job-id (integer(1:MAX)) mod 4.3.2 REQUIRED REQUIRED**
-
-job-name (name(MAX)) mod 4.3.5 n/a REQUIRED**
-
-trigger-event (type2 keyword) 7.2.1 REQUIRED REQUIRED
-
-trigger-time (integer(MIN:MAX)) 7.2.2 REQUIRED REQUIRED
-
-trigger-date-time (dateTime) 7.2.3 n/a OPTIONAL
-
-subscription-id (integer(1:MAX)) 5.8 REQUIRED REQUIRED
-
-subscriber-user-name (name(MAX)) 5.11 REQUIRED REQUIRED
-
-subscriber-user-data 5.4 REQUIRED REQUIRED
-(octetString(63))
-
-notify-format (mimeMediaType) 5.3 OPTIONAL OPTIONAL
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 39]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Attributes Reference Events
-
- 'job- all others
- progress'
-
-human-readable-report (text(MAX)) 7.2.4 OPTIONAL OPTIONAL
-
-Attribute Notes:
-
-"version-number" - the major and minor version number.
-
-"operation-id" - the operation id if the delivery method document models
- the Notification as the Printer sending the Notification to the
- Notification Recipient (whether the Notification Recipient returns
- a response or not).
-
-"status-code" - a value of 0x600 (hexadecimal 600) for a Job event and
- 0x601 (hexadecimal 601) for a Printer event if the delivery method
- document models the Notification as the Printer returning the
- Notification to the Notification Recipient as a response to a
- request.
-
-"request-id" - the sequence number for this subscription, starting at 1,
- for each subscription, i.e., the Printer copies the current value
- of the "subscription-request-id' Subscription object attribute to
- the Notification request content.
-
-"attributes-charset" - the value comes from the "notify-charset"
- attribute in the Subscription object.
-
-"attributes-natural-language" - the value comes from the "notify-
- natural-language" attribute in the Subscription object.
-
-"printer-uri" - the value comes from the "job-printer-uri" Job attribute
- for Per-Job subscriptions.
-
-**"job-id" and "job-name" - included in Printer event Notifications only
- for Per-Job subscriptions.
-
-"job-name" - SNMP delivery method can truncate to less than 255 octets,
- since the Notification needs to fit into 484 octets or so on some
- transports that SNMP is defined for. See [ipp-method-snmp]
-
-"subscription-id" - the unique identifier for the Subscription object on
- this Printer.
-
-"subscriber-user-name" - the subscriber user name that created the
- Subscription object. SNMP delivery method can truncate to less
- than 255 octets, since the Notification needs to fit into 484
- octets or so on some transports that SNMP is defined for. See
- [ipp-method-snmp]
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 40]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-"subscriber-user-data" - opaque user data that may identify either the
- Subscriber and/or the ultimate Notification Recipient. The client
- MUST supply this attribute, if the definition of the delivery
- method specified in the "notify-recipient" attribute REQUIRES the
- client to supply it.
-
-"notify-format (mimeMediaType) - indicates the text MIME media type (see
- section 5.3) for the "human-readable-report" attribute. This
- attribute MUST be present if the "human-readable-report"
- (text(MAX)) attribute is present in order to unambiguously identify
- the format of its text value to the Notification Recipient.
-
-7.2.1 "trigger-event" (type2 keyword)
-
-This REQUIRED Notification Content attribute indicates the event that
-caused this Notification to be delivered.
-
-7.2.2 "trigger-time" (integer(MIN:MAX))
-
-This REQUIRED Notification Content attribute indicates the time at which
-the event occurred, i.e., the "printer-up-time" value (see [ipp-mod]
-section 4.4.29) when the event occurred.
-
-7.2.3 "trigger-date-time" (dateTime)
-
-This OPTIONAL Notification Content attribute indicates the date and time
-at which the event occurred, i.e., the "printer-current-time" value (see
-[ipp-mod] section 4.4.30) when the event occurred.
-
-7.2.4 "human-readable-report" (text(MAX))
-
-This OPTIONAL Notification Content attribute contains the human
-consumable text message (see section 7.1.1) that describes the event and
-is represented in the text format specified by the "notify-format"
-attribute. Whether or not this attribute is defined depends on the
-delivery method definition document and MUST be defined only for use in
-the Machine Consumable format. If this attribute is defined for use in
-the Machine Consumable Notification, then whether this attribute is
-REQUIRED or OPTIONAL also depends on the delivery method definition
-document.
-
-
-7.3 Additional Notification content attributes for Job events only
-
-Table 5 lists the additional attributes that are included only in Job
-event Notifications and indicates the Printer support required for
-conformance: "R" indicates REQUIRED, "O" indicates OPTIONAL, and "CR"
-indicates CONDITIONALLY REQUIRED, i.e., REQUIRED in a Notification if
-the corresponding Job attributes are supported. Some events do not
-include all of these attributes as shown in Table 5.
-
-Table 5 - Additional Notification content attributes for Job events only
-
-Attributes Reference Events
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 41]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- 'job- 'job- all
- progre complet othe
- ss' ed' rs
-
-job-state (type1 enum) mod 4.3.7 R R R
-
-job-state-reasons (1setOf type2 mod 4.3.8 R R R
-keyword)
-
-job-k-octets (integer(0:MAX)) mod O O
- 4.3.17.1
-
-job-k-octets-processed (integer(0:MAX)) mod O O
- 4.3.18.1
-
-job-impressions (integer(0:MAX)) mod O O
- 4.2.17.2
-
-job-impressions-completed mod CR CR
-(integer(0:MAX)) 4.3.18.2
-
-impressions-completed-current-copy [ipp- R
-(integer(0:MAX)) prog]
-
-job-media-sheets (integer(0:MAX)) mod O O
- 4.3.17.3
-
-job-media-sheets-completed mod CR CR
-(integer(0:MAX)) 4.3.18.3
-
-job-collation-type (type2 enum) [ipp- R
- prog]
-
-sheet-completed-copy-number [ipp- R
-(integer(0:MAX)) prog]
-
-sheet-completed-document- [ipp- R
-number(integer(0:MAX)) prog]
-
-
-7.4 Additional Notification content attributes for Printer events only
-
-Table 6 lists the additional attributes that are included only in
-Printer event Notifications and indicates the Printer support required
-for conformance:
-
-Table 6 - Additional Notification content attributes for Printer events
- only
-
-Attributes Reference Events
-
- all printer
- events
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 42]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-Attributes Reference Events
-
- all printer
- events
-
-printer-state (type1 enum) mod 4.4.11 REQUIRED
-
-printer-state-reasons (1setOf type2 keyword) mod 4.4.12 REQUIRED
-
-printer-is-accepting-jobs (boolean) mod 4.4.23 REQUIRED
-
-
-8 Operations for notification
-
-
-This section defines all of the operations for notification which are
-summarized in Table 1 in section 1.1, including the assignment of the
-operation-id.
-
-
-8.1 Operations for Per-Job Subscriptions only
-
-This section defines the operation requests and responses that are
-related to Per-Job subscriptions and its Subscription object. Section
-8.3 defines the REQUIRED operation requests and responses associated
-with the REQUIRED Per-Printer subscription and its Subscription object.
-
-8.1.1 Job Creation Operations (Create-Job, Print-Job, Print-URI) and
- Validate-Job
-
-The usual method for a client to associate one subscription with a Job
-is to specify the subscription when the job is created. For a Per-Job
-Subscription, the client supplies the "job-notify (1setOf collection)"
-operation attribute with the member attributes listed in Table 7 with
-any of the Job Creation operations (Create-Job, Print-Job, Print-URI),
-plus Validate-Job (which doesn't create a job or subscription). If the
-client does not supply the "job-notify" attribute in the create
-operation, there is no subscription made (either implicitly or
-explicitly).
-
-If a Printer does not support this notification specification, then it
-MUST ignore the "job-notify" operation attribute and return it in the
-response indicated as an attribute that is not supported. See [ipp-mod]
-section 3.1.7 for details on returning Unsupported Attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 43]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Table 7 - Member attributes of the "job-notify" collection operation
- attribute
-
-Member attribute of "job-notify" Referen client Printer
-collection ce MUST support
- supply
-
-notify-recipient (uri) 5.1 yes REQUIRED
-
-notify-events (1setOf type2 keyword) 5.2 no REQUIRED
-
-notify-format (mimeMediaType) 5.3 no REQUIRED
-
-subscriber-user-data (octetString(63)) 5.4 depends on REQUIRED
- delivery
- method **
-
-notify-charset (charset) 5.5 no OPTIONAL
-
-notify-natural-language 5.6 no OPTIONAL
-(naturalLanguage)
-
-
-
-Table 8 shows the "job-notify" (collection) member attributes with their
-corresponding "xxx-default" and "xxx-supported" attributes. The Printer
-uses the "xxx-default" values if the client omits the member attribute
-in the request. The "xxx-supported" attributes are used by the Printer
-to validate the request. The client can query to determine supported
-values.
-
- Table 8 - "job-notify" supported and default attributes
-
-"job-notify" member "xxx-default", if "xxx-supported"
-attribute any
-
-notify-recipient none notify-schemes-supported
-(uri) (1setOf uriScheme)
-
-notify-events (1setOf notify-events-supported
- notify-events-
-type2 keyword) (1setOf type2 keyword)
- default (1setOf
- max-events-supported
- type2 keyword)
- (integer(5:MAX))
-
-notify-format none notify-format-supported
-(mimeMediaType) (1setOf mimeMediaType)
-
-subscriber-user-data none none
-(octetString(63))
-
-notify-charset charset-configured charset-supported (1setOf
-(charset) (charset) charset)
-
-notify-natural- natural-language- generated-natural-language-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 44]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-"job-notify" member "xxx-default", if "xxx-supported"
-attribute any
-
-language configured supported (1setOf
-(naturalLanguage) (naturalLanguage) naturalLanguage)
-
-See the referenced sections for a definition of these operation
-attributes, since they are copied to the Subscription object as the
-Subscription Description attributes described in section 5.
-
-The following rules apply to Per-Job subscriptions created as part of
-the Job Creation operations:
-
-1. Any subscription can contain job events, printer events, or both.
-
-2. The Job Submission Subscription is only valid while the job is "not-
- completed". The job is "not-completed" while it is in the
- 'pending', 'pending-held', 'processing', and 'processing-stopped'
- states. The job changes from being "not-completed" to "retained"
- when it is done processing and enters any of the 'completed',
- 'canceled', or 'aborted' states. The job becomes "not-completed"
- again when it is restarted using the Restart-Job operation (see
- [ipp-mod]).
-
-3. Since no job is created for the Validate-Job operation, the only
- purpose of supplying the subscription operation attributes in the
- Validate-Job operation is to validate that the values are supported;
- the Printer object does not establish a notification subscription as
- a result of the Validate-Job operation.
-
-4. Since a Job Submission Subscription is included within a job
- submission operation, any interest in job events is limited to "this
- job" only (the Job object created because of this job creation
- operation). There is no mechanism to subscribe to events for all
- jobs or specifically some job other than this job in a create
- operation. But see the Create-Printer-Subscription operation
- (section 8.2.1) for an explicit operation to subscribe for job
- and/or printer events independently of any particular job
- submission, i.e., Per-Printer subscriptions.
-
-5. Event reporting only occurs when a notification recipient has
- specified a subscription to any event(s).
-
-6. The notification implementation MAY allow an administrator to
- configure a policy on what events may be dropped.
-
-7. ** The client MUST supply the "subscriber-user-data"
- (octetString(63)) attribute, if the definition of the delivery
- method specified in the "notify-recipient" attribute REQUIRES the
- client to supply it.
-
-8. If the OPTIONAL "notify-charset" attribute is not supported or the
- supplied value is not supported, the IPP Printer MUST return the
- attribute in the Unsupported Attributes Group but still accept the
- operation, as with all Job create operations. In this case, the
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 45]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Printer MUST use the natural language supplied in the "attributes-
- charset" Job creation operation attribute, if that natural language
- value is supported by the Printer, else the Printer object MUST use
- the Printer's "charset-configured" value. See the Print-Job
- operation in [ipp-mod].
-
-9. If the OPTIONAL "notify-natural-language" attribute is not supported
- or the supplied value is not supported, the IPP Printer MUST return
- the attribute in the Unsupported Attributes Group but still accept
- the operation, as with all Job create operations. In this case, the
- Printer MUST use the natural language supplied in the "attributes-
- natural-language" Job creation operation attribute, if that natural
- language value is supported by the Printer, else the Printer object
- MUST use the Printer's "natural-language-configured" value. See the
- Print-Job operation in [ipp-mod].
-
-10. If a collection contains other unrecognized, unsupported member
- attributes and/or conflicting values, the attribute returned in the
- Unsupported Group is a collection containing the unrecognized,
- unsupported member attributes, and/or conflicting values. The
- Printer MUST return the unrecognized member attributes with the out-
- of-band value of 'unsupported'. The Printer MUST return the
- unsupported member attributes and conflicting values with their
- unsupported values. See [ipp-coll].
-
-11. If the number of events supplied in the "notify-events" attribute
- exceeds the Printer's "max-events-supported" attribute, the Printer
- MUST accept the request with the status code 'successful-ok-ignored-
- or-substituted-attributes' and return the "job-notify" collection in
- the Unsupported Attributes Group with only the "job-events" member
- attribute containing the events that exceed the maximum.
-
-12. If the Per-Job subscriptions would exceed the limit of Per-Job
- subscriptions supported per job as specified by the Printer's "max-
- job-subscriptions-supported" attribute or would exceed some
- implementation-defined limit on the total number of Per-Job
- subscriptions for the Printer (if any), the Printer MUST accept the
- request with the status code 'successful-ok-ignored-subscriptions',
- MUST return the "job-notify" attribute in the Unsupported Attributes
- Group with only the collection value(s) that represent the excess
- subscriptions that are being ignored, and MUST perform the Job
- Creation operation (see section 8.1.1), since the job can still be
- printed.
-
-13. If the job is accepted and one or more subscriptions are ignored,
- the status code returned is 'successful-ok-ignored-subscriptions.
- This status code is returned even if other job attributes are
- unsupported or in conflict. That is, if an IPP Printer finds a
- warning that would allow it to return 'successful-ok-ignored-
- subscriptions' and either 'successful-ok-ignored-or-substituted-
- attributes' and/or 'successful-ok-conflicting-attributes', it must
- return 'successful-ok-ignored-subscriptions'. In other words, the
- precedence for returning success codes is: 'successful-ok-ignored-
- subscriptions', 'successful-ok-conflicting-attributes', and
- 'successful-ok-ignored-or-substituted-attributes'.
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 46]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-8.1.2Create-Job-Subscription operation
-
-The OPTIONNAL Create-Job-Subscription operation creates a Per-Job
-Subscription object . The client can specify one or more job and/or
-printer events to be delivered as notifications to one Notification
-Recipient. For the Per-Job subscription objects, the Job events are for
-this job only. The printer events are any events generated by that
-Printer for any job or when no job is involved at all (same as for Per-
-Job Subscriptions).
-
-The Printer returns a subscription id and the length of time for which
-it has granted a lease for the subscription.
-
-A client can unsubscribe using the Cancel-Subscription operation
-(section 8.3.4) and the subscription id.
-
-Two Create-Job-Subscription operations with the same events and same
-Notification Recipient MUST be kept as distinct subscriptions and be
-assigned distinct subscription ids. A Printer MUST allow such duplicate
-subscriptions such that Cancel-Subscription doesn't unsubscribe both
-subscriptions and MUST send the Notifications twice to the Notification
-Recipient, since the "request-id" is supposed to count monotonically for
-each Subscription object.
-
-If the Printer has a bounded set of concurrent Per-Job subscriptions and
-the request would exceed that bound, the Printer rejects the operation
-and returns the 'client-error-too-many-subscriptions' status code. The
-client SHOULD try again later.
-
-Access Rights: To create Per-Job subscription objects, the
-authenticated user (see [IPP-MOD] section 8.3) performing this operation
-MUST either be the job owner or have operator or administrator access
-rights for the Printer object (see [IPP-MOD] sections 1 and 8.5).
-Otherwise the IPP object MUST reject the operation and return: the
-'client-error-forbidden', 'client-error-not-authenticated', or 'client-
-error-not-authorized' status code as appropriate.
-
-Request:
-
- Group 1: Operation Attributes Referencclient MUST Printer
- e [ipp- supply support
- mod]
- "attributes-charset" (charset) 3.1.4.1 yes REQUIRED
- "attributes-natural-language" 3.1.4.1 yes REQUIRED
- (naturalLanguage)
- "printer-uri" (uri) 3.1.5 yes REQUIRED
- "job-id" (integer(1:MAX)) 3.1.5 yes REQUIRED
- "job-uri" (uri) 3.1.5 if not REQUIRED
- "printer-
- uri" and
- "job-id"
- "requesting-user-name" 8.3 RECOMMENDED REQUIRED
- (name(MAX))
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 47]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Group 2: Subscription Attributes Referen client MUST Printer
- ce supply support
- "notify-recipient" (uri) 5.1 yes REQUIRED
- "notify-events" (1setOf type2 5.2 no REQUIRED
- keyword)
- "notify-format" (mimeMediaType) 5.3 no REQUIRED
- "subscriber-user-data" 5.4 depends on REQUIRED
- (octetString(63)) delivery
- method
- "notify-charset" (charset) 5.5 no OPTIONAL
- "notify-natural-language" 5.6 no OPTIONAL
- (naturalLanguage)
- "notify-persistence-requested" see no OPTIONAL
- (boolean) below
-
-Response:
-
- Group 1: Operation Attributes Reference REQUIRED
- [ipp-mod] in
- response
- "status-code" (type2 enum) 3.1.6.1 REQUIRED
- "attributes-charset" (charset) 3.1.4.2 REQUIRED
- "attributes-natural-language" 3.1.4.2 REQUIRED
- (naturalLanguage)
- "status-message" (text(255)) 3.1.6.2 OPTIONAL
- "detailed-status-message" (text(MAX)) 3.1.6.3 OPTIONAL
-
-
- Group 2: Unsupported Attributes (see [ipp-mod] REQUIRED if
- section 3.1.7) unsupported
- attributes
-
-
- Group 3: Subscriptions Attributes Reference REQUIRED
- in
- response
- "subscription-id" (integer(1:MAX)) 5.8 REQUIRED
- "notify-persistence-granted" (boolean) 5.13 REQUIRED
-
-Attribute Notes:
-
-"job-id" (integer(1:MAX)) - the client MUST either (1) supply this
- attribute, in combination with the "printer-uri" attribute, in
- order to create a Per-Job subscription for the Job identified by
- the "job-id" value or supply the "job-uri" instead, as with any Job
- operation:
-
-"job-uri" (uri) - the client MUST supply this attribute, if the
- "printer-uri" and "job-id" are not supplied, in order to identify
- the Job to which the Per-Job Subscription is being created.
-
-"notify-recipient" (uri) - the client MUST supply this attribute in
- order to have a subscription.
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 48]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-"notify-event" (1setOf type2 keyword) - if the client does not supply
- this attribute, the Printer populates the "notify-events"
- Subscription Description attribute from its "notify-events-default"
- Printer Description attribute.
-
-"notify-format" (mimeMediaType) - if the client supplies this attribute,
- the value indicates which Human Consumable text format is requested
- for use in the Notification using the delivery method that the
- client supplies in the "notify-recipient" attribute. If the client
- does not supply this attribute, the Machine-Consumable form of the
- delivery method that the client supplies in the "notify-recipient"
- attribute is used.
-
-"subscriber-user-data" (octetString(63)) - the client MUST supply this
- attribute, if the definition of the delivery method specified in
- the "notify-recipient" attribute REQUIRES the client to supply it.
-
-"notify-persistence-requested" (boolean) - whether or not the Per-Job
- Subscription is to be persistent, i.e., saved across power cycles.
- Note: Persistent trap registrations is a client option in SNMPv3
- [RFC2573].
-
-"notify-persistence-granted" (boolean) - whether or not this
- Subscription object instance is persistent. This attribute MUST be
- returned whether "notify-persistence-requested" is supported or
- not, so that the client knows which.
-
-
-8.2 Operations for Per-Printer Subscriptions only
-
-This section defines the operation requests and responses associated
-with the Per-Printer subscription and its Subscription object.
-
-8.2.1 Create-Printer-Subscription operation
-
-The REQUIRED Create-Printer-Subscription operation creates a Per-Printer
-Subscription object . The client can specify one or more job and/or
-printer events to be delivered as notifications to one Notification
-Recipient. For the Per-Printer subscription objects, the job events are
-for any job submitted to the Printer. The printer events are any events
-generated by that Printer for any job or when no job is involved at all.
-
-The Printer returns a subscription id and the time at which the
-subscription lease expires (which may be earlier or later than the
-client requested).
-
-The client MUST renew the Per-Printer subscription using the Renew-
-Subscription operation (see section 8.3.3) before the lease runs out in
-order to maintain the subscription. A client can unsubscribe using the
-Cancel-Subscription operation (section 8.3.4) and the subscription id.
-
-Two Create-Printer-Subscription operations with the same events and same
-Notification Recipient MUST be kept as distinct subscriptions and be
-assigned distinct subscription ids. A Printer MUST allow such duplicate
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 49]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-subscriptions such that Cancel-Subscription doesn't unsubscribe both
-subscriptions and MUST send the Notifications twice to the Notification
-Recipient, since the "request-id" is supposed to count monotonically for
-each subscription.
-
-If the Printer has a bounded set of concurrent Per-Printer subscriptions
-and the request would exceed that bound, the Printer rejects the
-operation and returns the 'client-error-too-many-subscriptions' status
-code. The client SHOULD try again later.
-
-Access Rights: To create Per-Printer subscription objects, the
-authenticated user performing this operation MUST have Per-Printer
-subscription rights for this Printer. Otherwise the IPP object MUST
-reject the operation and return: the 'client-error-forbidden', 'client-
-error-not-authenticated', or 'client-error-not-authorized' status code
-as appropriate.
-
-Request:
-
- Group 1: Operation Attributes Referen client Printer
- ce MUST support
- [ipp- supply
- mod]
- "attributes-charset" (charset) 3.1.4.1 yes REQUIRED
- "attributes-natural-language" 3.1.4.1 yes REQUIRED
- (naturalLanguage)
- "printer-uri" (uri) 3.1.5 yes REQUIRED
- "requesting-user-name" 8.3 RECOMMEND REQUIRED
- (name(MAX)) ED
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 50]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Group 2: Subscription Attributes Referen client Printer
- ce MUST support
- supply
- "notify-recipient" (uri) 5.1 yes REQUIRED
- "notify-events" (1setOf type2 5.2 no REQUIRED
- keyword)
- "notify-format" (mimeMediaType) 5.3 no REQUIRED
- "subscriber-user-data" 5.4 depends REQUIRED
- (octetString(63)) on the
- delivery
- method
- "notify-charset" (charset) 5.5 no OPTIONAL
- "notify-natural-language" 5.6 no OPTIONAL
- (naturalLanguage)
- "notify-lease-time-requested" see no REQUIRED
- (integer(0:MAX)) below
- "notify-persistence-requested" see no OPTIONAL
- (boolean) below
-
-Response:
-
- Group 1: Operation Attributes Reference REQUIRED
- in
- response
- "status-code" (type2 enum) 3.1.6.1 REQUIRED
- "attributes-charset" (charset) 3.1.4.2 REQUIRED
- "attributes-natural-language" 3.1.4.2 REQUIRED
- (naturalLanguage)
- "status-message" (text(255)) 3.1.6.2 OPTIONAL
- "detailed-status-message" (text(MAX)) 3.1.6.3 OPTIONAL
-
-
- Group 2: Unsupported Attributes (see [ipp-mod] REQUIRED if
- section 3.1.7) unsupported
- attributes
-
-
- Group 3: Subscription Attributes Reference REQUIRED
- in
- response
- "subscription-id" (integer(1:MAX)) 5.8 REQUIRED
- "notify-lease-expiration-time" 5.9 REQUIRED
- (integer(0:MAX))
- "notify-server-up-time" (integer(1:MAX)) 5.12 REQUIRED
- "notify-persistence-granted" (boolean) 5.13 REQUIRED
-
-Attribute Notes:
-
-"notify-recipient" (uri) - the client MUST supply this attribute in
- order to have a subscription.
-
-"notify-lease-time-requested" (integer(0:MAX) - the number of seconds
- requested for the subscription lease. A value of 0 indicates a
- request that the Per-Printer Subscription lease never expire.
- Supplying a 0 value MAY require authentication in order to be used,
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 51]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- if 0 is supported at all.
- If the client does not supply this attribute, the Printer uses its
- "notify-lease-time-default" Printer Description attribute value
- (see section 6.9).
-
-"notify-event" (1setOf type2 keyword) - if the client does not supply
- this attribute, the Printer populates the "notify-events"
- Subscription Description attribute from its "notify-events-default"
- Printer Description attribute.
-
-"notify-format" (mimeMediaType) - if the client supplies this attribute,
- the value indicates which Human Consumable text format is requested
- for use in the Notification using the delivery method that the
- client supplies in the "notify-recipient" attribute. If the client
- does not supply this attribute, the Machine-Consumable form of the
- delivery method that the client supplies in the "notify-recipient"
- attribute is used.
-
-"subscriber-user-data" (octetString(63)) - the client MUST supply this
- attribute, if the definition of the delivery method specified in
- the "notify-recipient" attribute REQUIRES the client to supply it.
-
-"notify-persistence-requested" (boolean) - whether or not the Per-
- Printer Subscription is to be persistent, i.e., saved across power
- cycles. Note: Persistent trap registrations is a client option in
- SNMPv3 [RFC2573].
-
-"notify-lease-expiration-time" (integer(0:MAX)) - The Printer object
- MUST return this attribute which is the time in the future at which
- the subscription lease will expire, i.e., the "printer-up-time"
- value (in time ticks - see [ipp-mod] section 4.4.29) at which the
- Printer will delete the Subscription. A value of 0 indicates that
- the lease subscription will never expire.
-
-"notify-server-up-time" (integer(1:MAX)) - The Printer object MUST
- return this attribute which is an alias for the Printer's "printer-
- up-time" Printer Description attribute. The client subtracts this
- value from the "notify-lease-expiration-time" value returned in
- order to determine the number of second in the future that the
- subscription will expire. This computed value may be less than the
- requester requested in the "notify-lease-time-requested" if it was
- greater than the MAX supported or more than the requester requested
- if it was less than the MIN supported, as indicated in the
- Printer's "notify-lease-time-supported" (rangeOfInteger(0:MAX))
- attribute (see section 6.8).
-
-"notify-persistence-granted" - whether or not this Subscription object
- instance is persistent. This attribute MUST be returned whether
- "notify-persistence-requested" is supported or not, so that the
- client knows which.
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 52]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-8.3 Common Operations for Per-Job and Per-Printer Subscriptions
-
-This section defines the operations that are common to both Per-Job and
- Per-Printer subscriptions.
-
-8.3.1 Get-Subscription-Attributes operation
-
-The REQUIRED Get-Subscription-Attributes returns the requested
-attributes of the identified Subscription object. See section 5.
-
-Request:
- Group 1: Operation Attributes Referen client Printer
- ce MUST support
- [ipp- supply
- mod]
- "attributes-charset" (charset) 3.1.4.1 yes REQUIRED
- "attributes-natural-language" 3.1.4.1 yes REQUIRED
- (naturalLanguage)
- "printer-uri" (uri) 3.1.5 yes REQUIRED
- "requesting-user-name" 8.3 RECOMMEND RECOMMEND
- (name(MAX)) ED ED
-
-
-
- Group 2: Subscription Attributes Referen client Printer
- ce MUST support
- supply
-
- "subscription-id" 5.8 yes REQUIRED
- (integer(1:MAX))
- "requested-attributes" (1setOf see no REQUIRED
- type2 keyword) below
-Response:
- Group 1: Operation Attributes Reference REQUIRED
- [ipp-mod] in
- response
- "status-code" (type2 enum) 3.1.6.1 REQUIRED
- "attributes-charset" (charset) 3.1.4.2 REQUIRED
- "attributes-natural-language" 3.1.4.2 REQUIRED
- (naturalLanguage)
- "status-message" (text(255)) 3.1.6.2 OPTIONAL
- "detailed-status-message (text(MAX)) 3.1.6.3 OPTIONAL
-
-
- Group 2: Unsupported Attributes (see [ipp-mod] REQUIRED if
- section 3.1.7) unsupported
- attributes
-
-
- Group 3: <the requested Subscription object REQUIRED
- attributes>
-
-This operation is similar to the Get-Printer-Attributes operation.
-
-"requested-attributes" (1setOf keyword): The client OPTIONALLY supplies
- this attribute. The Printer object MUST support this attribute.
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 53]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- It is a set of Subscription attribute names and/or the 'all'
- attribute group name in whose values the requester is interested.
- This set of attributes is returned for each Job object that is
- returned. If the client does not supply this attribute, the
- Printer MUST respond as if the client had supplied this attribute
- with the value: 'all'.
-
-8.3.2 Get-Subscriptions operation
-
-The REQUIRED Get-Subscriptions operation returns the requested
-attributes of the Subscription objects (see section 5).
-
-Request:
- Group 1: Operation Attributes Referen client Printer
- ce MUST support
- [ipp- supply
- mod]
- "attributes-charset" (charset) 3.1.4.1 yes REQUIRED
- "attributes-natural-language" 3.1.4.1 yes REQUIRED
- (naturalLanguage)
- "printer-uri" (uri) 3.1.5 yes REQUIRED
- "job-id" (integer(1:MAX)) 3.1.5 yes, if REQUIRED
- Per-Job
- Subscript
- ion
- "requesting-user-name" 8.3 RECOMMENT RECOMMEND
- (name(MAX)) ED ED
- "limit" (integer(1:MAX)) see OPTIONAL REQUIRED
- below
- "requested-attributes" (1setOf see OPTIONAL REQUIRED
- type2 keyword) below
- "my-subscriptions" (boolean) see OPTIONAL REQUIRED
- below
-Response:
- Group 1: Operation Attributes Reference REQUIRED
- [ipp-mod] in
- response
- "status-code" (type2 enum) 3.1.6.1 REQUIRED
- "attributes-charset" (charset) 3.1.4.2 REQUIRED
- "attributes-natural-language" 3.1.4.2 REQUIRED
- (naturalLanguage)
- "status-message" (text) 3.1.6.2 OPTIONAL
- "detailed-status-message" (text(MAX)) 3.1.6.3 OPTIONAL
-
-
- Group 2: Unsupported Attributes (see [ipp-mod] REQUIRED if
- section 3.1.7) unsupported
- attributes
-
-
- Group 3 to N:<the requested Subscription see below REQUIRED
- Attributes for each Subscription object in
- a separate group>
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 54]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-Attribute Notes:
-
-This operation is similar to the Get-Jobs operation (see [ipp-mod]). If
-the client wants any attributes returned, including the "subscription-
-id", it must include the attribute keyword name in the "requested-
-attributes" operation attribute. If the "requested-attributes.
-operation attribute is omitted, the Printer MUST respond as if the
-client supplied the value: 'subscription-id'.
-
-"job-id" (integer(1:MAX)) - If the client supplies this attribute, all
- of the Per-Job Subscription objects for the identified job are
- candidates for return. It this attribute is omitted, all of the
- Per-Printer Subscription objects are candidates for return.
-
-"limit" (integer(1:MAX)): The client OPTIONALLY supplies this
- attribute. The Printer object MUST support this attribute. It is
- an integer value that determines the maximum number of Subscription
- objects that a client will receive from the Printer even if "my-
- subscriptions" constrain which subscriptions are returned. The
- limit is a "stateless limit" in that if the value supplied by the
- client is 'N', then only the first 'N' Subscriptions are returned
- in the Get-Subscriptions Response. There is no mechanism to allow
- for the next 'M' Subscriptions after the first 'N' Subscriptions.
- If the client does not supply this attribute, the Printer object
- responds with all applicable Subscriptions.
-
-"requested-attributes" (1setOf keyword): The client OPTIONALLY supplies
- this attribute. The Printer object MUST support this attribute.
- It is a set of Subscription attribute names and/or the 'all'
- attribute group name in whose values the requester is interested.
- This set of attributes is returned for each Job object that is
- returned. If the client does not supply this attribute, the
- Printer MUST respond as if the client had supplied this attribute
- with the value: 'all'.
-
-"my-subscriptions" (boolean): The client OPTIONALLY supplies this
- attribute. The Printer object MUST support this attribute. It
- indicates whether Subscriptions from all users or just the
- Subscriptions submitted by the requesting user of this request MUST
- be returned by the Printer object. If the client does not supply
- this attribute, the Printer object MUST respond as if the client
- had supplied the attribute with a value of 'false', i.e.,
- Subscriptions from all users. The means for authenticating the
- requesting user and matching the Subscription objects is the same
- as for jobs as described in [ipp-mod] section 8.
-
-Groups 3 to N: Subscription Object Attributes: The Printer object
- responds with one set of Subscription Object Attributes for each
- returned Subscription object. The Printer object ignores (does not
- respond with) any requested attribute or value which is not
- supported or which is restricted by the security policy in force,
- including whether the requesting user is the user that created the
- Subscription object (subscribing user) or not (see [ipp-mod]
- section 8).
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 55]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-8.3.3 Renew-Subscription operation
-
-The REQUIRED Renew-Subscription operation permits a client to request
-the IPP Printer to extend the lease on a Subscription object instance.
-There is no way to renew a Per-Job subscription, since they are
-automatically canceled after the job completes and no longer has any
-documents, i.e., the job is no longer retained (see [ipp-mod] section
-4.3.7.2). If the requested subscription object is a Per-Job
-subscription, the Printer MUST grant an infinite lease by returning a 0
-value for the "notify-lease-expiration-time".
-
-Access Rights: The authenticated user (see [IPP-MOD] section 8.3)
-performing this operation MUST either be the owner of the Subscription
-object or have operator or administrator access rights for the Printer
-object (see [IPP-MOD] sections 1 and 8.5). Otherwise the IPP object
-MUST reject the operation and return: the 'client-error-forbidden',
-'client-error-not-authenticated', or 'client-error-not-authorized'
-status code as appropriate.
-
-Request:
-
- Group 1: Operation Attributes Referen client Printer
- ce MUST support
- [ipp- supply
- mod]
- "attributes-charset" (charset) 3.1.4.1 yes REQUIRED
- "attributes-natural-language" 3.1.4.1 yes REQUIRED
- (naturalLanguage)
- "printer-uri" (uri) 3.1.5 yes REQUIRED
- "requesting-user-name" 8.3 RECOMMEND RECOMMEND
- (name(MAX)) ED ED
-
-
- Group 2: Subscription Attributes Referen client Printer
- ce MUST support
- supply
- "subscription-id" 5.8 yes REQUIRED
- (integer(1:MAX))
- "notify-lease-time-requested" see no REQUIRED
- (integer(0:MAX)) below
-
-Response:
-
- Group 1: Operation Attributes Reference REQUIRED
- [ipp-mod] in
- response
- "status-code" (type2 enum) 3.1.6.1 REQUIRED
- "attributes-charset" (charset) 3.1.4.2 REQUIRED
- "attributes-natural-language" 3.1.4.2 REQUIRED
- (naturalLanguage)
- "status-message" (text(255)) 3.1.6.2 OPTIONAL
- "detailed-status-message" (text(MAX)) 3.1.6.3 OPTIONAL
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 56]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Group 2: Unsupported Attributes (see [ipp-mod] REQUIRED if
- section 3.1.7) unsupported
- attributes
-
-
- Group 3: Subscriptions Attributes Reference REQUIRED
- in
- response
- "notify-lease-expiration-time" 5.9 REQUIRED
- (integer(0:MAX))
- "notify-server-up-time" (integer(1:MAX)) 5.12 REQUIRED
-
-
-
-Attribute Notes:
-
-"notify-lease-time-requested" (integer(0:MAX) - the number of seconds
- requested for the Per-Printer subscription lease. Same as Create-
- Printer-Subscriptions (see section 8.2.1).
-
-"notify-lease-expiration-time" - the time in the future when the
- subscription will expire. Same as for the Create-Printer-
- Subscription operation (see section 8.2.1).
-
-"notify-server-up-time" - the Printer object MUST return this attribute
- which is an alias for the Printer's "printer-up-time" Printer
- Description attribute. The client subtracts this value from the
- "notify-lease-expiration-time" value returned in order to determine
- the number of second in the future that the subscription will
- expire (see further explanation in section 8.2.1).
-
-Note: There is no way to change any of the Subscription object
-attributes, except the "notify-lease-expiration-time" attribute (using
-the Renew-Subscription operation). In order to change other attributes,
-a client can create a new Subscription object and then use the Cancel-
-Subscription operation to cancel the old one (or do this in the other
-order, in case there is a limit on the number of Subscription object
-instances, as long as a short window with no Notifications is ok).
-
-Note: There is no need to renew a Per-Job Subscription, since it is
-effectively the time that the Job is active (see section 8.1).
-
-8.3.4 Cancel-Subscription operation
-
-The REQUIRED Cancel- Subscription operation allows a client to remove a
-Subscription object. No more Notifications are delivered for that
-Subscription. Once performed, there is no way to use that Subscription
-in the future. Subscription-ids should not be reused immediately, so
-that a stale reference situation is not created. Same as for Cancel-Job
-and job-ids.
-
-Access Rights: The authenticated user (see [IPP-MOD] section 8.3)
-performing this operation MUST either be the owner of the Subscription
-object or have operator or administrator access rights for the Printer
-object (see [IPP-MOD] sections 1 and 8.5). Otherwise the IPP object
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 57]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-MUST reject the operation and return: the 'client-error-forbidden',
-'client-error-not-authenticated', or 'client-error-not-authorized'
-status code as appropriate.
-
-Request:
- Group 1: Operation Attributes Referen client Printer
- ce MUST support
- [ipp- supply
- mod]
- "attributes-charset" (charset) 3.1.4.1 yes REQUIRED
- "attributes-natural-language" 3.1.4.1 yes REQUIRED
- (naturalLanguage)
- "printer-uri" (uri) 3.1.5 yes REQUIRED
- "requesting-user-name" 8.3 RECOMMEND RECOMMEND
- (name(MAX)) ED ED
-
-
- Group 2: Subscription Attributes Referen client Printer
- ce MUST support
- supply
- "subscription-id" 5.8 yes REQUIRED
- (integer(1:MAX))
-Response:
- Group 1: Operation Attributes Reference REQUIRED
- [ipp-mod] in
- response
- "status-code" (type2 enum) 3.1.6.1 REQUIRED
- "attributes-charset" (charset) 3.1.4.2 REQUIRED
- "attributes-natural-language" 3.1.4.2 REQUIRED
- (naturalLanguage)
- "status-message" (text(255)) 3.1.6.2 OPTIONAL
- "detailed-status-message" (text(MAX)) 3.1.6.3 OPTIONAL
-
-
- Group 2: Unsupported Attributes (see [ipp-mod] REQUIRED if
- section 3.1.7) unsupported
- attributes
-
-
-
-9 Comparison of Per-Job versus Per-Printer Subscriptions
-
-
-Per-Job and Per-Printer subscriptions are quite similar. Either type of
-subscription can subscribe to Job events, Printer events, or both. Both
-types of subscriptions can be queried using the Get-Subscriptions and
-Get-Subscription-Attributes operations and canceled using the Cancel-
-Subscription operation. Both types of subscriptions create Subscription
-objects which have the same attributes defined. However, there are some
-semantic differences between Per-Job subscriptions and Per-Printer
-subscriptions. A Per-Job Submission Subscription is established by the
-client when submitting a job and after creating the job using the
-Create-Job-Subscription operation by specifying the "job-id" of the job.
-A Per-Printer Subscription is established between a client and a
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 58]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-Printer using the Create-Printer-Subscription operation. Some specific
-differences are:
-
-1.A client usually creates a Per-Job subscription as part of the Job
- Creation operations (Create-Job, Print-Job, and Print-URI), rather
- than using the OPTIONAL Create-Job-Subscription operation, especially
- since Printer implementations NEED NOT support the Create-Job-
- Subscription operation, since it is OPTIONAL.
-
-2.For Per-Job subscriptions, the subscription is only valid while the
- job is "not-complete" (see sections 7.2 and 7.3) while for the Per-
- Printer subscriptions, the subscription is valid until the time (in
- seconds) that the Printer returned in the "notify-lease-expiration-
- time" operation attribute expires.
-
-3.Job Events in a Per-Job subscription apply only to "one job" (the Job
- created by the job creation operation or references by the Create-
- Job-Subscription operation) while Job Events in a Per-Printer
- subscription apply to ALL jobs contained in the IPP Printer object.
-
-
-10 Out of Band Values
-
-
-This section defines out-of-band values (see [ipp-mod] section 4.1) for
-use with attributes defined in this and other documents.
-
-
-10.1'none'
-
-This out-of-band value permits a client to indicate in a request that a
-specified attribute in the request MUST NOT be applied to the job.
-Specifically, this value overrides the Printer's "xxx-default" attribute
-value for the attribute, if one exists. This out-of-band value is
-needed since attributes that are of the 'collection', 'uri', and
-'mimeMediaType' type need a way for a client to specify that the Printer
-MUST NOT apply the value of an "xxx-default" attribute to the job. See
-[ipp-coll] for a complete specification, including encoding.
-
-
-11 Conformance Requirements
-
-
-It is OPTIONAL to implement this Event Notification specification. An
-implementation conforming to this specification MUST also meet the
-Conformance Requirements detailed in [IPP-MOD] section 5. If this Event
-Notification specification is implemented, IPP objects MUST support all
-of the REQUIRED object attributes as defined in this document in the
-indicated sections:
-
- 1.REQUIRED Subscription object attributes in section 5.
-
- 2.REQUIRED Printer Description object attributes in section 6.
-
- 3.REQUIRED attributes in Notification content in section 7.
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 59]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-In addition, the Printer MUST support the 'collection' attribute syntax
-(see [ipp-coll]).
-
-Extensions made to the events herein must be made such that new events
-or event attributes are backward compatible to clients who implemented
-early versions of this notification specification.
-
-If this Event Notification specification is implemented, the operations
-described in section 8 MUST be supported as described in Table 9:
-
- Table 9 - Conformance Requirements for Operations
-
- Attribute Conformance
- requirements
- "job-notify" (1setOf collection) in Job REQUIRED
- Creation operations (section 8.1.1)
- Create-Printer-Subscription (section 8.2.1) REQUIRED
- Create-Job-Subscription (section 8.1.2) OPTIONAL
- Get-Subscription-Attributes (section 8.3.1) REQUIRED
- Get-Subscriptions (section 8.3.2) REQUIRED
- Renew-Subscription (section 8.3.3) REQUIRED
- Cancel-Subscription (section 8.3.4) REQUIRED
-
-
-12 IANA Considerations
-
-
-IANA will be called on to register URL schemes for notification delivery
-methods, such as 'snmpnotify', for use in the "notification-recipient"
-attribute, using the same procedures outlined in [ipp-mod].
-
-
-13 Internationalization Considerations
-
-
-This IPP notification specification continues the internationalization
-of [ipp-mod] for attributes containing text strings and names. A
-subscribing client can specify a different natural language and charset
-for each Notification content delivered to a Notification Recipient.
-
-The Human Consumable Notification content is a 'text/plain; charset=utf-
-8' by default where the Notification Sender has localized the text
-message as requested by the subscriber for the intended Notification
-Recipient.
-
-
-14 Security Considerations
-
-
-By far the biggest security concern is the abuse of notification:
-sending unwanted notifications to third parties (i.e., spam). The
-problem is made worse by notification addresses that may be
-redistributed to multiple parties (e.g. mailing lists). There exist
-scenarios where third party notification is required (see Scenario #2
-and #3 in [ipp-not-req]). The fully secure solution would require
-active agreement of all recipients before sending out anything.
-However, requirement #9 in [ipp-req] (.There is no requirement for IPP
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 60]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-Printer receiving the print request to validate the identity of an event
-recipient.) argues against this. Certain systems may decide to disallow
-third party notifications (a traditional fax model).
-
-Clients submitting notification requests to the IPP Printer has the same
-security issues as submitting an IPP/1.1 print job request. The same
-mechanisms used by IPP/1.1 can therefore be used by the client
-notification submission. Operations that require authentication can use
-the HTTP authentication. Operations that require privacy can use the
-HTTP/TLS privacy.
-
-The notification access control model should be similar to the IPP
-access control model for Jobs. Creating a Per-Printer Notification
-Subscription object is associated with a user. Only the creator or an
-operator can cancel the subscription. The system may limit the listing
-of items to only those items owned by the user. Some subscriptions
-(e.g. those that have a lifetime longer than a job) can be done only by
-privileged users (users having operator and/or administrator access
-rights), if that is the authorization policy.
-
-The standard security concerns (delivery to the right user, privacy of
-content, tamper proof content) apply to the notification delivery. IPP
-should use the security mechanism of the delivery method used. Some
-delivery mechanisms are more secure than others. Therefore, sensitive
-notifications should use the delivery method that has the strongest
-security.
-
-
-15 Status Codes
-
-
-The following status codes are defined as extensions for notification:
-
-
-15.1'successful-ok-ignored-subscriptions' (0x0003)
-
-The number of subscriptions supplied in a Job Creation operation
-(Create-Job, Print-Job, Print-URI) exceeds either the limit of Per-Job
-subscriptions supported per job as specified by the Printer's "max-job-
-subscriptions-supported" attribute or some implementation-defined limit
-on the total number of Per-Job subscriptions for the Printer (if any).
-The Printer MUST accept the request with this status code, MUST return
-the "job-notify" attribute in the Unsupported Attributes Group with only
-the collection value(s) that represent the excess subscriptions that are
-being ignored, and MUST perform the Job Creation operation (see section
-8.1.1), since the job can still be printed.
-
-This status code is returned even if other job attributes are
-unsupported or in conflict. That is, if an IPP Printer finds a warning
-that would allow it to return 'successful-ok-ignored-subscriptions' and
-either 'successful-ok-ignored-or-substituted-attributes' and/or
-'successful-ok-conflicting-attributes', it must return 'successful-ok-
-ignored-subscriptions'. In other words, the precedence for returning
-success codes is: 'successful-ok-ignored-subscriptions', 'successful-ok-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 61]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-conflicting-attributes', and 'successful-ok-ignored-or-substituted-
-attributes'.
-
-
-15.2client-error-uri-notification-scheme-not-supported (0x0414)
-
-The scheme of the client-supplied URI in a "notify-recipient" operation
-attribute in a Create-Printer-Subscription or Create-Printer-
-Subscription operation is not supported. See [ipp-mod] section 3.1.7.
-
-There is no corresponding Per-Job subscription error for a Job Creation
-operation, since the Printer object MUST ignore any errors in the "job-
-notify" operation attribute, MUST return the "notify-recipient"
-attribute in the Unsupported Attributes Group, and perform the Job
-Creation operation (see section 8.1.1), since the job can still be
-printed.
-
-
-15.3client-error-too-many-subscriptions (0x0415)
-
-The bounded set of concurrent Per-Printer subscriptions supported by the
-Printer object would be exceeded if this Create-Printer-Subscription
-request were accepted or the bounded set of concurrent Per-Job
-subscriptions supported by the Printer object would be exceeded if this
-Create-Job-Subscriptions request were accepted.
-
-Note: There is no corresponding Per-Job subscription error on a Job
-Creation operation, since the Printer object MUST ignore any errors in
-the "job-notify" operation attribute and perform the Job Creation
-operation (see section 8.1.1), since the job can still be printed.
-
-
-15.4client-error-too-many-events (0x0416)
-
-The client supplied more events in the "notify-events" operation
-attribute in a Create-Job-Subscription or Create-Printer-Subscription
-operation than the Printer supports, as indicated in its "max-events-
-supported" attribute (see section 6.4).
-
-There is no corresponding Per-Job subscription error for a Job Creation
-operation, since the Printer object MUST ignore any errors in the "job-
-notify" operation attribute, MUST return the "notify-events" attribute
-in the Unsupported Attributes Group with only the excess events that are
-being ignored, and perform the Job Creation operation (see section
-8.1.1), since the job can still be printed.
-
-
-16 Addition attribute tag encodings
-
-
-The Subscription attributes tag and the Notification attributes tag are
-assigned the following delimiter tag values as extensions to the
-encoding defined in [ipp-pro]) for use in requests and responses to
-delimit Subscription object attribute Groups and Notification Content
-attribute Groups:
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 62]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- Tag Value (Hex) Delimiter
-
- 0x06 subscription-attributes-tag
- 0x07 notification-attributes-tag
-
-17 References
-
-[ipp-coll]
- deBry, R., , Hastings, T., Herriot, R., "Internet Printing
- Protocol/1.0 & 1.1: collection attribute syntax", <draft-ietf-ipp-
- collection-01.doc>, work in progress, February 22, 2000.
-
-[ipp-mod]
- deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
- "Internet Printing Protocol/1.1: Model and Semantics", < draft-
- ietf-ipp-model-v11-06.txt>, work in progress, March 1, 2000.
-
-[ipp-not-hist]
- deBry, R., Lewis, H., Hastings, T., "Internet Printing
- Protocol/1.1: Change History for IPP Notifications", <draft-ietf-
- ipp-not-change-history-00.txt>, work in progress, August 22, 1999.
-
-[ipp-method-indp]
- Parra, H., Hastings, T., "Internet Printing Protocol (IPP): The
- INDP Event Notification Delivery Method", <draft-ietf-indp-method-
- 00.txt>, work in progress, March 8, 2000.
-
-[ipp-method-ipp]
- Manros, C., Hastings, T., Herriot, R., Lewis, H., "Internet
- Printing Protocol (IPP): The 'ipp' Notification Delivery Polling
- Method", <draft-ietf-ipp-notify-poll-00.txt>, work in progress,
- March 8, 2000.
-
-[ipp-method-mailto]
- Holst, H. and Hastings, T., "Internet Printing Protocol (IPP): The
- 'mailto' Notification Delivery Method", <draft-ietf-ipp-notify-
- mailto-00.txt>, work in progress, March 9, 2000.
-
-[ipp-method-snmp]
- McDonald, I., Hastings, T., "Internet Printing Protocol (IPP):
- Notifications over SNMP", <draft-ietf-ipp-not-over-snmp-01.txt>,
- work in progress, December 1, 1999.
-
-[ipp-not-req]
- deBry, R., Lewis, H., Hastings, T., "Internet Printing
- Protocol/1.1: Requirements for IPP Notifications", <draft-ietf-ipp-
- not-03.txt>, work in progress, August 11, 1999.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", <draft-ietf-ipp-protocol-
- v11-05.txt>, work in progress, March 1, 2000.
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 63]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-[ipp-prog]
- Hastings, T., Bergman, R., Lewis, H., "Proposed Job Progress
- Attributes for IPP", <draft-ietf-ipp-job-prog.txt> work in
- progress, February 2, 2000.
-
-[ipp-set]
- Kugler, C., , Hastings, T., Herriot, R., Lewis, H, "Internet
- Printing Protocol (IPP): Job and Printer Set Operations", <draft-
- ietf-ipp-job-printer-set-ops-01.txt>, work in progress, March 8,
- 2000.
-
-[ipp-set2]
- Kugler, C., , Hastings, T., Lewis, H, "Internet Printing Protocol
- (IPP): Additional Operations, Set 2", <draft-ietf-ipp-ops-
- set2.txt>, work in progress, February 3, 2000.
-
-[RFC1866]
- Berners-Lee, T., Connolly, D., "Hypertext Markup Language - 2.0",
- RFC 1866, November 1995.
-
-[RFC2046]
- Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
- N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521,
- RFC1522, RFC1590), RFC 2046.
-
-[RFC2119]
- S. Bradner, "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119 , March 1997
-
-[RFC2279]
- F. Yergeau , "UTF-8, a transformation format of ISO 10646", RFC
- 2279. January 1998.
-
-[RFC2302]
- Parsons, G., et. al., "Tag Image File Format (TIFF) -
- image/tiff", RFC 2302, March 1998.
-
-[RFC2376]
- Whitehead, E., Murata, M., "XML Media Types", RFC 2376, July 1998.
-
-[RFC2566]
- deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April 1999.
-
-[RFC2567]
- Wright, D., "Design Goals for an Internet Printing Protocol", RFC
- 2567, April 1999.
-
-[RFC2568]
- Zilles, S., "Rationale for the Structure and Model and Protocol for
- the Internet Printing Protocol", RFC 2568, April 1999.
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 64]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-[RFC2569]
- Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
- LPD and IPP Protocols", RFC 2569, April 1999.
-
-
-18 Author's Addresses
-
- Scott A. Isaacson (Editor)
- Novell, Inc.
- 122 E 1700 S
- Provo, UT 84606
-
- Phone: 801-861-7366
- Fax: 801-861-2517
- e-mail: sisaacson@novell.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
- Roger deBry
- Utah Valley State College
- Orem, UT 84058
-
- Phone: (801) 222-8000
- EMail: debryro@uvsc.edu
-
- Jay Martin
- e-mail: jkm@underscore.com
-
- Michael Shepherd
- Xerox Corporation
- 800 Phillips Road MS 128-51E
- Webster, NY 14450
-
- Phone: 716-422-2338
- Fax: 716-265-8871
- e-mail: mshepherd@crt.xerox.com
-
- Ron Bergman (Editor)
- Hitachi Koki Imaging Solutions
- 1757 Tapo Canyon Road
- Simi Valley, CA 93063-3394
-
- Phone: 805-578-4421
- Fax: 805-578-4001
- Email: rbergma@hitachi-hkis.com
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 65]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-
-
-A. Appendix: Change History
-
-This section summarizes the changes to the document. Each sub-section
-is in reverse chronological order. Adding or removing ISSUES that don't
-change the document are not listed here.
-
-
-18.1Changes to the March 6, 2000 version to create the March 8, 2000
- version
-
-The following changes were made to the March 6, 2000 version to create
-the March 8, 2000 version based on the agreements reached on the mailing
-list:
-
-1.Changed the name of the SNMP delivery method from 'snmp' to
- 'snmpnotify', since the Notification Recipient isn't an SNMP agent.
-
-2.Clarified that an implementation with only a single value for
- persistent-jobs-supported (boolean) or persistent-subscriptions-
- supported (boolean) MAY make it settable to the single value or make
- it not-settable.
-
-
-18.2Changes to the February 2, 2000 version to create the March 6, 2000
- version
-
-The following changes were made to the February 2, 2000 version to
-create the March 6, 2000 version based on the agreements reached on the
-mailing list, at the February IPP WG meetings, and reflected in the
-minutes:
-
-1.Clarified that this extension is intended as an extension to IPP/1.0,
- IPP/1.1, and future versions.
-
-2.Allocated the operation-id 0x0016 to 0x001B values for the
- Notification operations defined in the document.
-
-3.Pre-pended the word "subscription-" on the front of the "request-id"
- Subscription object attribute to distinguish it from the "request-id"
- parameter that is sent in every request and response.
-
-4.Added the term "settable" for describing attributes that are not
- READ-ONLY.
-
-5.Added the term "Subscription Creation operation" to stand for any
- operation that can create a Subscription object: Job Creation
- operations (Create-Job, Print-Job, and Print-URI), Create-Job-
- Subscription, and Create-Printer-Subscription.
-
-6.Changed the "subscriber-user-name" (name(MAX)) Subscription object
- attribute from OPTIONAL to REQUIRED.
-
-7.Changed the name and semantics of "notify-printer-up-
- time(integer(1:MAX)) to notify-server-up-time so that it can be
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 66]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
- either the Printer's uptime or a Notification Delivery Service
- uptime.
-
-8.Added the 'ipp:', 'indp:', 'mailto:, and 'snmp:' notification
- delivery schemes to the definition of the "notify-recipients" to
- indicate possible schemes.
-
-9.Changed the name and semantics of "notify-text-format"
- (mimeMediaType) to "notify-format" so that it can be used to specify
- either Human Consumable or Machine Consumable formats where the
- implementation supports both. Clarified that this attribute controls
- whatever variable Notification Content that the implementation
- supports, which may be an attachment to the fixed content format or
- the contents of the "human-readable-report" (text(MAX)) attribute.
- Clarified that an implementation NEED NOT support all of its
- supported Notification Content formats with all of its supported
- delivery methods.
-
-10. Added 'text/xml', 'application/ipp', 'application/postscript', and
- 'image/tiff' and additional example MIME media types for "notify-
- format" (mimeMediaType).
-
-11. Clarified that the recommend way for a client to determine whether
- or not a Printer supports Per-Job Subscriptions is to query the
- Printer's "max-job-subscriptions-supported" attribute, since Create-
- Job-Subscriptions is an OPTIONAL operation.
-
-12. Clarified that the recommend way for a client to determine whether
- or not a Printer supports Per-Printer Subscriptions is to query the
- Printer's "operations-supported" attribute to see if the Create-
- Printer-Subscriptions operations is supported, since this is the
- usual way to determine a Printer's capabilities.
-
-13. Clarified that if "persistent-jobs-supported" (boolean) and
- "persistent-subscriptions-supported" (boolean) are settable, then
- setting them must affect whether or not jobs and subscriptions are
- persistent.
-
-14. Allowed delivery methods to send operations with or without a
- response, depending on the definition of the delivery method.
-
-15. Indicated that a deliver method definition is free to REQUIRE that
- the client supply the "subscriber-user-data" attribute.
-
-16. Required that the Printer support the "job-uri" operation attribute
- as a target, in addition to "printer-uri"&"job-id", i.e., keep
- consistent with all Job operations.
-
-17. Changed the 'none' out-of-band value to be a reference to the
- collection document [ipp-coll], since the use for it in this document
- is with the 'collection' attribute syntax.
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 67]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-18. Clarified that a conforming implementation MUST support the
- 'collection' attribute syntax, since that is required in Job Creation
- operations.
-
-19. Allocated the values to the new status codes defined in this
- document.
-
-20. Allocated the [ipp-pro] subscription-attributes-tag and
- notification-attributes-tag delimiter tags to delimit Subscription
- attributes and Notification Content attributes in requests and
- responses.
-
-21. Changed the 'server-error-too-many-subscriptions' and 'server-
- error-too-many-events' to be client errors, i.e., 'client-error-too-
- many-subscriptions' and 'client-error-too-many-events', since other
- errors of this type are client errors.
-
-
-
-
-18.3Changes to the October 14, 1999 version to create the February 2,
- 2000 version
-
-The following changes were made to the October 14, 1999 version to
-create the February 2, 2000 version based on the agreements reached at
-the October and December IPP WG meetings and reflected in the minutes:
-
-1.Added a Java Listener as an example of a Notification Recipient.
-
-2.Clarified the object relationships in section 4.1.
-
-3.Clarified how job events differ for Per-Job versus Per-Printer
- Subscriptions.
-
-4.Added the ability for the Machine Consumable form to contain a Human
- Readable "human-readable-report" (text) attribute so that both forms
- could be sent in the same Notification.
-
-5.Clarified that the 'none' value for notify-text-format
- (mimeMediaType) has to be out-of-band, not the text string 'none' as
- a mimeMediaType.
-
-6.Clarified that 'none' means send the Machine Consumable form without
- the "human-readable-report" (text) attribute, if it is defined.
-
-7.Clarified that Notification Recipients MUST be able to accept
- unrecognized attributes.
-
-8.Allowed the notification delivery method definition to be modeled as
- (1) a request with an operation code without a response, (2) a
- request with a operation code with a response or (3) a response with
- a status code.
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 68]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-9.Added "notify-text-format" (mimeMediaType) and "human-readable-
- report" (text(MAX)) to be able to be sent in a Notification content,
- if the notification delivery method document permits it.
-
-10. Added "job-k-octets" (integer(0:MAX)), "job-impressions"
- (integer(0:MAX)), and "job-media-sheets" (integer(0:MAX)) as OPTIONAL
- for Notification content for use in job-progress events to show the
- target values so that the Notification Recipient can show a
- thermometer.
-
-11. Added a Subscription Attributes group (and subscription-attributes
- tag) the Create-Job-Subscription and Create-Printer-Subscription
- requests and responses.
-
-12. Added the 'none' out-of-band value for use with "notify-text-
- format" (mimeMediaType) attribute.
-
-13. Changed the job progress attributes from using -2 to mean 'unknown'
- as in the PWG Job Monitoring MIB, to use the 'unknown' out-of-band
- value.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 69]
- Expires September 8, 2000
-
-
-
-
-INTERNET-DRAFT IPP: Event Notification March 8, 2000
-
-
-
-
-B. Appendix: Full Copyright Statement
-
-Copyright (C) The Internet Society (1998,1999,2000). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 70]
- Expires September 8, 2000
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT R. Herriot (editor)
+<draft-ietf-ipp-not-spec-06.txt> Xerox Corporation
+[Target Category: standards track] T. Hastings
+ Xerox Corporation
+ R. deBry
+ Utah Valley State College
+ S. Isaacson
+ Novell, Inc.
+ J. Martin
+ Underscore
+ M. Shepherd
+ Xerox Corporation
+ R. Bergman
+ Hitachi Koki Imaging Solutions
+ January 24, 2000
+ Internet Printing Protocol (IPP):
+ IPP Event Notification Specification
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [RFC2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+Abstract
+
+ This document describes an extension to the IPP/1.0, IPP/1.1, and
+ future versions. This extension allows a client to subscribe to
+ printing related Events. Subscriptions are modeled as Subscription
+ Objects. The Subscription Object specifies that when one of the
+ specified Event occurs, the Printer sends an asynchronous Event
+ Notification to the specified Notification Recipient via the
+ specified Delivery Method (i.e., protocol). A client associates
+ Subscription Objects with a particular Job by performing the Create-
+ Job-Subscriptions operation or by submitting a Job with subscription
+ information. A client associates Subscription Objects with the
+
+Herriot, et al. Expires July 24, 2001 [page 1]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Printer by performing a Create-Printer-Subscriptions operation. Four
+ other operations are defined for Subscription Objects: Get-
+ Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and
+ Cancel-Subscription.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 2]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+
+
+ The basic 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
+ Mapping between LPD and IPP Protocols [RFC2569]
+
+ The "Design Goals for an Internet Printing Protocol" document 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. It 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. A few OPTIONAL Operator operations
+ have been added to IPP/1.1.
+
+ The "Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol" document 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 "Internet Printing Protocol/1.1: Model and Semantics", describes
+ a simplified model with abstract objects, their attributes, and their
+ operations that are independent of encoding and transport. It
+ introduces a Printer object and a Job object. The Job object
+ optionally supports multiple documents per Job. It also addresses
+ security, internationalization, and directory issues.
+
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1. It defines the encoding rules
+ for a new Internet MIME media type called "application/ipp". This
+ document also defines the rules for transporting over HTTP a message
+ body whose Content-Type is "application/ipp". This document defines
+ a new scheme named 'ipp' for identifying IPP printers and jobs.
+ Finally, this document defines interoperability rules for supporting
+ IPP/1.0 clients.
+
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them 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
+
+
+Herriot, et al. Expires July 24, 2001 [page 3]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ processing requests is given, including error checking. Motivation
+ for some of the specification decisions is also included.
+
+ The "Mapping between LPD and IPP Protocols" document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 4]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+Table of Contents
+
+
+ 1 Introduction....................................................9
+ 1.1 Notification Overview........................................9
+
+ 2 Models for Notification........................................12
+ 2.1 Model for Notification (Simple Case)........................12
+ 2.2 Model for Notification with Cascading Printers..............12
+ 2.3 Distributed Model for Notification..........................12
+ 2.4 Extended Notification Recipient.............................13
+
+ 3 Terminology....................................................13
+ 3.1 Conformance Terminology.....................................13
+ 3.2 Other Terminology...........................................14
+
+ 4 Object Relationships...........................................16
+ 4.1 Printer and Per-Printer Subscription Objects................16
+ 4.2 Printer, Job and Per-Job Subscription Objects...............16
+
+ 5 Subscription Object............................................17
+ 5.1 Rules for Support of Subscription Template Attributes.......17
+ 5.2 Rules for Processing Subscription Template Attributes.......18
+ 5.3 Subscription Template Attributes............................22
+ 5.3.1 notify-recipient-uri (uri)..................................23
+ 5.3.2 notify-events (1setOf type2 keyword)........................24
+ 5.3.2.1 Standard Values for Subscribed Events ...................24
+ 5.3.2.1.1 No Events.............................................25
+ 5.3.2.1.2 Subscribed Printer Events.............................25
+ 5.3.2.1.3 Subscribed Job Events.................................26
+ 5.3.2.2 Rules for Matching of Subscribed Events .................28
+ 5.3.2.2.1 Rules for Matching of Printer Events..................28
+ 5.3.2.2.2 Rules for Matching of Job Events......................28
+ 5.3.2.2.3 Special Cases for Matching Rules......................29
+ 5.3.3 notify-attributes (1setOf type2 keyword)....................30
+ 5.3.4 notify-user-data (octetString(63))..........................31
+ 5.3.5 notify-charset (charset)....................................31
+ 5.3.6 notify-natural-language (naturalLanguage)...................32
+ 5.3.7 notify-lease-duration (integer(0:67108863)).................32
+ 5.3.8 notify-time-interval (integer(0:MAX)).......................33
+ 5.4 Subscription Description Attributes.........................35
+ 5.4.1 notify-subscription-id (integer (1:MAX))...................35
+ 5.4.2 notify-sequence-number (integer (0:MAX))....................36
+ 5.4.3 notify-lease-expiration-time (integer(0:MAX))...............36
+ 5.4.4 notify-printer-up-time (integer(1:MAX)).....................37
+ 5.4.5 notify-printer-uri (uri)....................................37
+ 5.4.6 notify-job-id (integer(1:MAX))..............................38
+ 5.4.7 notify-subscriber-user-name (name(MAX)).....................38
+
+ 6 Printer Description Attributes Related to Notification.........38
+
+
+Herriot, et al. Expires July 24, 2001 [page 5]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ 6.1 printer-state-change-time (integer(1:MAX))..................39
+ 6.2 printer-state-change-date-time (dateTime)...................39
+
+ 7 New Values for Existing Printer Description Attributes.........40
+ 7.1 operations-supported (1setOf type2 enum)....................40
+
+ 8 Attributes Only in Event Notifications.........................40
+ 8.1 notify-subscribed-event (type2 keyword).....................40
+ 8.2 notify-text (text(MAX)).....................................41
+
+ 9 Event Notification Content.....................................41
+ 9.1 Content of Machine Consumable Event Notifications...........43
+ 9.1.1 Event Notification Content Common to All Events.............44
+ 9.1.2 Additional Event Notification Content for Job Events........45
+ 9.1.3 Additional Event Notification Content for Printer Events....46
+ 9.2 Content of Human Consumable Event Notification..............46
+ 9.2.1 Event Notification Content Common to All Events.............47
+ 9.2.2 Additional Event Notification Content for Job Events........49
+ 9.2.3 Additional Event Notification Content for Printer Events....50
+
+ 10 Delivery Methods...............................................51
+
+ 11 Operations for Notification....................................53
+ 11.1 Subscription Creation Operations............................53
+ 11.1.1 Create-Job-Subscriptions Operation .......................54
+ 11.1.1.1 Create-Job-Subscriptions Request ........................54
+ 11.1.1.2 Create-Job-Subscriptions Response .......................55
+ 11.1.2 Create-Printer-Subscriptions operation ...................56
+ 11.1.2.1 Create-Printer-Subscriptions Request ....................57
+ 11.1.2.2 Create-Printer-Subscriptions Response ...................57
+ 11.1.3 Job Creation Operation - Extensions for Notification .....57
+ 11.1.3.1 Job Creation Request ....................................58
+ 11.1.3.2 Job Creation Response ...................................58
+ 11.2 Other Operations............................................59
+ 11.2.1 Validate-Job Operation - Extensions for Notification .....59
+ 11.2.2 Get-Printer-Attributes - Extensions for Notification .....60
+ 11.2.3 Get-Subscription-Attributes operation ....................60
+ 11.2.3.1 Get-Subscription-Attributes Request .....................61
+ 11.2.3.2 Get-Subscription-Attributes Response ....................62
+ 11.2.4 Get-Subscriptions operation ..............................63
+ 11.2.4.1 Get-Subscriptions Request ...............................63
+ 11.2.4.2 Get-Subscriptions Response ..............................64
+ 11.2.5 Renew-Subscription operation .............................65
+ 11.2.5.1 Renew-Subscription Request ..............................66
+ 11.2.5.2 Renew-Subscription Response .............................66
+ 11.2.6 Cancel-Subscription operation ............................67
+ 11.2.6.1 Cancel-Subscription Request .............................68
+ 11.2.6.2 Cancel-Subscription Response ............................69
+
+ 12 Conformance Requirements.......................................69
+
+
+Herriot, et al. Expires July 24, 2001 [page 6]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ 13 IANA Considerations............................................70
+ 13.1 Attribute Registrations.....................................70
+ 13.2 Keyword Attribute Value Registrations.......................71
+ 13.3 Operation Registrations.....................................71
+ 13.4 Status code Registrations...................................72
+ 13.5 Attribute Group tag Registrations...........................72
+ 13.6 Format for Event Notification Delivery Method Registration
+ proposals.........................................................73
+ 13.7 Format and Requirements for IPP Delivery Method Registration
+ Proposals.........................................................73
+
+ 14 Internationalization Considerations............................73
+
+ 15 Security Considerations........................................74
+
+ 16 Status Codes...................................................74
+ 16.1 successful-ok-ignored-subscriptions (0x0003)................75
+ 16.2 client-error-ignored-all-subscriptions (0x0414).............75
+
+ 17 Status Codes in Subscription Attributes Groups.................75
+ 17.1 client-error-uri-scheme-not-supported (0x040C)..............75
+ 17.2 client-error-too-many-subscriptions (0x0415)................76
+ 17.3 successful-ok-too-many-events (0x0005)......................76
+ 17.4 successful-ok-ignored-or-substituted-attributes (0x0001)....76
+
+ 18 Encodings of Additional Attribute Tags.........................76
+
+ 19 References.....................................................76
+
+ 20 Author's Addresses.............................................78
+
+ A. Appendix - Model for Notification with Cascading Printers......79
+
+ B. Appendix - Distributed Model for Notification..................80
+
+ C. Appendix - Extended Notification Recipient.....................81
+
+ D. Appendix - Details about Conformance Terminology...............82
+
+ E. Appendix - Object Model for Notification.......................83
+ E.1 Appendix - Object relationships.............................84
+ E.2 Printer Object and Per-Printer Subscription Objects.........85
+ E.3 Job Object and Per-Job Subscription Objects.................85
+
+ F. Appendix - Per-Job versus Per-Printer Subscription Objects.....85
+
+ G. Appendix: Full Copyright Statement.............................86
+
+Tables
+ Table 1 - Subscription Template Attributes........................23
+
+
+Herriot, et al. Expires July 24, 2001 [page 7]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Table 2 - Subscription Description Attributes.....................35
+ Table 3 - Printer Description Attributes Associated with Notification
+ ..............................................................39
+ Table 4 - Operation-id assignments................................40
+ Table 5 - Attributes in Event Notification Content................44
+ Table 6 - Additional Event Notification Content for Job Events....45
+ Table 7 - Combinations of Events and Subscribed Events for "job-
+ impressions-completed" ........................................46
+ Table 8 - Additional Event Notification Content for Printer Events46
+ Table 9 - Printer Name in Event Notification Content..............48
+ Table 10 - Event Name in Event Notification Content...............48
+ Table 11 - Event Time in Event Notification Content...............49
+ Table 12 - Job Name in Event Notification Content.................49
+ Table 13 - Job State in Event Notification Content................50
+ Table 14 - Printer State in Event Notification Content............51
+ Table 15 - Information about the Delivery Method..................52
+ Table 16 - Conformance Requirements for Operations................70
+Figures
+ Figure 1 - Model for Notification.................................12
+ Figure 2 - Model for Notification with Cascading Printers.........80
+ Figure 3 - Opaque Use of a Notification Service Transparent to the
+ Client ........................................................81
+ Figure 4 - Use of an Extended Notification Recipient transparent to
+ the Printer ...................................................82
+ Figure 5 - Object Model for Notification..........................84
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 8]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+1 Introduction
+
+ This IPP notification specification is an extension to IPP/1.0
+ [RFC2568, RFC2569] and IPP/1.1 [RFC2911, RFC2910]. This document in
+ combination with the following documents is intended to meet the
+ notification requirements described in [ipp-not-req]:
+
+ Internet Printing Protocol (IPP): "Job Progress Attributes"
+ [ipp-prog]
+ One or more Delivery Method Documents registered with IANA (see
+ section 13).
+
+ Note: this document does not define any Delivery Methods, but it does
+ define the rules for conformance for Delivery Method Documents.
+
+ Refer to the Table of Contents for the layout of this document.
+
+1.1 Notification Overview
+
+ This document defines operations that a client can perform in order
+ to create Subscription Objects in a Printer and carry out other
+ operations on them. A Subscription Object represents a Subscription
+ abstraction. The Subscription Object specifies that when one of the
+ specified Events occurs, the Printer sends an asynchronous Event
+ Notification to the specified Notification Recipient via the
+ specified Delivery Method (i.e., protocol).
+
+ When a client (called a Subscribing Client) performs an operation
+ that creates a Subscription Object, the operation contains one or
+ more Subscription Template Attributes Groups. Each such group holds
+ information used by the Printer to initialize a newly created
+ Subscription Object. The Printer creates one Subscription Object for
+ each Subscription Template Attributes Group in the operation. This
+ group is like the Job Template Attributes group defined in [RFC2911].
+ The following is an example of the information included in a
+ Subscription Template Attributes Group (see section 5 for details on
+ the Subscription Object attributes):
+
+ 1.The names of Subscribed Events that are of interest to the
+ Notification Recipient.
+ 2.The address (URL) of one Notification Recipient.
+ 3.The Delivery Method (i.e., the protocol) which the Printer uses
+ to send the Event Notification.
+ 4.Some opaque data that the Printer sends to the Notification
+ Recipient in the Event Notification. The Notification Recipient
+ might use this opaque data as a forwarding address for the Event
+ Notification.
+ 5.The charset to use in text fields within an Event Notification
+ 6.The natural language to use in the text fields of the Event
+ Notification
+
+
+Herriot, et al. Expires July 24, 2001 [page 9]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ 7.The requested lease time in seconds for the Subscription Object
+ An operation that creates a Subscription Object is called a
+ Subscription Creation Operation. These operations include the
+ following operations (see section 11.1 for further details):
+
+ . Job Creation operation: When a client performs such an operation
+ (Print-Job, Print-URI, and Create-Job), a client can include
+ zero or more Subscription Template Attributes Groups in the
+ request. The Printer creates one Subscription Object for each
+ Subscription Template Attributes Group in the request, and the
+ Printer associates each such Subscription Object with the newly
+ created Job. This document extends these operations' definitions
+ in [RFC2911] by adding Subscription Template Attributes Groups
+ in the request and Subscription Attributes Groups in the
+ response.
+
+ . Create-Job-Subscriptions operation: A client can include one or
+ more Subscription Template Attributes Groups in the request.
+ The Printer creates one Subscription Object for each
+ Subscription Template Attributes Group and associates each with
+ the job that is the target of this operation.
+
+ . Create-Printer-Subscriptions operation: A client can include one
+ or more Subscription Template Attributes Groups in the request.
+ The Printer creates one Subscription Object for each
+ Subscription Template Attributes Group and associates each with
+ the Printer that is the target of this operation.
+
+ For each of the above operations:
+
+ . the Printer associates a Subscription Object with the Printer or
+ a specific Job. When a Subscription Object is associated with a
+ Job Object, it is called a Per-Job Subscription Object. When a
+ Subscription Object is associated with a Printer Object, it is
+ called a Per-Printer Subscription Object.
+
+ . the response contains one Subscription Attributes Group for each
+ Subscription Template Attributes Group in the request and in the
+ same order. When the Printer successfully creates a Subscription
+ Object, its corresponding Subscription Attributes Group contains
+ the "notify-subscription-id" attribute. This attribute uniquely
+ identifies the Subscription Object and is analogous to a "job-
+ id" for a Job object. Some operations described below use the
+ "notify-subscription-id" to identify the target Subscription
+ Object.
+
+ This document defines the following additional operations (see
+ section 11.2 for further details):
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 10]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ . Validate-Job operation: When a client performs this operation, a
+ client can include zero or more Subscription Template Attributes
+ Groups in the request. The Printer determines if it could
+ create one Subscription Object for each Subscription Template
+ Attributes Group in the request. This document extends this
+ operation's definition in [RFC2911] by adding Subscription
+ Template Attributes Groups in the request and Subscription
+ Attributes Groups in the response.
+
+ . Get-Subscription-Attributes operation: This operation allows a
+ client to obtain the specified attributes of a target
+ Subscription Object.
+
+ . Get-Subscriptions operation: This operation allows a client to
+ obtain the specified attributes of all Subscription Objects
+ associated with the Printer or a specified Job.
+
+ . Renew-Subscription operation: This operation renews the lease on
+ the target Per-Printer Subscription Object before it expires. A
+ newly created Per-Printer Subscription Object receives an
+ initial lease. It is the duty of the client to use this
+ operation frequently enough to preserve a Per-Printer
+ Subscription Object. The Printer deletes a Per-Printer
+ Subscription Object when its lease expires. A Per-Job
+ Subscription Object last exactly as long as its associated Job
+ Object and thus doesn't have a lease.
+
+ . Cancel-Subscription operation: This operation cancels the lease
+ on the specified Per-Printer Subscription Object and thereby
+ deletes the Subscription Object.
+
+ When an Event occurs, the Printer finds all Subscription Objects
+ listening for the Event (see section 9 for details on finding such
+ Subscription Objects). For each such Subscription Object, the
+ Printer:
+
+ a)generates an Event Notification with information specified in
+ section 9, AND
+
+ b)either:
+
+ i) delivers the Event Notification using the Delivery Method
+ and target address identified in the Subscription Object's
+ "notify-recipient-uri" attribute if the Delivery Method is a
+ "push", OR
+
+ ii) saves Event Notification for a time period defined by the
+ Delivery Method if the Delivery Method is a "pull", i.e., the
+ Notification Recipient is expected to fetch the Event
+ Notifications.
+
+
+Herriot, et al. Expires July 24, 2001 [page 11]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+2 Models for Notification
+
+2.1 Model for Notification (Simple Case)
+
+ As part of a Subscription Creation Operation, an IPP Printer (i.e.,
+ located in an output device or a server) creates one or more
+ Subscription Objects. In a Subscription Creation Operation, the
+ client specifies the Notification Recipient to which the Printer is
+ to deliver Event Notifications. A Notification Recipient can be the
+ Subscribing Client or a third party.
+
+ Figure 1 shows the Notification model for a simple Client-Printer
+ relationship.
+
+
+ embedded printer:
+ output device or server
+ PDA, desktop, or server +---------------+
+ +--------+ | ########### |
+ | client |-----Subscription ---------># Printer # |
+ +--------+ Creation Operation | # Object # |
+ +------------+ | #####|##### |
+ |Notification| +-------|-------+
+ |Recipient |<----IPP Event Notifications----+
+ +------------+ (Job and/or Printer Events)
+
+ Figure 1 - Model for Notification
+
+2.2 Model for Notification with Cascading Printers
+
+ With this model, there is an intervening Print server between the
+ human user and the Printer in the output device. If the Printer in
+ the output device generates an Event, the system can be configured to
+ send Event Notification either
+
+ . directly to the Notification Recipient specified by the
+ Subscribing Client or
+
+ . via the Print Server to the Notification Recipient specified by
+ the Subscribing Client.
+
+ See Appendix A for more details.
+
+2.3 Distributed Model for Notification
+
+ The preceding sections (2.1 and 2.2) assume that the Notification
+ software resides in the same device or Server box as the rest of the
+ Printer software. In many implementations, the assumption is correct.
+ However, the Notification model also permits a distributed
+ implementation.
+
+
+Herriot, et al. Expires July 24, 2001 [page 12]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ For example, the software that supports both Subscription Creation
+ Operations and sending of Event Notifications could be on hardware
+ that is separate from the output device. To make this work, there
+ must be a symbiotic relationship between the output device software
+ and the remote Notification software. Without the remote Notification
+ software, the output device software is not a complete Printer.
+
+ The term "Printer" in this document includes the software on the
+ output device or server box as well as Notification software that is
+ local to or remote from the output device.
+
+ Appendix B describes this example in detail.
+
+2.4 Extended Notification Recipient
+
+ The model allows for an extended Notification Recipient that is
+ itself a Notification service that forwards each Event Notification
+ to another recipient. The client contacts this Notification Recipient
+ to arrange for forwarding by means outside the scope of this
+ document. The Printer need not be aware that the Notification
+ Recipient forwards Event Notifications.
+
+ Appendix C describes this example in detail.
+
+
+3 Terminology
+
+ This section defines terminology used throughout this document. Other
+ terminology is defined in [RFC2911].
+
+3.1 Conformance Terminology
+
+ Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+ NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+ conformance to this specification. These terms are defined in
+ [RFC2911 section 13.1 on conformance terminology, most of which is
+ taken from RFC 2119 [RFC2119]. See Appendix D for complete details.
+
+ Note: a feature that is OPTIONAL in this document becomes REQUIRED if
+ the Printer implements a Delivery Method that REQUIRES the feature
+
+ READ-ONLY - an adjective used in an attribute definition to indicate
+ that an IPP Printer MUST NOT allow the attribute's value to be
+ modified with the Set-Job-Attributes or Set-Printer-Attributes
+ operations (see [ipp-set]). Note: there is no Set-Subscription
+ operation so this term is not used for Subscription object
+ attributes.
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 13]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+3.2 Other Terminology
+
+ Administrator - A human user who establishes policy for and
+ configures the print system.
+
+ Operator - A human user who carries out the policy established by the
+ Administrator and controls the day to day running of the print
+ system.
+
+ IPP Client (or client) - The software component (PDA, desktop, or
+ server) that performs an IPP operation directed at an IPP Printer
+ (located in a server or output device).
+
+ Job Creation operation - One of the operations that creates a Job
+ object: Print-Job, Print-URI and Create-Job. The Validate-Job
+ operation is not a Job Creation operation because no Job object is
+ created. Therefore, when a statement also applies to the
+ Validate-Job operation, it is mentioned explicitly.
+
+ Event - some occurrence (either expected or unexpected) within the
+ printing system of a change of state, condition, or configuration
+ of a Job or Printer object. An Event occurs only at one instant in
+ time and does not span the time the physical Event takes place.
+ For example, jam-occurred and jam-cleared are two distinct,
+ instantaneous Events, even though the jam may last for a while.
+
+ Job Event - an Event caused by some change in a particular job on the
+ Printer, e.g., job-completed.
+
+ Printer Event - an Event caused by some change in the Printer that is
+ not specific to a job, e.g., printer-state-changed.
+
+ Subscribed Event - an Event that the Subscribing Client expresses
+ interest in by making it a value of the "notify-events" attribute
+ on a Subscription Object.
+
+ Subscribed Job Event - a Subscribed Event that is a Job Event.
+
+ Subscribed Printer Event - a Subscribed Event that is a Printer
+ Event.
+
+ Event Notification - the information about an Event that the Printer
+ sends when an Event occurs.
+
+ Notification Recipient - the entity to which the Printer sends an
+ Event Notification.
+
+ Delivery Method - the mechanism by which the Printer delivers the
+ Event Notification, e.g., via email or via SNMP.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 14]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Delivery Method Document - a document, separate from this document,
+ that defines a Delivery Method.
+
+ Compound Event Notification - two or more Event Notifications that a
+ Printer sends together as a single entity. The Delivery Method
+ Document specifies whether the Delivery Method supports Compound
+ Event Notifications.
+
+ Subscription Object - An object containing a set of attributes that
+ indicate: the Notification Recipient, the Delivery Method, the
+ Subscribed Events that cause the Printer to send an Event
+ Notification, and the information to send in an Event
+ Notification.
+
+ Per-Job Subscription Object - A Subscription Object that is
+ associated with a single Job. The Create-Job-Subscriptions
+ operation and Job Creation operations create such an object.
+
+ Per-Printer Subscription Object - A Subscription Object that is
+ associated with the Printer as a whole. The Create-Printer-
+ Subscriptions operation creates such an object.
+
+ Subscribing Client - The client that creates the Subscription Object.
+
+ Subscription Creation Operation - An operation that creates a
+ Subscription Object: Job Creation operations, Create-Job-
+ Subscriptions operation, and Create-Printer-Subscriptions
+ operation. In the context of a Job Creation operation, a
+ Subscription Creation Operation is the part of the Job Creation
+ operation that creates a Subscription object.
+
+ Subscription Creation Request - The request portion of a
+ Subscription Creation Operation.
+
+ Subscription Template Attributes - Subscription Object attributes
+ that a client can supply in a Subscription Creation Operation and
+ associated Printer Object attributes that specify supported and
+ default values for the Subscription Object attributes.
+
+ Subscription Description Attributes - Subscription Object attributes
+ that a Printer supplies during a Subscription Creation Operation.
+
+ Subscription Template Attributes Group - The attributes group in a
+ request that contains Subscription Object attributes that are
+ Subscription Template Attributes.
+
+ Subscription Attributes Group - The attributes group in a response
+ that contains Subscription Object attributes.
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 15]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Human Consumable Event Notification - localized text for human
+ consumption only. There is no standardized format and thus
+ programs should not try to parse this text.
+
+ Machine Consumable Event Notification - bytes for program
+ consumption. The bytes are formatted according to the Delivery
+ Method document.
+
+ Printer - the software that supports an output device or print server
+ (see IPP/1.1 [RFC2911] which uses the terms Printer and Printer
+ object interchangeably). This document extends the IPP/1.1 Printer
+ definition to include the software that implements Subscription
+ Creation Operations and the sending of Event Notifications, even
+ if the software for such a Printer would be distributed across a
+ network (see section 2.3).
+
+ Notification - when not in the phrases 'Event Notification' and
+ 'Notification Recipient' - the concepts of this specification,
+ i.e., Events, Subscription Objects, and Event Notifications.
+
+
+4 Object Relationships
+
+ This section defines the object relationships between the Printer,
+ Job, and Subscription Objects. It does not define the
+ implementation. For an illustration of these relationships, see
+ Appendix E.
+
+4.1 Printer and Per-Printer Subscription Objects
+
+ 1.A Printer object can be associated with zero or more Per-Printer
+ Subscription Objects.
+
+ 2.Each Per-Printer Subscription Object is associated with exactly
+ one Printer object.
+
+4.2 Printer, Job and Per-Job Subscription Objects
+
+ 1.A Printer object is associated with zero or more Job objects.
+
+ 2.Each Job object is associated with exactly one Printer object.
+
+ 3.A Job object is associated with zero or more Per-Job Subscription
+ Objects.
+
+ 4.Each Per-Job Subscription Object is associated with exactly one
+ Job object.
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 16]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+5 Subscription Object
+
+ A Subscribing Client creates a Subscription Object with a
+ Subscription Creation Operation in order to indicate its interest in
+ certain Events. See section 11 for a description of these operations.
+ When an Event occurs, the Subscription Object specifies to the
+ Printer where to send Event Notifications, how to send them and what
+ to put in them. See section 9 for details on the contents of an Event
+ Notification.
+
+ Using the IPP Job Template attributes as a model (see [RFC2911]
+ section 4.2), the attributes of a Subscription Object are divided
+ into two categories: Subscription Template Attributes and
+ Subscription Description Attributes.
+
+ Subscription Template attributes are, in turn, like the Job Template
+ attributes, divided into
+
+ 1.Subscription Object attributes that a client can supply in a
+ Subscription Creation Request and
+
+ 2.their associated Printer Object attributes that specify
+ supported and default values for the Subscription Object
+ attributes
+
+ The remainder of this section specifies general rules for
+ Subscription Template Attributes and describes each attribute in a
+ Subscription Object.
+
+5.1 Rules for Support of Subscription Template Attributes
+
+ Subscription Template Attributes are fundamental to the Notification
+ model described in this specification. The client supplies these
+ attributes in Subscription Creation Operations and the Printer uses
+ these attributes to populate a newly created Subscription Object.
+
+ Subscription Objects attributes that are Subscription Template
+ Attributes conform to the following rules:
+
+ 1.Each attribute's name starts with the prefix string "notify-"
+ and this document calls such attributes "notify-xxx".
+
+ 2.For each "notify-xxx" Subscription Object attribute defined in
+ column 1 of Table 1 in section 5.3, Table 1 specifies
+ corresponding Printer attributes: "notify-xxx-default", "notify-
+ xxx-supported", "yyy-supported" and "notify-max-xxx-supported"
+ defined in column 2 of Table 1. Note "xxx" stands for the same
+ string in each case and "yyy" stands for some other string.
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 17]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ 3.If a Printer supports "notify-xxx" in column 1 of Table 1, then
+ the Printer MUST support all associated attributes specified in
+ column 2 of Table 1. For example, Table 1 shows that if the
+ Printer supports "notify-events", it MUST support "notify-
+ events-default", "notify-events-supported" and "notify-max-
+ events-supported".
+
+ 4.If a Printer does not support "notify-xxx" in column 1 of Table
+ 1, then the Printer MUST NOT support any associated "notify-yyy"
+ attributes specified in column 2 of Table 1. For example, Table
+ 1 shows that if the Printer doesn't support "notify-events", it
+ MUST NOT support "notify-events-default", "notify-events-
+ supported" and "notify-max-events-supported". Note this rule
+ does not apply to attributes whose names do not start with the
+ string "notify-" and are thus defined in another object and used
+ by other attributes.
+
+ 5.Most "notify-xxx" attributes have a corresponding "yyy-
+ supported" attribute that specifies the supported values for
+ "notify-xxx". Column 2 of Table 1 specifies the name of each
+ "yyy-supported" attribute. The naming rules of IPP/1.1 (see
+ [RFC2911]) are used when "yyy-supported" is "notify-xxx-
+ supported".
+
+ 6.Some "notify-xxx" attributes have a corresponding "notify-xxx-
+ default" attribute that specifies the value for "notify-xxx" if
+ the client does not supply it. Column 2 of Table 1 specifies the
+ name of each "notify-xxx-default" attribute. The naming rules of
+ IPP/1.1 (see [RFC2911]) are used.
+
+ If a client wishes to present an end user with a list of supported
+ values from which to choose, the client SHOULD query the Printer for
+ its supported value attributes. The client SHOULD also query the
+ default value attributes. If the client then limits selectable
+ values to only those values that are supported, the client can
+ guarantee that the values supplied by the client in the create
+ request all fall within the set of supported values at the Printer.
+ When querying the Printer, the client MAY enumerate each attribute by
+ name in the Get-Printer-Attributes Request, or the client MAY just
+ supply the 'subscription-template' group name in order to get the
+ complete set of supported attributes (both supported and default
+ attributes).
+
+5.2 Rules for Processing Subscription Template Attributes
+
+ This section defines a detailed set of rules that a Printer follows
+ when it processes Subscription Template Attributes in a Subscription
+ Creation Request. These rules for are similar to the rules for
+ processing Operation attributes in [RFC2911]. That is, the Printer
+ may or may not support an attribute and a client may or may not
+
+
+Herriot, et al. Expires July 24, 2001 [page 18]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ supply the attribute. Some combinations of these cases are OK. Others
+ return warnings or errors, and perhaps a list of unsupported
+ attributes.
+
+ A Printer MUST implement the following behavior for processing
+ Subscription Template Attributes in a Subscription Creation Request:
+
+ 1.If a client supplies a "notify-xxx" attribute from column 1 of
+ Table 1 and the Printer supports it and its value, the Printer
+ MUST populate the attribute on the created Subscription Object.
+
+ 2.If a client supplies a "notify-xxx" attribute from column 1 of
+ Table 1 and the Printer doesn't support it or its value, the
+ Printer MUST NOT populate the attribute on the created
+ Subscription Object with it. The Printer MUST do one of the
+ following:
+
+ a) If the value of the "notify-xxx" attribute is unsupported, the
+ Printer MUST return the attribute with its value in the
+ Subscription Attributes Group of the response.
+
+ b) If "notify-xxx" is an unsupported attribute, the Printer MUST
+ return the attribute in the Subscription Attributes Group of the
+ response with the 'unsupported' out-of-band value.
+
+ Note: The rules of this step are the same as for Unsupported
+ Attributes [RFC2911] section 3.1.7. except that the unsupported
+ attributes are returned in the Subscription Attributes Group
+ rather than the Unsupported Attributes Group because Subscription
+ Creation Operations can create more than one Subscription Object).
+
+ 3.If a client is REQUIRED to supply a "notify-xxx" attribute from
+ column 1 of Table 1 and the Printer doesn't support the supplied
+ value, the Printer MUST NOT create a Subscription Object. The
+ rules for Unsupported Attributes in step #2 still apply.
+
+ 4.If a client does not supply a "notify-xxx" attribute from column 1
+ of Table 1 and the attribute is REQUIRED for the client to supply,
+ the Printer MUST reject the Subscription Creation Operation
+ (including Job Creation operations) without creating a
+ Subscription Object, and MUST return in the response:
+
+ c) the status code 'client-error-bad-request' AND
+
+ d) no Subscription Attribute Groups.
+
+ 5.If a client does not supply a "notify-xxx" attribute from column 1
+ of Table 1 that is OPTIONAL for the client to supply, and column 2
+ of Table 1 either:
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 19]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ a) specifies a "notify-xxx-default" attribute, the Printer MUST
+ behave as if the client had supplied the "notify-xxx-default"
+ attribute (see step #1) and populate the Subscription object
+ with the value of the "notify-xxx-default" attribute as part of
+ the Subscription Creation operation (unlike Job Template
+ attributes where the Printer does not populate the Job object
+ with defaults - see [RFC2911]) OR
+
+ b) does not specify a "notify-xxx-default" attribute, the Printer
+ MUST populate the "notify-xxx" attribute on the Subscription
+ Object according to the definition of the "notify-xxx" attribute
+ in a section 5.3. For some attributes, the "notify-xxx" is
+ populated with the value of some other attribute, and for
+ others, the "notify-xxx" is NOT populated on the Subscription
+ object at all.
+
+ 6.A Printer MUST create a Subscription Object for each Subscription
+ Template Attributes group in a request unless the Printer:
+
+ a) encounters some attributes in a Subscription Template Attributes
+ Group that require the Printer not to create the Subscription
+ Object OR
+
+ b) would create a Per-Job Subscription Object when it doesn't have
+ space for another Per-Job Subscription Object OR
+
+ c) would create a Per-Printer Subscription Object when it doesn't
+ have space for another Per-Printer Subscription Object.
+
+ 7.A response MUST contain one Subscription Attributes Group for each
+ Subscription Template Attributes Group in the request (and in the
+ same order) whether the Printer creates a Subscription Object from
+ the Subscription Template Attributes Group or not. However, the
+ attributes in each Subscription Attributes Group can be in any
+ order.
+
+ 8.The Printer MUST populate each Subscription Attributes Group of
+ the response such that each contains:
+
+ a) the "notify-subscription-id" attribute (see section 0), if and
+ only if the Printer creates a Subscription Object.
+
+ b) the "notify-lease-duration" attribute (see section 5.3.7), if
+ and only if the Printer creates a Per-Printer Subscription
+ Object. The value of this attribute is the value of the
+ Subscription Object's "notify-lease-duration" attribute. This
+ value MAY be different from the client-supplied value (see
+ section 5.3.7). If a client supplies this attribute in the
+ creation of a Per-Job Subscription Object, it MUST appear in
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 20]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ this group with the out-of-band value 'unsupported' to indicate
+ that the Printer doesn't support it in this context.
+
+ c) all of the unsupported Subscription Template Attributes from
+ step #2. Note, they are not returned in the Unsupported
+ Attributes Group in order to separate the unsupported attributes
+ for each Subscription Object.
+
+ d) the "notify-status-code" attribute if the Printer does not
+ create the Subscription Object or if there are unsupported
+ attributes from step #2. The possible values of the "notify-
+ status-code" attribute are shown below (see section 17 for more
+ details). The Printer returns the first value in the list below
+ that describes the status.
+
+ 'client-error-uri-scheme-not-supported': the Subscription
+ Object was not created because the scheme of the "notify-
+ recipient-uri" attribute is not supported. See section 17.1
+ for more details about this status code. See step #3 in
+ this section for the case that causes this error, and the
+ resulting step #6a) that causes the Printer not to create
+ the Subscription Object.
+
+ 'client-error-too-many-subscriptions': the Subscription
+ Object was not created because the Printer has no space for
+ additional Subscription Objects. The client SHOULD try
+ again later. See section 17.2 for more details about this
+ status code. See steps #6b) and #6c) in this section for
+ the cases that causes this error.
+
+ 'successful-ok-too-many-events': the Subscription Object
+ was created without the "notify-events" values included in
+ this Subscription Attributes Group because the "notify-
+ events" attribute contains too many values. See section
+ 17.3 for more details about this status code. See step #2
+ in this section and section 5.3.2 for the cases that cause
+ this status code.
+
+ 'successful-ok-ignored-or-substituted-attributes' : the
+ Subscription Object was created but some supplied
+ Subscription Template Attributes are unsupported. These
+ unsupported attributes are also in the Subscription
+ Attributes Group. See section 17.4 for more details about
+ this status code. See step #2 in this section for the cases
+ that cause this status code.
+
+ 9.The Printer MUST validate all Subscription Template Attributes and
+ MUST return all unsupported attributes and values in the
+ corresponding Subscription Attributes Group of the response (see
+ step #2) unless it determines that it could not create additional
+
+
+Herriot, et al. Expires July 24, 2001 [page 21]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Subscription Objects because of condition #6b) or condition #6c).
+ Then, the Printer NEED NOT validate these additional Subscription
+ Template Attributes and the client MUST NOT expect to find
+ unsupported attributes from step #2 in such additional
+ Subscription Attribute Groups.
+
+5.3 Subscription Template Attributes
+
+ This section contains the Subscription Template Attributes defined
+ for the Subscription and Printer objects.
+
+ Table 1 below shows the Subscription Template Attributes and has two
+ columns:
+
+ . Attribute in Subscription Object: the name and attribute syntax
+ of each Subscription Object Attribute that is a Subscription
+ Template Attribute
+
+ . Default and Supported Printer Attributes: the default attribute
+ and supported Printer attributes that are associated with the
+ attribute in column 1.
+
+ A Printer MUST support all attributes in Table 1 below except for
+ "notify-attributes" (and "notify-attributes-supported"). A client
+ MUST supply "notify-recipient-uri" and MAY omit any of the rest of
+ the attributes in column 1 of Table 1 in a Subscription Creation
+ Request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 22]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Table 1 - Subscription Template Attributes
+
+
+
+ Attribute in Subscription Default and Supported Printer
+ Object Attributes
+
+
+ notify-recipient-uri (uri) notify-schemes-supported (1setOf
+ uriScheme)
+
+ notify-events (1setOf type2 notify-events-default (1setOf type2
+ keyword) keyword)
+ notify-events-supported (1setOf type2
+ keyword)
+ notify-max-events-supported
+ (integer(2:MAX))
+
+ notify-attributes (1setOf notify-attributes-supported (1setOf
+ type2 keyword) type2 keyword)
+
+ notify-user-data
+ (octetString(63))
+
+ notify-charset (charset) charset-supported (1setOf charset)
+
+ notify-natural-languages generated-natural-language-supported
+ (naturalLanguage) (1setOf naturalLanguage)
+
+ notify-lease-duration notify-lease-duration-default
+ (integer(0:MAX)) (integer(0:67108863))
+ notify-lease-duration-supported
+ (1setOf (integer(0: 67108863) |
+ rangeOfInteger(0:67108863)))
+
+ notify-time-interval
+ (integer(0:MAX))
+
+
+
+5.3.1 notify-recipient-uri (uri)
+
+ This attribute's value is a URL, which is a special case of a URI.
+ Its value consists of a scheme and an address. The address specifies
+ the Notification Recipient and the scheme specifies the Delivery
+ Method for each Event Notification associated with this Subscription
+ Object.
+
+ A Printer MUST support this attribute.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 23]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ A client MUST supply this attribute in Subscription Creation
+ Operation. Thus there is no need for a default attribute.
+
+ The "notify-schemes-supported (1setOf uriScheme)" attribute MUST
+ specify the schemes supported for this attribute. Note: According to
+ [RFC1738] the ":" terminates the scheme and so is not part of the
+ scheme. Therefore, values of this attribute do not include the ":".
+
+ If the client supplies an unsupported scheme in the value of this
+ attribute, then the Printer MUST not create the Subscription Object
+ and MUST return the "notify-status-code" attribute with the 'client-
+ error-uri-scheme-not-supported' value in the Subscription Attributes
+ Group in the response.
+
+ The Printer MUST treat the address part of this attribute as opaque.
+
+5.3.2 notify-events (1setOf type2 keyword)
+
+ This attribute contains a set of Subscribed Events. When an Event
+ occurs and it "matches" a value of this attribute, the Printer sends
+ an Event Notification using information in the Subscription Object.
+ The details of "matching" are described subsection 5.3.2.2.
+
+ A Printer MUST support this attribute.
+
+ A client MAY supply this attribute in a Subscription Creation
+ Operation. If the client does not supply this attribute in
+ Subscription Creation Operation, the Printer MUST populate this
+ attribute on the Subscription Object with its "notify-events-default"
+ attribute value.
+
+ Each value of this attribute on a Subscription Object MUST be one of
+ the values of the "notify-events-supported (1setOf type2 keyword)"
+ attribute.
+
+ The number of values of this attribute MUST NOT exceed the value of
+ the "notify-max-events-supported" attribute. A Printer MUST support
+ at least 2 values per Subscription Object. If the number of values
+ supplied by a client in a Subscription Creation Operation exceeds the
+ value of this attribute, the Printer MUST treat extra values as
+ unsupported values and MUST use the value of 'successful-ok-too-many-
+ events' for the "notify-status-code" attribute in the Subscription
+ Attributes Group of the response.
+
+5.3.2.1 Standard Values for Subscribed Events
+
+ Each value of this attribute is a keyword and it specifies a
+ Subscribed Event that represents certain changes. Some keywords
+ represent a subset of changes of another keyword, e.g., 'job-
+ completed' is an Event value which is a sub-value of 'job-state-
+
+
+Herriot, et al. Expires July 24, 2001 [page 24]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ change'. See section 5.3.2.2 for the case where this attribute
+ contains both a value and a sub-value.
+
+ The values in this section are divided into three categories: No
+ Events, Job Events and Printer Events.
+
+ A Printer MUST support the Events indicated as "REQUIRED" and MAY
+ support the Events indicated as "OPTIONAL".
+
+5.3.2.1.1 No Events
+
+ The standard and only keyword value for No Events is:
+
+ 'none': REQUIRED - no Event Notifications for any Events. As the
+ sole value of "notify-events-supported", this value means that the
+ Printer does not support the sending of Event Notifications. As
+ the sole value of "notify-events-default", this value means that a
+ client MUST specify the "notify-events" attribute in order for a
+ Subscription Creation Operation to succeed. If the Printer
+ receives this value as the sole value of a Subscription Creation
+ Operation, it does not create a Subscription Object. If a Printer
+ receives this value with other values of a Subscription Creation
+ Operation, the Printer MUST treat this value as an unsupported
+ value.
+
+5.3.2.1.2 Subscribed Printer Events
+
+ The standard keyword values for Subscribed Printer Events are:
+
+ 'printer-state-changed': REQUIRED - the Printer changed state from
+ any state to any other state. Specifically, the value of the
+ Printer's "printer-state", "printer-state-reasons" or "printer-is-
+ accepting-jobs" attributes changed.
+
+ This Subscribed Event value has the following sub-values:
+ 'printer-restarted' and 'printer-shutdown'. A client can listen
+ for any of these sub-values if it doesn't want to listen to all
+ printer-state changes:
+
+ 'printer-restarted': OPTIONAL - when the printer is powered
+ up .
+
+ 'printer-shutdown': OPTIONAL - when the device is being
+ powered down .
+
+ 'printer-stopped: REQUIRED - when the printer stops printing,
+ i.e. the value of the "printer-state" Printer attribute
+ becomes 'stopped'.
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 25]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ 'printer-config-changed': OPTIONAL - when the configuration of a
+ Printer has changed, i.e., the value of the "printer-message-from-
+ operator" or any "configuration" Printer attribute has changed. A
+ "configuration" Printer attribute is an attribute which can change
+ value because of some human interaction either direct or indirect,
+ and which is not covered by one of the other Events in this
+ section. Examples of "configuration" Printer attributes are any of
+ the Job Template attributes, such as "xxx-supported", "xxx-ready"
+ and "xxx-default". Often, such a change is the result of a client
+ performing a Set-Printer-Attributes operation (see [ipp-set]) on
+ the Printer. The client has to perform a Get-Printer-Attributes to
+ find out the new values of these changed attributes. This Event
+ is useful for GUI clients and drivers to update the available
+ printer capabilities to the user.
+
+ This Event value has the following sub-values: 'printer-media-
+ changed' and 'printer-finishings-changed'. A client can listen for
+ any of these sub-values if it doesn't want to listen to all
+ printer-configuration changes:
+
+ 'printer-media-changed': OPTIONAL - when the media loaded on
+ a printer has been changed, i.e., the "media-ready"
+ attribute has changed. This Event includes two cases: an
+ input tray that goes empty and an input tray that receives
+ additional media of the same type or of a different type.
+ The client must check the "media-ready" Printer attribute
+ (see [RFC2911] section 4.2.11) separately to find out what
+ changed.
+
+ 'printer-finishings-changed': OPTIONAL - when the finisher on
+ a printer has been changed, i.e., the "finishings-ready"
+ attribute has changed. This Event includes two cases: a
+ finisher that goes empty and a finisher that is refilled
+ (even if it is not full). The client must check the
+ "finishings-ready" Printer attribute separately to find out
+ what changed.
+
+ 'printer-queue-order-changed': OPTIONAL - the order of jobs in the
+ Printer's queue has changed, so that an application that is
+ monitoring the queue can perform a Get-Jobs operation to determine
+ the new order. This Event does not include when a job enters the
+ queue (the 'job-created' Event covers that) and does not include
+ when a job leaves the queue (the 'job-completed' Event covers
+ that).
+
+5.3.2.1.3 Subscribed Job Events
+
+ The standard keyword values for Subscribed Job Events are:
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 26]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ 'job-state-changed': REQUIRED - the job has changed from any state
+ to any other state. Specifically, the Printer sends this Event
+ whenever the value of the "job-state" attribute or "job-state-
+ reasons" attribute changes. When a Job is removed from the Job
+ History (see [RFC2911] 4.3.7.1), no Event is generated.
+
+ This Event value has the following sub-values: 'job-created',
+ 'job-completed' and 'job-stopped'. A client can listen for any of
+ these sub-values if it doesn't want to listen to all 'job-state
+ changes'.
+
+ 'job-created': REQUIRED - the Printer has accepted a Job
+ Creation operation and the job's "time-at-creation"
+ attribute value is set (see [RFC2911] section 4.3.14.1).
+ The Printer puts the job in the 'pending', 'pending-held'
+ or 'processing' states..
+
+ 'job-completed': REQUIRED - the job has reached one of the
+ completed states, i.e., the value of the job's "job-state"
+ attribute has changed to: 'completed', 'aborted', or
+ 'canceled'. The Job's "time-at-completed" and "date-time-
+ at-completed" (if supported) attributes are set (see
+ [RFC2911] section 4.3.14).. The Printer also sends this
+ Event when a Job is removed with the Purge-Job operation.
+ In this case, the Event Notification MUST report the 'job-
+ state' as 'canceled'.
+
+ 'job-stopped: OPTIONAL - when the job stops printing, i.e.
+ the value of the "job-state" Job attribute becomes
+ 'processing-stopped'.
+
+ 'job-config-changed': OPTIONAL - when the configuration of a job has
+ changed, i.e., the value of the "job-message-from-operator" or any
+ of the "configuration" Job attributes have changed. A
+ "configuration" Job attribute is an attribute that can change
+ value because of some human interaction either direct or indirect.
+ Examples of "configuration" Job attributes are any of the job
+ template attributes and the "job-name" attribute. Often, such a
+ change is the result of the user or the Operator performing a Set-
+ Job-Attributes operation (see [ipp-set]) on the Job object. The
+ client performs a Get-Job-Attributes to find out the new values of
+ the changed attributes. This Event is useful for GUI clients and
+ drivers to update the job information to the user.
+
+ 'job-progress': OPTIONAL - when the Printer has completed Printing a
+ sheet. See the separate [ipp-prog] specification for additional
+ attributes that a Printer MAY send in an Event Notification caused
+ by this Event. The "notify-time-interval" attribute affects this
+ Event by causing the Printer NOT to send an Event Notification
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 27]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ every time a 'job-progress' Events occurs. See section 5.3.8 for
+ full details.
+
+5.3.2.2 Rules for Matching of Subscribed Events
+
+ When an Event occurs, the Printer MUST find each Subscription object
+ whose "notify-events" attribute "matches" the Event. The rules for
+ "matching" of Subscribed Events are described separately for Printer
+ Events and for Job Events. This section also describes some special
+ cases.
+
+5.3.2.2.1 Rules for Matching of Printer Events
+
+ Suppose that the Printer causes Printer Event E to occur. For each
+ Per-Job or Per-Printer Subscription S in the Printer, if E equals a
+ value of this attribute in S or E is a sub-value of a value of this
+ attribute in S, the Printer MUST generate an Event Notification.
+
+ Consider the example. There are three Subscription Objects each with
+ the Subscribed Printer Event 'printer-state-changed'. Subscription
+ Object A is a Per-Printer Subscription Object. Subscription Object B
+ is a Per-Job Subscription Object for Job 1, and Subscription Object C
+ is a Per-Job Subscription Object for Job 2. When the Printer enters
+ the 'stopped' state, the Printer sends an Event Notification to the
+ Notification Recipients of Subscription Objects A, B, and C because
+ this is a Printer Event. Note if Job 1 has already completed, the
+ Printer would not send an Event Notification for its Subscription
+ Object.
+
+5.3.2.2.2 Rules for Matching of Job Events
+
+ Suppose that Job J causes Job Event E to occur.
+
+ 1.For each Per-Printer Subscription S in the Printer, if E equals
+ a value of this attribute in S or E is a sub-value of a value of
+ this attribute in S, the Printer MUST generate an Event
+ Notification.
+
+ 2.For each Per-Job Subscription S associated with Job J, if E
+ equals a value of this attribute in S or E is a sub-value of a
+ value of this attribute in S, the Printer MUST generate an Event
+ Notification.
+
+ 3.For each Per-Job Subscription S that is NOT associated Job J, if
+ E equals a value of this attribute in S or E is a sub-value of a
+ value of this attribute in, the Printer MUST NOT generate an
+ Event Notification from S.
+
+ Consider the example: There are three Subscription Objects listening
+ for the Job Event 'job-completed'. Subscription Object A is a Per-
+
+
+Herriot, et al. Expires July 24, 2001 [page 28]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Printer Subscription Object. Subscription Object B is a Per-Job
+ Subscription Object for Job 1, and Subscription Object C is a Per-Job
+ Subscription Object for Job 2. In addition, Per-Printer Subscription
+ Object D is listening for the Job Event 'job-state-changed'. When Job
+ 1 completes, the Printer sends an Event Notification to the
+ Notification Recipient of Subscription Object A (because it is Per-
+ Printer) and Subscription Object B because it is a Per-Job
+ Subscription Object associated with the Job generating the Event.
+ The Printer also sends an Event Notification to the Notification
+ Recipient of Subscription Object D because 'job-completed' is a sub-
+ value of 'job-state-changed' - the value that Subscription Object D
+ is listening for. The Printer does not send an Event Notification to
+ the Notification Recipients of Subscription Object C because it is a
+ Per-Job Subscription Object associated with some Job other than the
+ Job generating the Event.
+
+5.3.2.2.3 Special Cases for Matching Rules
+
+ This section contains rule for special cases.
+
+ If an Event matches Subscribed Events in two different Subscription
+ Objects and the Printer would send two identical Event Notifications
+ (except for the "notify-subscription-id" attribute) to the same
+ Notification Recipient using the same Delivery Method, the Printer
+ MUST send both Event Notifications. That is, the Printer MUST NOT try
+ to consolidate seemingly identical Event Notifications that occur in
+ separate Subscription objects. Incidentally, the Printer MUST NOT
+ reject Subscription Creation Operations that would create this
+ scenario.
+
+ If an Event matches two values of this "notify-events" attribute in a
+ single Subscription object (e.g., a value and its sub-value), a
+ Printer MAY send one Event Notification for each matched value in the
+ Subscription Object or it MAY send only one Event Notification per
+ Subscription Object. The rules in sections 5.3.2.2.1 and 5.3.2.2.2
+ are purposefully ambiguous about the number of Event Notification
+ sent when Event E matches two or more values in a Subscription
+ Object.
+
+ Consider the example: There are two Per-Printer Subscription Objects
+ when a Job completes. Subscription Object A has the Subscribed Job
+ Event 'job-state-changed'. Subscription Object B has the Subscribed
+ Job Events 'job-state-changed' and 'job-completed'. The Printer sends
+ an Event Notification to the Notification Recipient of Subscription
+ Object A with the value of 'job-state-changed' for the "notify-
+ subscribing-event" attribute. The Printer sends either one or two
+ Event Notifications to the Notification Recipient of Subscription
+ Object B, depending on implementation. If it sends two Event
+ Notifications, one has the value of 'job-state-changed' for the
+ "notify-subscribing-event" attribute, and the other has the value of
+
+
+Herriot, et al. Expires July 24, 2001 [page 29]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ 'job-completed' for the "notify-subscribing-event" attribute. If it
+ sends one Event Notification, it has the value of either 'job-state-
+ changed' or 'job-completed' for the "notify-subscribing-event"
+ attribute, depending on implementation. The algorithm for choosing
+ such a value is implementation dependent.
+
+5.3.3 notify-attributes (1setOf type2 keyword)
+
+ This attribute contains a set of attribute names. When a Printer
+ sends a Machine Consumable Event Notification, it includes a fixed
+ set of attributes (see section 9.1). If this attribute is present and
+ the Event Notification is Machine Consumable, the Printer also
+ includes the attributes specified by this attribute.
+
+ A Printer MAY support this attribute.
+
+ A client MAY supply this attribute in a Subscription Creation
+ Operation. If the client does not supply this attribute in
+ Subscription Creation Operation or the Printer does not support this
+ attribute, the Subscription Object MUST NOT contain the "notify-
+ attributes" attribute. There is no "notify-attributes-default"
+ attribute.
+
+ Each keyword value of this attribute on a Subscription Object MUST be
+ a value of the "notify-attributes-supported (1setOf type2 keyword)"
+ attribute. The "notify-attributes-supported" MAY contain any Printer
+ attribute, Job attribute or Subscription Object attribute that the
+ Printer supports in an Event Notification. It MUST NOT contain any
+ of the attributes in Section 9.1 that a Printer automatically puts in
+ an Event Notification; it would be redundant. If a client supplies an
+ attribute in Section 9.1, the Printer MUST treat it as an unsupported
+ attribute value of the "notify-attributes" attribute.
+
+ The following rules apply to each keyword value N of the "notify-
+ attributes" attribute: If the value N names:
+
+ a)a Subscription attribute, the Printer MUST use the attribute N in
+ the Subscription Object that is being used to generate the Event
+ Notification.
+
+ b)a Job attribute and the Printer is generating an Event
+ Notification from a Per-Job Subscription Object S, the Printer
+ MUST use the attribute N in the Job object associated with S.
+
+ c)a Job attribute and the Printer is generating an Event
+ Notification from a Per-Printer Subscription Object and the Event
+ is:
+
+ . a Job Event, the Printer MUST use the attribute N in the Job
+ object that caused the Event.
+
+
+Herriot, et al. Expires July 24, 2001 [page 30]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ . a Printer Event, the Printer MUST use the attribute N in the
+ active Job.
+
+ If a Printer supports this attribute and a Subscription Object
+ contains this attribute and the Delivery Method generates a Machine
+ Consumable Event Notification, the Printer MUST include in each Event
+ Notification:
+
+ a)the attributes specified in section 9.1 and
+
+ b)each attribute named by this attribute.
+
+ The Printer MUST NOT use this attribute to generate a Human
+ Consumable Event Notification.
+
+5.3.4 notify-user-data (octetString(63))
+
+ This attribute contains opaque data that some Delivery Methods
+ include in each Machine Consumable Event Notification. The opaque
+ data might contain, for example:
+
+ . the identity of the Subscriber
+
+ . a path or index to some Subscriber information
+
+ . a key that identifies to the Notification Recipient the ultimate
+ recipient of the Event Notification
+
+ . the id for a Notification Recipient that had previously
+ registered with an Instant Messaging Service
+
+ A Printer MUST support this attribute.
+
+ A client MAY supply this attribute in a Subscription Creation
+ Operation. If the client does not supply this attribute in
+ Subscription Creation Operation, the Subscription Object MUST NOT
+ contain the "notify-user-data" attribute. There is no "notify-user-
+ data-default" attribute.
+
+ There is no "user-data-supported" attribute. Rather, any octetString
+ whose length does not exceed 63 octets is a supported value. If the
+ length exceeds 63 octets, the Printer MUST treat it as an unsupported
+ value.
+
+5.3.5 notify-charset (charset)
+
+ This attribute specifies the charset to be used in the Event
+ Notification content sent to the Notification Recipient, whether the
+ Event Notification content is Machine Consumable or Human Consumable.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 31]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ A Printer MUST support this attribute.
+
+ A client MAY supply this attribute in a Subscription Creation
+ Operation. If the client does not supply this attribute in
+ Subscription Creation Operation or supplies an unsupported value, the
+ Printer MUST populate this attribute in the Subscription Object with
+ the value of the "attributes-charset" operation attribute, which is a
+ REQUIRED attribute in all IPP requests (see [RFC2911]). If the value
+ of the "attributes-charset" attribute is unsupported, the Printer
+ MUST populate this attribute in the Subscription Object with the
+ value of the Printer's "charset-configured" attribute. There is no
+ "notify-charset-default" attribute.
+
+ The value of this attribute on a Subscription Object MUST be a value
+ of the "charset-supported (1setOf charset)" attribute.
+
+5.3.6 notify-natural-language (naturalLanguage)
+
+ This attribute specifies the natural language to be used in any human
+ consumable text in the Event Notification content sent to the
+ Notification Recipient, whether the Event Notification content is
+ Machine Consumable or Human Consumable.
+
+ A Printer MUST support this attribute.
+
+ A client MAY supply this attribute in a Subscription Creation
+ Operation. If the client does not supply this attribute in
+ Subscription Creation Operation or supplies an unsupported value, the
+ Printer MUST populate this attribute in the Subscription Object with
+ the value of the "attributes-natural-language" operation attribute,
+ which is a REQUIRED attribute in all IPP requests (see [RFC2911]). If
+ the value of the "attributes-natural-language" attribute is
+ unsupported, the Printer MUST populate this attribute in the
+ Subscription Object with the value of the Printer's "natural-
+ language-configured" attribute. There is no "notify-natural-language-
+ default" attribute.
+
+ The value of this attribute on a Subscription Object MUST be a value
+ of the "generated-natural-language-supported (1setOf type2
+ naturalLanguage)" attribute.
+
+5.3.7 notify-lease-duration (integer(0:67108863))
+
+ This attribute specifies the duration of the lease (in seconds)
+ associated with the Per-Printer Subscription Object at the time the
+ Subscription Object was created or the lease was renewed. The
+ duration of the lease is infinite if the value is 0, i.e., the lease
+ never expires.
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 32]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ This attribute is not present on a Per-Job Subscription Object
+ because the Subscription Object lasts exactly as long as the
+ associated Job object. See section 5.4.3 on "notify-lease-expiration-
+ time (integer(0:MAX))" for more details.
+
+ A Printer MUST support this attribute.
+
+ For a Subscription Object Creation operation of a Per-Job
+ Subscription Object, the client MUST NOT supply this attribute. If
+ the client does supply this attribute, the Printer MUST treat it as
+ an unsupported attribute.
+
+ For a Subscription Creation Operation of a Per-Printer Subscription
+ Object or a Renew-Subscription operation, a client MAY supply this
+ attribute. If the client does not supply this attribute, the Printer
+ MUST populate this attribute with its "notify-lease-duration-default"
+ (0:67108863) attribute value. If the client supplies this attribute
+ with an unsupported value, the Printer MUST populate this attribute
+ with a supported value, and this value SHOULD be as close as possible
+ to the value requested by the client. Note: this rule implies that a
+ Printer doesn't assign the value of 0 (infinite) unless the client
+ requests it.
+
+ After the Printer has populated this attribute with a supported
+ value, the value represents the "granted duration" of the lease in
+ seconds and the Printer sets the value of the Subscription Object's
+ "notify-lease-expiration-time" attribute as specified in section
+ 5.4.3.
+
+ The value of this attribute on a Subscription Object MUST be a value
+ of the "notify-lease-duration-supported" (1setOf (integer(0:67108863)
+ | rangeOfInteger(0:67108863))) attribute.
+
+ A Printer MAY require authentication in order to return the value of
+ 0 (the lease never expires) as one of the values of "notify-lease-
+ duration-supported", and to allow 0 as a value of the "notify-lease-
+ duration" attribute.
+
+ Note: The maximum value 67,108,863 is 2 raised to the 26 power minus
+ 1 and is about 2 years in seconds. The value is considerably less
+ than MAX so that there is virtually no chance of an overflow when it
+ is added to "printer-up-time" to produce "notify-lease-expiration-
+ time".
+
+5.3.8 notify-time-interval (integer(0:MAX))
+
+ The 'job-progress' Event occurs each time that a Printer completes a
+ sheet. Some Notification Recipients do not want to receive an Event
+ Notification every time this Event occurs. This attribute allows a
+ Subscribing Client to request how often it wants to receive Event
+
+
+Herriot, et al. Expires July 24, 2001 [page 33]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Notifications for 'job-progress' Events. The value of this attribute
+ MAY be any nonnegative integer (0,MAX) indicating the minimum number
+ of seconds between 'job-progress' Event Notifications.
+
+ The Printer MUST support this attribute if and only if the Printer
+ supports the 'job-progress' Event.
+
+ A client MAY supply this attribute in a Subscription Creation
+ Operation. If the client does not supply this attribute, the Printer
+ MUST not populate this attribute on the Subscription Object. There is
+ no "notify-time-interval-default" attribute.
+
+ There is no "notify-time-interval-supported" attribute.
+
+ If the 'job-progress' Event occurs and a Subscription Object contains
+ the 'job-progress' Event as a value of the 'notify-events' attribute,
+ there are two cases to consider:
+
+ 1.This attribute is not present on the Subscription Object or has
+ the value of 0. The Printer MUST generate and send an Event
+ Notification (as is the case with other Events).
+
+ 2.This attribute is present with a nonzero value of N:
+
+ a)If the Printer has not sent an Event Notification for the 'job-
+ progress' Event for the associated Subscription Object within
+ the past N seconds, the Printer MUST send an Event Notification
+ for the Event that just occurred. Note when the Printer
+ completes the first page of a Job, this rule implies that the
+ Printer sends an Event Notification for a Per-Job Subscription
+ Objects.
+
+ b)Otherwise, the Printer MUST NOT generate or send an Event
+ Notification for the associated Subscription Object. The Printer
+ MUST NOT increase the value of the "notify-sequence-number"
+ Subscription Object attribute (i.e., the sequence of values of
+ the "notify-sequence-number" attribute counts the Event
+ Notifications that the Printer sent and not the Events that do
+ not cause an Event Notification to be sent).
+
+ It is RECOMMENDED that a Subscribing Client use this attribute when
+ it subscribes to the 'job-progress' Event, and that the value be
+ sufficiently large to limit the frequency with which the Printer
+ sends Event Notifications requests.
+
+ This attribute MUST NOT effect any Events other than 'job-progress'.
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 34]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+5.4 Subscription Description Attributes
+
+ Subscription Description Attributes are those attributes that a
+ Printer adds to a Subscription Object at the time of its creation.
+
+ A Printer MUST support all attributes in this Table 2.
+
+ A client MUST NOT supply the attributes in Table 2 in a Subscription
+ Template Attributes Group of a Subscription Creation Operation. If
+ the client supplies them, the Printer MUST NOT set them and MUST
+ treat them as unsupported attributes. There are no corresponding
+ default or supported attributes.
+
+
+ Table 2 - Subscription Description Attributes
+
+
+
+ Subscription Object attributes:
+
+
+ notify-subscription-id (integer(1:MAX))
+
+ notify-sequence-number (integer(0:MAX))
+
+ notify-lease-expiration-time (integer(0:MAX))
+
+ notify-printer-up-time (integer(1:MAX))
+
+ notify-printer-uri (uri)
+
+ notify-job-id (integer(1:MAX))
+
+ notify-subscriber-user-name (name(MAX))
+
+
+
+5.4.1 notify-subscription-id (integer (1:MAX))
+
+ This attribute identifies a Subscription Object instance with a
+ number that is unique within the context of the Printer. The Printer
+ generates this value at the time it creates the Subscription Object.
+
+ A Printer MUST support this attribute.
+
+ The Printer SHOULD NOT assign the value of this attribute
+ sequentially as it creates Subscription Objects. Sequential
+ assignment makes it easy for rogue clients to guess the value of this
+ attribute on other Subscription Objects.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 35]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ The Printer SHOULD avoid re-using recent values of this attribute
+ during continuous operation of the Printer as well as across power
+ cycles. Then a Subscribing Client is unlikely to find that a stale
+ reference accesses a new Subscription Object.
+
+ The 0 value is not permitted in order to allow for compatibility with
+ "job-id" and with SNMP index values, which also cannot be 0.
+
+5.4.2 notify-sequence-number (integer (0:MAX))
+
+ The value of this attribute indicates the number of times that the
+ Printer has generated and attempted to send an Event Notification.
+ When an Event Notification contains this attribute, the Notification
+ Recipient can determine whether it missed some Event Notifications
+ (i.e., numbers skipped) or received duplicates (i.e., same number
+ twice).
+
+ A Printer MUST support this attribute.
+
+ When the Printer creates a Subscription Object, it MUST set the value
+ of this attribute to 0. This value indicates that the Printer has not
+ sent any Event Notifications for this Subscription Object.
+
+ Each time the Printer sends a newly generated Event Notification, it
+ MUST increase the value of this attribute by 1. For some Delivery
+ Methods, the Printer MUST include this attribute in each Event
+ Notification, and the value MUST be the value after it is increased
+ by 1. That is, the value of this attribute in the first Event
+ Notification after Subscription object creation MUST be 1, the second
+ MUST be 2, etc. If a Delivery Method is defined such that the
+ Notification Recipient returns a response, the Printer can re-try
+ sending an Event Notification a certain number of times with the same
+ sequence number when the Notification Recipient fails to return a
+ response.
+
+ If a Subscription Object lasts long enough to reach the value of MAX,
+ its next value MUST be 0, i.e., it wraps.
+
+5.4.3 notify-lease-expiration-time (integer(0:MAX))
+
+ This attribute specifies the time in the future when the lease on the
+ Per-Printer Subscription Object will expire, i.e. the "printer-up-
+ time" value at which the lease will expire. If the value is 0, the
+ lease never expires.
+
+ A Printer MUST support this attribute.
+
+ When the Printer creates a Per-Job Subscription Object, this
+ attribute MUST NOT be present - the Subscription Object lasts exactly
+ as long as the associated Job object.
+
+
+Herriot, et al. Expires July 24, 2001 [page 36]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ When the Printer creates a Per-Printer Subscription Object, it
+ populates this attribute with a value that is the sum of the values
+ of the Printer's "printer-up-time" attribute and the Subscription
+ Object's "notify-lease-duration" attribute with the following
+ exception. If the value of the Subscription Object's "notify-lease-
+ duration" attribute is 0 (i.e., no expiration time), then the value
+ of this attribute MUST be set to 0 (i.e., no expiration time).
+
+ When the Printer powers up, it MUST set the value of this attribute
+ in each persistent Subscription Object using the algorithm in the
+ previous paragraph.
+
+ When the "printer-up-time" equals the value of this attribute, the
+ Printer MUST delete the Subscription Object. A client can extend a
+ lease of a Per-Printer Subscription Object with the Renew-
+ Subscription operation (see section 11.2.5).
+
+ Note: In order to compute the number of seconds remaining in a lease
+ for a Per-Printer Subscription Object, a client can subtract the
+ Subscription's "notify-printer-up-time" attribute (see section 5.4.4)
+ from the Subscription's "notify-lease-expiration-time" attribute.
+
+5.4.4 notify-printer-up-time (integer(1:MAX))
+
+ This attribute is an alias for the Printer's "printer-up-time"
+ attribute " (see [RFC2911] section 4.4.29).
+
+ A Printer MUST support this attribute.
+
+ When the Printer creates a Per-Job Subscription Object, this
+ attribute MUST NOT be present. When the Printer creates a Per-Printer
+ Subscription Object, this attribute MUST be present.
+
+ Note: this attribute exists in a Per-Printer Subscription Object so
+ that a client using the Get-Subscription-Attributes or Get-
+ Subscription operations can convert the Per-Printer Subscription's
+ "notify-lease-expiration-time" attribute to wall clock time with one
+ request. If the value of the "notify-lease-expiration-time" attribute
+ is not 0 (i.e., no expiration time), then the difference between the
+ "notify-lease-expiration-time" attribute and the "notify-printer-up-
+ time" is the remaining number of seconds on the lease from the
+ current time.
+
+5.4.5 notify-printer-uri (uri)
+
+ This attribute identifies the Printer object that created this
+ Subscription Object.
+
+ A Printer MUST support this attribute.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 37]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ During a Subscription Creation Operation, the Printer MUST populate
+ this attribute with the value of the "printer-uri" operation
+ attribute in the request. From the Printer URI, the client can, for
+ example, determine what security scheme was used.
+
+5.4.6 notify-job-id (integer(1:MAX))
+
+ This attribute specifies whether the containing Subscription Object
+ is a Per-Job or Per-Printer Subscription Object, and for Per-Job
+ Subscription Objects, it specifies the associated Job.
+
+ A Printer MUST support this attribute.
+
+ If this attribute is not present, the Subscription Object MUST be a
+ Per-Printer Subscription. If this attribute is present, the
+ Subscription Object MUST be a Per-Job Subscription Object and this
+ attribute MUST identify the Job with which the Subscription Object is
+ associated.
+
+ Note: This attribute could be useful to a Notification Recipient that
+ receives an Event Notification generated from a Per-Job Subscription
+ Object and caused by a Printer Event. The Event Notification gives
+ access to the Printer and the Subscription Object. The Event
+ Notification gives access to the associated Job only via this
+ attribute.
+
+5.4.7 notify-subscriber-user-name (name(MAX))
+
+ This attribute contains the name of the user who performed the
+ Subscription Creation Operation.
+
+ A Printer MUST support this attribute.
+
+ The Printer sets this attribute to the most authenticated printable
+ name that it can obtain from the authentication service over which
+ the Subscription Creation Operation was received. The Printer uses
+ the same mechanism for determining the value of this attribute as it
+ does for a Job's "job-originating-user-name" (see [RFC2911] section
+ 4.3.6).
+
+ Note: To help with authentication, a Subscription Object may have
+ additional private attributes about the user, e.g., a credential of a
+ principal. Such private attributes are implementation-dependent and
+ not defined in this document.
+
+
+6 Printer Description Attributes Related to Notification
+
+ This section defines the Printer Description attributes that are
+ related to Notification. Table 3 lists the Printer Description
+
+
+Herriot, et al. Expires July 24, 2001 [page 38]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ attributes, indicates the Printer support required for conformance,
+ and whether or not the attribute is READ-ONLY (see section 3.1):
+
+
+ Table 3 - Printer Description Attributes Associated with Notification
+
+
+
+ Printer object attributes: REQUIRED READ-ONLY
+
+
+ printer-state-change-time (integer(1:MAX)) No Yes
+
+ printer-state-change-date-time (dateTime) No Yes
+
+
+
+6.1 printer-state-change-time (integer(1:MAX))
+
+ This attribute records the most recent time at which the 'printer-
+ state-changed' Printer Event occurred whether or not any Subscription
+ objects were listening for this event. This attribute helps a client
+ or operator to determine how long the Printer has been in its current
+ state.
+
+ A Printer MAY support this attribute and if so, the attribute MUST be
+ READ-ONLY.
+
+ On power-up, the Printer MUST set the value of this attribute to be
+ the value of its "printer-up-time" attribute, so that it always has a
+ value. Whenever the 'printer-state-changed' Printer Event occurs, the
+ Printer MUST set this attribute to the value of the Printer's
+ "printer-up-time" attribute.
+
+6.2 printer-state-change-date-time (dateTime)
+
+ This attribute records the most recent time at which the 'printer-
+ state-changed' Printer Event occurred whether or not there were any
+ Subscription Objects listening for this event. This attribute helps
+ a client or operator to determine how long the Printer has been in
+ its current state.
+
+ A Printer MAY support this attribute and if so, the attribute MUST be
+ READ-ONLY.
+
+ On power-up, the Printer MUST set the value of this attribute to be
+ the value of its "printer-current-time" attribute, so that it always
+ has a value (see [RFC2911] section 4.4.30 on "printer-current-time").
+ Whenever the 'printer-state-changed' Printer Event occurs, the
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 39]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Printer MUST set this attribute to the value of the Printer's
+ "printer-current-time" attribute.
+
+
+7 New Values for Existing Printer Description Attributes
+
+ This section contains those attributes for which additional values
+ are added.
+
+7.1 operations-supported (1setOf type2 enum)
+
+ The following "operation-id" values are added in order to support the
+ new operations defined in this document:
+
+
+ Table 4 - Operation-id assignments
+
+
+
+ Value Operation Name
+
+
+ 0x0016 Create-Printer-Subscriptions
+
+ 0x0017 Create-Job-Subscriptions
+
+ 0x0018 Get-Subscription-Attributes
+
+ 0x0019 Get-Subscriptions
+
+ 0x001A Renew-Subscription
+
+ 0x001B Cancel-Subscription
+
+
+8 Attributes Only in Event Notifications
+
+ This section contains those attributes that exist only in Event
+ Notifications and do not exist in any objects.
+
+8.1 notify-subscribed-event (type2 keyword)
+
+ This attribute indicates the Subscribed Event that caused the Printer
+ to send this Event Notification. This attribute exists only in Event
+ Notifications.
+
+ This attribute MUST contain one of the values of the "notify-events"
+ attribute in the Subscription Object, i.e., one of the Subscribed
+ Event values. Its value is the Subscribed Event that "matches" the
+ Event that caused the Printer to send this Event Notification. This
+
+
+Herriot, et al. Expires July 24, 2001 [page 40]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Subscribed Event value may be identical to the Event or the Event may
+ be a sub-value of the Subscribed Event. For example, the 'job-
+ completed' Event (which is a sub-event of the 'job-state-changed'
+ event) would cause the Printer to send an Event Notification for
+ either the 'job-completed' or 'job-state-changed' Subscribed Events
+ and to send the 'job-completed' or 'job-state-changed' value for this
+ attribute, respectively,. See section 5.3.2.2 for the "matching"
+ rules of Subscribed Events and for additional examples.
+
+ The Delivery Method Document specifies whether the Printer includes
+ the value of this attribute in an Event Notification.
+
+8.2 notify-text (text(MAX))
+
+ This attribute contains a Human Consumable text message (see section
+ 0). This message describes the Event and is encoded as plain text,
+ i.e., 'text/plain' with the charset specified by Subscription
+ Object's "notify-charset" attribute.
+
+ The Delivery Method Document specifies whether the Printer includes
+ this attribute in an Event Notification.
+
+
+9 Event Notification Content
+
+ This section defines the Event Notification content that the Printer
+ sends when an Event occurs.
+
+ When an Event occurs, the Printer MUST find each Subscription object
+ whose "notify-events" attribute "matches" the Event. See section
+ 5.3.2.2 for details on "matching". For each matched Subscription
+ Object, the Printer MUST create an Event Notification with the
+ content and format that the Delivery Method Document specifies. The
+ content contains the value of attributes specified by the Delivery
+ Method Document. The Printer obtains the values immediately after the
+ Event occurs. For example, if the "printer-state" attribute changes
+ from 'idle' to 'processing', the Event 'printer-state-changed' occurs
+ and the Printer puts various attributes into the Event Notification,
+ including "printer-up-time" and "printer-state" with the values that
+ they have immediately after the Event occurs, i.e., the value of
+ "printer-state" is 'processing'.
+
+ If two different Events occur simultaneously, or nearly so (e.g.,
+ "printer-up-time" has the same value for both), the Printer MUST
+ create a separate Event Notification for each Event, even if the
+ associated Subscription Object is the same for both Events. However,
+ the Printer MAY combine these distinct Event Notifications into a
+ single Compound Event Notification if the Delivery Method supports
+ Compound Event Notifications For example, suppose that two nearly-
+ simultaneously Events represent two successive 'printer-state-
+
+
+Herriot, et al. Expires July 24, 2001 [page 41]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ changed' Events, one from 'idle' to 'processing' and another from
+ 'processing' to 'stopped'. These two Events have the same name but
+ are different instances of the Event. Then the Printer MUST create a
+ separate Event Notification for each Event and SHOULD accurately
+ report the "printer-state" of the first Event as 'processing' and the
+ second Event as 'stopped'.
+
+ If a Subscription Object contains more than one Subscribed Event, and
+ several Events occur in quick succession each matching a different
+ Subscribed Event in the Subscription Object, the Printer MUST NOT
+ generate a single Event Notification from several of these Events,
+ but MAY combine distinct Event Notifications into a single Compound
+ Event Notification if the Delivery Method supports Compound Event
+ Notifications.
+
+ After the Printer has created the Event Notification, the Printer
+ delivers it via either a:
+
+ Push Delivery Method: The Printer sends the Event Notification
+ shortly after an Event occurs. For some Push Delivery Methods,
+ the Notification Recipient MUST send a response; for others it
+ MUST NOT send a response.
+
+ Pull Delivery Method: The Printer saves Event Notifications for
+ some event-lease time and expects the Notification Recipient to
+ request Event Notifications. The Printer returns the Event
+ Notifications in a response to such a request.
+
+ If an error that meets the following conditions occurs, the Printer
+ MUST cancel the Subscription Object.
+
+ a)the error occurs during the sending of an Event Notification
+ generated from Subscription Object S AND
+
+ b)the error would continue to occur every time the Printer sends an
+ Event Notification generated from Subscription Object S in the
+ future.
+
+ From example, if the address of the "notify-recipient-uri" of
+ Subscription Object A references a non-existent target and the
+ Printer determines that this fact, it MUST delete Subscription Object
+ A.
+
+ The next two sections describe the values that a Printer sends in the
+ content of Machine Consumable and Human Consumable Event
+ Notifications, respectively.
+
+ The tables in the sub-sections of this section contain the following
+ columns:
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 42]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ a)Source Value: the name of the attribute that supplies the value
+ for the Event Notification. Asterisks in this field refer to a
+ note below the table.
+
+ b)Sends: if the Printer supports the value (column 1) on the
+ Source Object (column 3) the Delivery Method MUST specify:
+
+ MUST: that the Printer MUST send the value.
+
+ SHOULD: either that the Printer MUST send the value or that
+ the value is incompatible with the Delivery Method.
+
+ MAY: that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT,
+ or NEED NOT send the value. The Delivery Method specifies the
+ level of conformance for the Printer.
+
+ c)Source Object: the object from which the source value comes. If
+ the object is "Event Notification", the Printer fabricates the
+ value when it sends the Event Notification. See section 8.
+
+9.1 Content of Machine Consumable Event Notifications
+
+ This section defines the attributes that a Delivery Method MUST
+ mention in a Delivery Method Document when specifying the Machine
+ Consumable Event Notification's contents.
+
+ This document does not define the order of attributes in Event
+ Notifications. However, Delivery Method Documents MAY define the
+ order of some or all of the attributes.
+
+ A Delivery Method Document MUST specify additional attributes (if
+ any) that a Printer implementation sends in a Machine Consumable
+ Event Notification.
+
+ Notification Recipients MUST be able to accept Event Notifications
+ containing attributes they do not recognize. What a Notification
+ Recipient does with an unrecognized attribute is implementation-
+ dependent. Notification Recipients MAY attempt to display
+ unrecognized attributes anyway or MAY ignore them.
+
+ The next three sections define the attributes in Event Notification
+ Contents that are:
+
+ 1.for all Events
+
+ 2.for Job Events only
+
+ 3.for Printer Events only
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 43]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+9.1.1 Event Notification Content Common to All Events
+
+ This section lists the attributes that a Delivery Method Document
+ MUST specify for all Events.
+
+ Table 5 lists potential values in each Event Notification.
+
+
+ Table 5 - Attributes in Event Notification Content
+
+
+
+ Source Value Sends Source Object
+
+
+ notify-subscription-id (integer(1:MAX)) MUST Subscription
+
+ notify-printer-uri (uri) MUST Subscription
+
+ notify-subscribed-event (type2 keyword) MUST Event
+ Notification
+
+ printer-up-time (integer(MIN:MAX)) MUST Printer
+
+ printer-current-time (dateTime) * MUST Printer
+
+ notify-sequence-number (integer (0:MAX)) SHOULD Subscription
+
+ notify-charset (charset) SHOULD Subscription
+
+ notify-natural-language (naturalLanguage) SHOULD Subscription
+
+ notify-user-data (octetString(63)) ** SHOULD Subscription
+
+ notify-text (text) SHOULD Event
+ Notification
+
+ attributes from the "notify-attributes" MAY Printer
+ attribute ***
+
+ attributes from the "notify-attributes" MAY Job
+ attribute ***
+
+ attributes from the "notify-attributes" MAY Subscription
+ attribute ***
+
+
+ *A Printer MUST send this value only if and only if it supports the
+ Printer's "printer-current-time" attribute.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 44]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ ** If the Subscription Object does not contain a "notify-user-data"
+ attribute and the Delivery Method document REQUIRES the Printer to
+ send the "notify-user-data" source value in the Event Notification,
+ the Printer MUST send an octet-string of length 0.
+
+ *** The last three rows represent additional attributes that a client
+ MAY request via the "notify-attributes" attribute. A Printer MAY
+ support the "notify-attributes" attribute. The Delivery Method MUST
+ say that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, or NEED
+ NOT support the "notify-attributes" attribute and specific values of
+ this attribute. The Delivery Method MAY say that support for the
+ "notify-attributes" is conditioned on support of the attribute by the
+ Printer or it MAY say that Printer MUST support the "notify-
+ attributes" attribute if the Printer supports the Delivery Method.
+
+9.1.2 Additional Event Notification Content for Job Events
+
+ This section lists the additional attributes that a Delivery Method
+ Document MUST specify for Job Events. See Table 6.
+
+
+ Table 6 - Additional Event Notification Content for Job Events
+
+
+
+ Source Value Sends Source Object
+
+
+ job-id (integer(1:MAX)) MUST Job
+
+ job-state (type1 enum) MUST Job
+
+ job-state-reasons (1setOf type2 keyword) MUST Job
+
+ job-impressions-completed (integer(0:MAX)) * MUST Job
+
+
+ * The Printer MUST send the "job-impressions-completed" attribute in
+ an Event Notification only for the combinations of Events and
+ Subscribed Events shown in Table 7.
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 45]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Table 7 - Combinations of Events and Subscribed Events for "job-
+ impressions-completed"
+
+
+
+ Job Event Subscribed Job Event
+
+
+ 'job-progress' 'job-progress'
+
+ 'job-completed' 'job-completed'
+
+ 'job-completed' 'job-state-changed'
+
+
+
+9.1.3 Additional Event Notification Content for Printer Events
+
+ This section lists the additional attributes that a Delivery Method
+ Document MUST specify for Printer Events. See Table 8.
+
+
+ Table 8 - Additional Event Notification Content for Printer Events
+
+
+
+ Source Value Sends Source Object
+
+
+ printer-state (type1 enum) MUST Printer
+
+ printer-state-reasons (1setOf type2 keyword) MUST Printer
+
+ printer-is-accepting-jobs (boolean) MUST Printer
+
+
+9.2 Content of Human Consumable Event Notification
+
+ This section defines the information that a Delivery Method MUST
+ mention in a Delivery Method Document when specifying the Human
+ Consumable Event Notifications contents or the value of the "notify-
+ text" attribute.
+
+ Such a Delivery Method MUST specify the following information and a
+ Printer SHOULD send it:
+
+ a)the Printer name (see Table 9)
+ b)the time of the Event (see Table 11)
+ c)for Printer Events only:
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 46]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ i) the Event (see Table 10) and/or Printer state information
+ (see Table 14)
+ d)for Job Events only:
+ i) the job identity (see Table 12)
+ ii) the Event (see Table 10) and/or Job state information (see
+ Table 13)
+
+ The subsections of this section specify the attributes that a Printer
+ MUST use to obtain this information.
+
+ A Delivery Method Document MUST specify additional information (if
+ any) that a Printer implementation sends in a Human Consumable Event
+ Notification or in the "notify-text" attribute.
+
+ A client MUST NOT request additional attributes via the "notify-
+ attributes" attribute because this attribute works only for Machine
+ Consumable Event Notifications.
+
+ Notification Recipients MUST NOT expect to be able to parse the Human
+ Consumable Event Notification contents or the value of the "notify-
+ text" attribute.
+
+ The next three sections define the attributes in Event Notification
+ Contents that are:
+
+ a) for all Events
+ b) for Job Events only
+ c) for Printer Events only
+
+9.2.1 Event Notification Content Common to All Events
+
+ This section lists the source of the information that a Delivery
+ Method MUST specify for all Events.
+
+ There is a separate table for each piece of information. Each row in
+ the table represents a source value for the information and the
+ values are listed in order of preference, with the first one being
+ the preferred one. An implementation SHOULD use the source value from
+ the earliest row in each table. It MAY use the source value from
+ another row instead, or it MAY combine the source values from several
+ rows. An implementation is free to determine the best way to present
+ this information.
+
+ In all tables of this section, all rows contain a "MAY" in order to
+ state that the Delivery Method specifies the conformance.
+
+ Table 9 lists the source of the information for the Printer Name. The
+ "printer-name" is more user-friendly unless the Notification
+ Recipient is in a place where the Printer name is not meaningful. For
+ example, an implementation could have the intelligence to send the
+
+
+Herriot, et al. Expires July 24, 2001 [page 47]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ value of the "printer-name" attribute to a Notification Recipient
+ that can access the Printer via value of the "printer-name" attribute
+ and otherwise send the value of the "notify-printer-uri" attribute.
+
+
+ Table 9 - Printer Name in Event Notification Content
+
+
+
+ Source Value Sends Source Object
+
+
+ printer-name (name(127)) MAY Printer
+
+ notify-printer-uri (uri) MAY Subscription
+
+
+
+
+ Table 10 lists the source of the information for the Event name. A
+ Printer MAY combine this information with state information described
+ for Jobs in Table 13 or for Printers in Table 14.
+
+
+ Table 10 - Event Name in Event Notification Content
+
+
+
+ Source Value Sends Source Object
+
+
+ notify-subscribed-event (type2 keyword) MAY Subscription
+
+
+
+ Table 11 lists the source of the information for the time that the
+ Event occurred. A Printer can send this value only if it supports the
+ Printer's "printer-current-time" attribute. If a Printer does not
+ support the "printer-current-time" attribute, it MUST NOT send the
+ "printer-up-time" value instead, since it is not an allowed option
+ for human consumable information.
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 48]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Table 11 - Event Time in Event Notification Content
+
+
+
+ Source Value Sends Source Object
+
+
+ printer-current-time (dateTime) MAY Printer
+
+
+
+9.2.2 Additional Event Notification Content for Job Events
+
+ This section lists the source of the additional information that a
+ Delivery Method MUST specify for Job Events.
+
+ Table 12 lists the source of the information for the job name. The
+ "job-name" is likely more meaningful to a user than "job-id".
+
+
+ Table 12 - Job Name in Event Notification Content
+
+
+
+ Source Value Sends Source Object
+
+
+ job-name (name(MAX)) MAY Job
+
+ job-id (integer(1:MAX)) MAY Job
+
+
+
+ Table 13 lists the source of the information for the job state. If a
+ Printer supports the "job-state-message" and "job-detailed-state-
+ message" attributes, it SHOULD use those attributes for the job state
+ information, otherwise, it should fabricate such information from the
+ "job-state" and "job-state-reasons". For some Events, a Printer MAY
+ combine this information with Event information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 49]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Table 13 - Job State in Event Notification Content
+
+
+
+ Source Value Sends Source
+ Object
+
+
+ job-state-message (text(MAX)) MAY Job
+
+ job-detailed-status-messages (1setOf text(MAX)) MAY Job
+
+ job-state (type1 enum) MAY Job
+
+ job-state-reasons (1setOf type2 keyword) MAY Job
+
+
+9.2.3 Additional Event Notification Content for Printer Events
+
+ This section lists the source of the additional information that a
+ Delivery Method MUST specify for Printer Events.
+
+ Table 14 lists the source of the information for the printer state.
+ If a Printer supports the "printer-state-message", it SHOULD use that
+ attribute for the job state information, otherwise it SHOULD
+ fabricate such information from the "printer-state" and "printer-
+ state-reasons". For some Events, a Printer MAY combine this
+ information with Event information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 50]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Table 14 - Printer State in Event Notification Content
+
+
+
+ Source Value Sends Source
+ Object
+
+
+ printer-state-message (text(MAX)) MAY Printer
+
+ printer-state (type1 enum) MAY Printer
+
+ printer-state-reasons (1setOf type2 keyword) MAY Printer
+
+ printer-is-accepting-jobs (boolean) MAY Printer
+
+
+10 Delivery Methods
+
+ A Delivery Method is the mechanism, i.e., protocol, by which the
+ Printer delivers an Event Notification to a Notification Recipient.
+ There are several potential Delivery Methods for Event Notifications,
+ standardized, as well as proprietary. This document does not define
+ any of these delivery mechanisms. Each Delivery Method MUST be
+ defined in a Delivery Method Document that is separate from this
+ document. New Delivery Methods will be created as needed using an
+ extension to the registration procedures defined in [RFC2911]. Such
+ documents are registered with IANA (see section 13).
+
+ The following sorts of Delivery Methods are expected:
+
+ - The Notification Recipient polls for Event Notifications at
+ intervals directed by the Printer
+
+ - The Printer sends Event Notifications to the Notification
+ Recipient using http as the transport.
+
+ - The Printer sends an email message.
+
+ This section specifies how to define a Delivery Method Document and
+ what to put in such a document.
+
+ A Delivery Method Document MUST contain an exact copy of the
+ following paragraph, caption and table. In addition, column 2 of the
+ table in the Delivery Method Document MUST contain answers to
+ questions in column 1 for the Delivery Method. Also, the Delivery
+ Method document MUST contain a reference to this document and call
+ that reference [ipp-ntfy] because the table contains an [ipp-ntfy]
+ reference.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 51]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ If a Printer supports this Delivery Method, the following are its
+ characteristics.
+
+
+ Table 15 - Information about the Delivery Method
+
+
+
+ Document Method Conformance Delivery Method Realization
+ Requirement
+
+
+ 1.What is the URL scheme name for the
+ Delivery Method?
+
+ 2.Is the Delivery Method REQUIRED,
+ RECOMMENDED, or OPTIONAL for an IPP
+ Printer to support?
+
+ 3.What transport and delivery
+ protocols does the Printer use to
+ deliver the Event Notification
+ Content, i.e., what is the entire
+ network stack?
+
+ 4.Can several Event Notifications be
+ combined into a Compound Event
+ Notification?
+
+ 5.Is the Delivery Method initiated by
+ the Notification Recipient (pull),
+ or by the Printer (push)?
+
+ 6.Is the Event Notification content
+ Machine Consumable or Human
+ Consumable?
+
+ 7.What section in this document
+ answers the following question? For
+ a Machine Consumable Event
+ Notification, what is the
+ representation and encoding of
+ values defined in section 9.1 of
+ [ipp-ntfy] and the conformance
+ requirements thereof? For a Human
+ Consumable Event Notification, what
+ is the representation and encoding
+ of pieces of information defined in
+ section 0 of [ipp-ntfy] and the
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 52]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+
+ conformance requirements thereof?
+
+ 8.What are the latency and
+ reliability of the transport and
+ delivery protocol?
+
+ 9.What are the security aspects of
+ the transport and delivery
+ protocol, e.g., how it is handled
+ in firewalls?
+
+ 10. What are the content length
+ restrictions?
+
+ 11. What are the additional values
+ or pieces of information that a
+ Printer sends in an Event
+ Notification content and the
+ conformance requirements thereof?
+
+ 12. What are the additional
+ Subscription Template and/or
+ Subscription Description attributes
+ and the conformance requirements
+ thereof?
+
+ 13. What are the additional Printer
+ Description attributes and the
+ conformance requirements thereof?
+
+
+
+11 Operations for Notification
+
+ This section defines all of the operations for Notification. Section
+ 7.1 assigns the "operation-id" for each operation. The following two
+ sub-sections define Subscription Creation Operations, and other
+ operations.
+
+11.1 Subscription Creation Operations
+
+ This section defines the Subscription Creation Operations. The first
+ section on Create-Job-Subscriptions gives most of the information.
+ The other Subscription Creation Operations refer to the section on
+ Create-Job-Subscriptions, even though the Create-Job-Subscriptions
+ operation is the only OPTIONAL operation in this document (see
+ section 12).
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 53]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ A Printer MUST support Create-Printer-Subscriptions and the
+ Subscription Template Attributes Group in Job Creation operations. It
+ MAY support Create-Job-Subscriptions operations.
+
+11.1.1 Create-Job-Subscriptions Operation
+
+ The operation creates one or more Per-Job Subscription Objects. The
+ client supplies one or more Subscription Template Attributes Groups
+ each containing one or more of Subscription Template Attributes
+ (defined in section 5.3).
+
+ Except for errors, the Printer MUST create exactly one Per-Job
+ Subscription Object from each Subscription Template Attributes Group
+ in the request, even if the newly created Subscription Object would
+ have identical behavior to some existing Subscription Object. The
+ Printer MUST associate each newly created Per-Job Subscription Object
+ with the target Job, which is specified by the "notify-job-id"
+ operation attribute.
+
+ The Printer MUST accept the request in any of the target job's 'not-
+ completed' states, i.e., 'pending', 'pending-held', 'processing', or
+ 'processing-stopped'. The Printer MUST NOT change the job's "job-
+ state" attribute because of this operation. If the target job is in
+ any of the 'completed' states, i.e., 'completed', 'canceled', or
+ 'aborted, then the Printer MUST reject the request and return the
+ 'client-error-not-possible' status code; the response MUST NOT
+ contain any Subscription Attribute Groups.
+
+ Access Rights: To create Per-Job Subscription Objects, the
+ authenticated user (see [RFC2911] section 8.3) performing this
+ operation MUST either be the job owner or have Operator or
+ Administrator access rights for this Printer (see [RFC2911] sections
+ 1 and 8.5). Otherwise the Printer MUST reject the operation and
+ return: the 'client-error-forbidden', 'client-error-not-
+ authenticated', or 'client-error-not-authorized' status code as
+ appropriate.
+
+11.1.1.1 Create-Job-Subscriptions Request
+
+ The following groups of attributes are part of the Create-Job-
+ Subscriptions Request:
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.1.
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 54]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Target:
+ The "printer-uri" attribute which defines the target for this
+ operation as described in [RFC2911] section 3.1.5.
+
+ Requesting User Name:
+ The "requesting-user-name" attribute SHOULD be supplied by the
+ client as described in [RFC2911] section 8.3.
+
+ notify-job-id (integer(1:MAX)):
+ The client MUST supply this attribute and it MUST specify the
+ Job object to associate the Per-Job Subscription with. The
+ value of "notify-job-id" MUST be the value of the "job-id" of
+ the associated Job object. If the client does not supply this
+ attribute, the Printer MUST reject this request with a 'client-
+ error-bad-request' status code.
+
+ Group 2-N: Subscription Template Attributes
+
+ For each occurrence of this group:
+
+ The client MUST supply one or more Subscription Template
+ Attributes in any order. See section 5.3 for a description of
+ each such attribute. See section 5.2 for details on processing
+ these attributes.
+
+11.1.1.2 Create-Job-Subscriptions Response
+
+ The Printer MUST return to the client the following sets of
+ attributes as part of a Create-Job-Subscriptions response:
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ In addition to the REQUIRED status code returned in every
+ response, the response OPTIONALLY includes a "status-message"
+ (text(255)) and/or a "detailed-status-message" (text(MAX))
+ operation attribute as described in [RFC2911] sections 13 and
+ 31.6.
+
+ In this group, the Printer can return any status codes defined
+ in [RFC2911] and section 16. The following is a description of
+ the important status codes:
+
+ successful-ok: the Printer created all Subscription Objects
+ requested.
+ successful-ok-ignored-subscriptions: the Printer created some
+ Subscription Objects requested but some failed. The
+ Subscription Attributes Groups with a "notify-status-code"
+ attribute are the ones that failed.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 55]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ client-error-ignored-all-subscriptions: the Printer created no
+ Subscription Objects requested and all failed. The
+ Subscription Attributes Groups with a "notify-status-code"
+ attribute are the ones that failed
+ client-error-not-possible: For this operation and other Per-Job
+ Subscription operations, this error can occur because the
+ specified Job has already completed.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2.
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes. This group does not contain any
+ unsupported Subscription Template Attributes; they are returned
+ in the Subscription Attributes Group (see below).
+
+ Group 3-N: Subscription Attributes
+
+ These groups MUST be returned unless the Printer is unable to
+ interpret the entire request, e.g., the "status-code" parameter
+ returned in Group 1 has the value: 'client-error-bad-request'.
+
+ "notify-status-code" (type2 enum):
+ Indicates the status of this subscription (see section 17 for
+ the status code definitions). Section 5.2 defines when this
+ attribute MUST be present in this group.
+
+ See section 5.2 for details on the contents of each occurrence
+ of this group.
+
+11.1.2 Create-Printer-Subscriptions operation
+
+ The operation is identical to Create-Job-Subscriptions with
+ exceptions noted in this section.
+
+ The operation creates Per-Printer Subscription Objects instead of
+ Per-Job Subscription Objects, and associates each newly created Per-
+ Printer Subscription Object with the Printer specified by the
+ operation target rather than with a specific Job.
+
+ The Printer MUST accept the request in any of its states, i.e.,
+ 'idle', 'processing', or 'stopped'. The Printer MUST NOT change its
+ "printer-state" attribute because of this operation.
+
+ Access Rights: To create Per-Printer Subscription Objects, the
+ authenticated user (see [RFC2911] section 8.3) performing this
+ operation MUST have Operator or Administrator access rights for this
+
+
+Herriot, et al. Expires July 24, 2001 [page 56]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Printer (see [RFC2911] sections 1 and 8.5). Otherwise, the Printer
+ MUST reject the operation and return: the 'client-error-forbidden',
+ 'client-error-not-authenticated', or 'client-error-not-authorized'
+ status code as appropriate.
+
+11.1.2.1 Create-Printer-Subscriptions Request
+
+ The groups are identical to the Create-Job-Subscriptions (see section
+ 11.1.1.1) except that the Operation Attributes group MUST NOT contain
+ the "notify-job-id" attribute. If the client does supply the
+ "notify-job-id" attribute, then the Printer MUST treat it as any
+ other unsupported Operation attribute and MUST return it in the
+ Unsupported Attributes group.
+
+11.1.2.2 Create-Printer-Subscriptions Response
+
+ The groups are identical to the Create-Job-Subscriptions (see section
+ 11.1.1.2).
+
+
+11.1.3 Job Creation Operation - Extensions for Notification
+
+ This document extends the Job Creation operations to create
+ Subscription Objects as a part of the operation.
+
+ The operation is identical to Create-Job-Subscriptions with
+ exceptions noted in this section.
+
+ Unlike the Create-Job-Subscriptions operation, this operation
+ associates the newly created Subscription Objects with the Job object
+ created by this operation. The operation succeeds if and only if the
+ Job creation succeeds. If the Printer does not create some or all of
+ the requested Subscription Objects, the Printer MUST return a
+ 'successful-ok-ignored-subscriptions' status-code instead of a
+ 'successful-ok' status-code, but the Printer MUST NOT reject the
+ operation because of a failure to create Subscription Objects.
+
+ If the operation includes a Job Template group, the client MUST
+ supply it after the Operation Attributes group and before the first
+ Subscription Template Attributes Group.
+
+ If a Printer does not support this Notification specification, then
+ it MUST treat the Subscription Attributes Group like an unknown group
+ and ignore it (see [RFC2911] section 5.2.2). Because the Printer
+ ignores the Subscription Attributes Group, it doesn't return them in
+ the response either, thus indicating to the client that the Printer
+ doesn't support Notification.
+
+ Access Rights: To create Per-Job Subscription Objects, the
+ authenticated user (see [RFC2911] section 8.3) performing this
+
+
+Herriot, et al. Expires July 24, 2001 [page 57]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ operation MUST either have permission to create Jobs on the Printer.
+ Otherwise the Printer MUST reject the operation and return: the
+ 'client-error-forbidden', 'client-error-not-authenticated', or
+ 'client-error-not-authorized' status code as appropriate.
+
+11.1.3.1 Job Creation Request
+
+ The groups for this operation are sufficiently different from the
+ Create-Job-Subscriptions operation that they are all presented here.
+ The following groups of attributes are supplied as part of a Job
+ Creation Request:
+
+ Group 1: Operation Attributes
+
+ Same as defined in [RFC2911] for Print-Job, Print-URI, and
+ Create-Job requests.
+ Group 2: Job Template Attributes
+
+ The client OPTIONALLY supplies a set of Job Template attributes
+ as defined in [RFC2911] section 4.2.
+ Group 3 to N: Subscription Template Attributes
+
+ The same as Group 2-N in Create-Job-Subscriptions. See section
+ 11.1.1.1.
+ Group N+1: Document Content (Print-Job only)
+
+ The client MUST supply the document data to be processed.
+
+11.1.3.2 Job Creation Response
+
+ The Printer MUST return to the client the following sets of
+ attributes as part of a Print-Job, Print-URI, and Create-Job
+ Response:
+
+ Group 1: Operation Attributes
+
+
+ Status Message:
+
+ As defined in [RFC2911] for Print-Job, Print-URI, and Create-
+ Job requests.
+
+ In this group, the Printer can return any status codes defined
+ in [RFC2911] and section 16. The following is a description of
+ the important status codes:
+
+ successful-ok: the Printer created the Job and all Subscription
+ Objects requested.
+ successful-ok-ignored-subscriptions: the Printer created the Job
+ and not all of the Subscription Objects requested. This
+
+
+Herriot, et al. Expires July 24, 2001 [page 58]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ status-code hides 'successful-ok-xxx' status-codes that could
+ reveal problems in Job creation. The Printer MUST not return
+ the 'client-error-ignored-all-subscriptions' status code for
+ Job Creation operations because the Printer returns an error
+ status-code only when it fails to create a Job.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2.
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes. This group does not contain any
+ unsupported Subscription Template Attributes; they are returned
+ in the Subscription Attributes Group (see below).
+
+ Group 3: Job Object Attributes
+
+ As defined in [RFC2911] for Print-Job, Print-URI, and Create-
+ Job requests.
+
+ Group 4 to N: Subscription Attributes
+
+ These groups MUST be returned if and only if the client
+ supplied Subscription Template Attributes and the operation was
+ accepted.
+
+ See section 5.2 for details on the contents of each occurrence
+ of this group.
+
+11.2 Other Operations
+
+ This section defines other operations on Subscription objects.
+
+11.2.1 Validate-Job Operation - Extensions for Notification
+
+ A client can test whether one or more Subscription Objects could be
+ created using the Validate-Job operation. The client supplies one or
+ more Subscription Template Attributes Groups (defined in section
+ 5.3), just as in a Job Creation request.
+
+ A Printer MUST support this extension to this operation.
+
+ The Printer MUST accept requests that are identical to the Job
+ Creation request defined in section 11.1.3.1, except that the request
+ MUST not contain document data.
+
+ The Printer MUST return the same groups and attributes as the Print-
+ Job operation (section 11.1.3.1) with the following exceptions. The
+
+
+Herriot, et al. Expires July 24, 2001 [page 59]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Printer MUST NOT return a Job Object Attributes Group because no Job
+ is created. The Printer MUST NOT return the "notify-subscription-id"
+ attribute in any Subscription Attribute Group because no Subscription
+ Object is created.
+
+ If the Printer would succeed in creating a Subscription Object, the
+ corresponding Subscription Attributes Group either has no 'status-
+ code' attribute or a 'status-code' attribute with a value of
+ 'successful-ok-too-many-events' or 'successful-ok-ignored-or-
+ substituted-attributes' (see sections 5.2 and 17). The status-codes
+ have the same meaning as in Job Creation except the results state
+ what "would happen".
+
+ The Printer MUST validate Subscription Template Attributes Groups in
+ the same manner as the Job Creation operations.
+
+11.2.2 Get-Printer-Attributes - Extensions for Notification
+
+ This operation is extended so that it returns Printer attributes
+ defined in this document.
+
+ A Printer MUST support this extension to this operation.
+
+ In addition to the requirements of [RFC2911] section 3.2.5, a Printer
+ MUST support the following additional values for the "requested-
+ attributes" Operation attribute in this operation and return such
+ attributes in the Printer Object Attributes group of its response.
+
+ 1.Subscription Template Attributes: Each supported attribute in
+ column 2 of Table 1.
+
+ 2.New Printer Description Attributes: Each supported attribute in
+ section 6.
+
+ 3.New Group Name: The 'subscription-template' group name, which
+ names all supported Subscription Template Attribute in column 2
+ of Table 1. This group name is also used in the Get-
+ Subscription-Attributes and Get-Subscriptions operation with an
+ analogous meaning.
+
+ 4.Extended Group Name: The 'all' group name, which names all
+ Printer attributes according to [RFC2911] section 3.2.5. In
+ this extension 'all' names all attributes specified in [RFC2911]
+ plus those named in items 1 and 2 of this list.
+
+11.2.3 Get-Subscription-Attributes operation
+
+ This operation allows a client to request the values of the
+ attributes of a Subscription Object.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 60]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ A Printer MUST support this operation.
+
+ This operation is almost identical to the Get-Job-Attributes
+ operation (see [RFC2911] section 3.3.4). The only differences are
+ that the operation is directed at a Subscription Object rather than a
+ Job object, and the returned attribute group contains Subscription
+ Object attributes rather than Job object attributes.
+
+11.2.3.1 Get-Subscription-Attributes Request
+
+ The following groups of attributes are part of the Get-Subscription-
+ Attributes request:
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in section [RFC2911] 3.1.4.1.
+
+ Target:
+ The "printer-uri" attribute which defines the target for this
+ operation as described in [RFC2911] section 3.1.5.
+
+ "notify-subscription-id" (integer (1:MAX)):
+ The client MUST supply this attribute. The Printer MUST
+ support this attribute. This attribute specifies the
+ Subscription Object from which the client is requesting
+ attributes. If the client omits this attribute, the Printer
+ MUST reject this request with the 'client-error-bad-request'
+ status code.
+
+ Requesting User Name:
+ The "requesting-user-name" attribute SHOULD be supplied by the
+ client as described in [RFC2911] section 8.3.
+
+ "requested-attributes" (1setOf keyword):
+ The client OPTIONALLY supplies this attribute. The Printer
+ MUST support this attribute. This attribute specifies the
+ attributes of the specified Subscription Object that the
+ Printer MUST return in the response. Each value of this
+ attribute is either an attribute name (defined in sections 5.3
+ and 5.4) or an attribute group name. The attribute group names
+ are:
+
+ - 'subscription-template': all attributes that are both defined
+ in section 5.3 and present on the specified Subscription
+ Object (column 1 of Table 1).
+ - 'subscription-description': all attributes that are both
+ defined in section 5.4 and present on the specified
+ Subscription Object (Table 2).
+
+
+Herriot, et al. Expires July 24, 2001 [page 61]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ - 'all': all attributes that are present on the specified
+ Subscription Object.
+ A Printer MUST support all these group names.
+
+ If the client omits this attribute, the Printer MUST respond as
+ if this attribute had been supplied with a value of 'all'.
+
+11.2.3.2 Get-Subscription-Attributes Response
+
+ The Printer returns the following sets of attributes as part of the
+ Get-Subscription-Attributes Response:
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ Same as [RFC2911].
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2. The
+ "attributes-natural-language" MAY be the natural language of
+ the Subscription Object, rather than the one requested.
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes.
+
+ The response NEED NOT contain the "requested-attributes"
+ operation attribute with any supplied values (attribute
+ keywords) that were requested by the client but are not
+ supported by the Printer. If the Printer does return
+ unsupported attributes referenced in the "requested-attributes"
+ operation attribute and that attribute included group names,
+ such as 'all', the unsupported attributes MUST NOT include
+ attributes described in the standard but not supported by the
+ implementation.
+
+ Group 3: Subscription Attributes
+
+ This group contains a set of attributes with their current
+ values. Each attribute in this group:
+
+ a)MUST be specified by the "requested-attributes" attribute
+ in the request, AND
+
+ b)MUST be present on the specified Subscription Object AND
+
+ c)MUST NOT be restricted by the security policy in force.
+ For example, a Printer MAY prohibit a client who is not the
+
+
+Herriot, et al. Expires July 24, 2001 [page 62]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ creator of a Subscription Object from seeing some or all of
+ its attributes. See [RFC2911] section 8.
+
+ The Printer can return the attributes of the Subscription
+ Object in any order. The client MUST accept the attributes in
+ any order.
+
+11.2.4 Get-Subscriptions operation
+
+ This operation allows a client to retrieve the values of attributes
+ of all Subscription Objects belonging to a Job or Printer.
+
+ A Printer MUST supported this operation.
+
+ This operation is similar to the Get-Subscription-Attributes
+ operation, except that this Get-Subscriptions operation returns
+ attributes from possibly more than one object.
+
+ This operation is similar to the Get-Jobs operation (see [RFC2911]
+ section 3.2.6), except that the operation returns Subscription
+ Objects rather than Job objects.
+
+11.2.4.1 Get-Subscriptions Request
+
+ The following groups of attributes are part of the Get-Subscriptions
+ request:
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.1.
+
+ Target:
+ The "printer-uri" attribute which defines the target for this
+ operation as described in [RFC2911] section 3.1.5.
+
+ Requesting User Name:
+ The "requesting-user-name" attribute SHOULD be supplied by the
+ client as described in [RFC2911] section 8.3.
+
+ "notify-job-id" (integer(1:MAX)):
+ If the client specifies this attribute, the Printer returns the
+ specified attributes of all Per-Job Subscription Objects
+ associated with the Job whose "job-id" attribute value equals
+ the value of this attribute. If the client does not specify
+ this attribute, the Printer returns the specified attributes of
+ all Per-Printer Subscription Objects. Note: there is no way to
+ get all Per-Job Subscriptions.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 63]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ "limit" (integer(1:MAX)):
+ The client OPTIONALLY supplies this attribute. The Printer
+ MUST support this attribute. It is an integer value that
+ determines the maximum number of Subscription Objects that a
+ client will receive from the Printer even if the "my-
+ subscriptions" attribute constrains which Subscription Objects
+ are returned. The limit is a "stateless limit" in that if the
+ value supplied by the client is 'N', then only the first 'N'
+ Subscription Objects are returned in the Get-Subscriptions
+ Response. There is no mechanism to allow for the next 'M'
+ Subscription Objects after the first 'N' Subscription Objects.
+ If the client does not supply this attribute, the Printer
+ responds with all applicable Subscription Objects.
+
+ "requested-attributes" (1setOf type2 keyword):
+ The client OPTIONALLY supplies this attribute. The Printer
+ MUST support this attribute. This attribute specifies the
+ attributes of the specified Subscription Objects that the
+ Printer MUST return in the response. Each value of this
+ attribute is either an attribute name (defined in sections 5.3
+ and 5.4) or an attribute group name (defined in section
+ 11.2.3.1). If the client omits this attribute, the Printer MUST
+ respond as if the client had supplied this attribute with the
+ one value: 'notify-subscription-id'.
+
+ "my-subscriptions" (boolean):
+ The client OPTIONALLY supplies this attribute. The Printer
+ MUST support this attribute. If the value is 'false', the
+ Printer MUST consider the Subscription Objects from all users
+ as candidates. If the value is 'true', the Printer MUST return
+ the Subscription Objects created by the requesting user of this
+ request. If the client does not supply this attribute, the
+ Printer MUST respond as if the client had supplied the
+ attribute with a value of 'false'. The means for
+ authenticating the requesting user and matching the
+ Subscription Objects is similar to that for Jobs which is
+ described in [RFC2911] section 8.
+
+11.2.4.2 Get-Subscriptions Response
+
+ The Printer returns the following sets of attributes as part of the
+ Get-Subscriptions Response:
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ Same as [RFC2911].
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 64]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2.
+
+ Group 2: Unsupported Attributes
+
+ Same as for Get-Subscription-Attributes.
+
+ Groups 3 to N: Subscription Attributes
+
+ The Printer responds with one Subscription Attributes Group for
+ each requested Subscription Object (see the "notify-job-id"
+ attribute in the Operation Attributes Group of this operation).
+
+ The Printer returns Subscription Objects in any order.
+
+ If the "limit" attribute is present in the Operation Attributes
+ group of the request, the number of Subscription Attributes
+ Groups in the response MUST NOT exceed the value of the "limit"
+ attribute.
+
+ It there are no Subscription Objects associated with the
+ specified Job or Printer, the Printer MUST return zero
+ Subscription Attributes Groups and it MUST NOT treat this case
+ as an error, i.e., the status-code MUST be 'successful-ok'
+ unless something else causes the status code to have some other
+ value.
+
+ See the Group 3 response (Subscription Attributes Group) of the
+ Get-Subscription-Attributes operation (section 11.2.3.2) for
+ the attributes that a Printer returns in this group.
+
+11.2.5 Renew-Subscription operation
+
+ This operation allows a client to request the Printer to extend the
+ lease on a Per-Printer Subscription Object.
+
+ The Printer MUST support this operation.
+
+ The Printer MUST accept this request for a Per-Printer Subscription
+ Object in any of the target Printer's states, i.e., 'idle',
+ 'processing', or 'stopped', but MUST NOT change the Printer's
+ "printer-state" attribute.
+
+ The Printer MUST reject this request for a Per-Job Subscription
+ Object because it has no lease (see section 5.4.3). The status code
+ returned MUST be 'client-error-not-possible'.
+
+ Access Rights: The authenticated user (see [RFC2911] section 8.3)
+ performing this operation MUST either be the owner of the Per-Printer
+
+
+Herriot, et al. Expires July 24, 2001 [page 65]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Subscription Object or have Operator or Administrator access rights
+ for the Printer (see [RFC2911] sections 1 and 8.5). Otherwise, the
+ Printer MUST reject the operation and return: the 'client-error-
+ forbidden', 'client-error-not-authenticated', or 'client-error-not-
+ authorized' status code as appropriate.
+
+11.2.5.1 Renew-Subscription Request
+
+ The following groups of attributes are part of the Renew-Subscription
+ Request:
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.1.
+
+ Target:
+ The "printer-uri" attribute which defines the target for this
+ operation as described in [RFC2911] section 3.1.5.
+
+ "notify-subscription-id" (integer (1:MAX)):
+ The client MUST supply this attribute. The Printer MUST
+ support this attribute. This attribute specifies the Per-
+ Printer Subscription Object whose lease the Printer MUST renew.
+ If the client omits this attribute, the Printer MUST reject
+ this request with the 'client-error-bad-request' status code.
+
+ Requesting User Name:
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be
+ supplied by the client as described in [RFC2911] section 8.3.
+
+ Group 2: Subscription Template Attributes
+
+
+ "notify-lease-duration" (integer(0:MAX)):
+ The client MAY supply this attribute. It indicates the number
+ of seconds to renew the lease for the specified Subscription
+ Object. A value of 0 requests an infinite lease (which MAY
+ require Operator access rights). If the client omits this
+ attribute, the Printer MUST use the value of the Printer's
+ "notify-lease-duration-default" attribute. See section 5.3.7
+ for more details.
+
+11.2.5.2 Renew-Subscription Response
+
+ The Printer returns the following sets of attributes as part of the
+ Renew-Subscription Response:
+
+ Group 1: Operation Attributes
+
+
+Herriot, et al. Expires July 24, 2001 [page 66]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Status Message:
+ Same as [RFC2911].
+
+ The following are some of the status codes returned:
+
+ successful-ok: The operation successfully renewed the lease on the
+ Subscription Object for the requested duration..
+ successful-ok-ignored-or-substituted-attributes: The operation
+ successfully renewed the lease on the Subscription Object for
+ some duration other than the amount requested.
+ client-error-not-possible: The operation failed because the
+ "notify-subscription-id" Operation attribute identified a Per-
+ Job Subscription Object.
+ client-error-not-found: The operation failed because the "notify-
+ subscription-id" Operation attribute identified a non-existent
+ Subscription Object.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2. The
+ "attributes-natural-language" MAY be the natural language of
+ the Subscription Object, rather than the one requested.
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes.
+
+ Group 3: Subscription Attributes
+
+ The Printer MUST return the following Subscription Attribute:
+
+ "notify-lease-duration" (integer(0:MAX)):
+ The value of this attribute MUST be the number of seconds that
+ the Printer has granted for the lease of the Subscription
+ Object (see section 5.3.7 for details, such as the value of
+ this attribute when the Printer doesn't support the requested
+ value).
+
+
+
+11.2.6 Cancel-Subscription operation
+
+ This operation allows a client to delete a Subscription Object and
+ stop the Printer from sending more Event Notifications. Once
+ performed, there is no way to reference the Subscription Object.
+
+ A Printer MUST supported this operation.
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 67]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ The Printer MUST accept this request in any of the target Printer's
+ states, i.e., 'idle', 'processing', or 'stopped', but MUST NOT change
+ the Printer's "printer-state" attribute.
+
+ If the specified Subscription Object is a Per-Job Subscription
+ Object, the Printer MUST accept this request in any of the target
+ Job's states, but MUST NOT change the Job's "job-state" attribute or
+ affect the Job.
+
+ Access Rights: The authenticated user (see [RFC2911] section 8.3)
+ performing this operation MUST either be the owner of the
+ Subscription Object or have Operator or Administrator access rights
+ for the Printer (see [RFC2911] sections 1 and 8.5). Otherwise, the
+ Printer MUST reject the operation and return: the 'client-error-
+ forbidden', 'client-error-not-authenticated', or 'client-error-not-
+ authorized' status code as appropriate.
+
+ Note: There is no way to change any attributes on a Subscription
+ Object, except the "notify-lease-duration" attribute (using the
+ Renew-Subscription operation). In order to change other attributes,
+ a client performs a Subscription Creation Operation and Cancel-
+ Subscription operation on the old Subscription Object. If the client
+ wants to avoid missing Event Notifications, it performs the
+ Subscription Creation Operation first. If this order would create too
+ many Subscription Objects on the Printer, the client reverses the
+ order.
+
+11.2.6.1 Cancel-Subscription Request
+
+ The following groups of attributes are part of the Cancel-
+ Subscription Request:
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.1.
+
+ Target:
+ The "printer-uri" attribute which defines the target for this
+ operation as described in [RFC2911] section 3.1.5.
+
+ "notify-subscription-id" (integer (1:MAX)):
+ The client MUST supply this attribute. The Printer MUST
+ support this attribute. This attribute specifies the
+ Subscription Object that the Printer MUST cancel. If the client
+ omits this attribute, the Printer MUST reject this request with
+ the 'client-error-bad-request' status code.
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 68]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Requesting User Name:
+ The "requesting-user-name" attribute SHOULD be supplied by the
+ client as described in [RFC2911] section 8.3.
+
+11.2.6.2 Cancel-Subscription Response
+
+ The Printer returns the following sets of attributes as part of the
+ Cancel-Subscription Response:
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ Same as [RFC2911].
+
+ The following are some of the status codes returned:
+
+ successful-ok: The operation successfully canceled (deleted) the
+ Subscription Object..
+ client-error-not-found: The operation failed because the "notify-
+ subscription-id" Operation attribute identified a non-existent
+ Subscription Object.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2. The
+ "attributes-natural-language" MAY be the natural language of
+ the Subscription Object, rather than the one requested.
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes.
+
+
+12 Conformance Requirements
+
+ It is OPTIONAL to implement this Event Notification specification.
+
+ If this Event Notification specification is implemented, Printers
+ MUST:
+
+ 1.meet the Conformance Requirements detailed in section 5 of
+ [RFC2911].
+
+ 2.support the Subscription Template Attributes Group in requests
+ and the Subscription Attributes Group in responses.
+
+ 3.support all of the following attributes:
+
+ a. REQUIRED Subscription Object attributes in section 5.
+
+
+Herriot, et al. Expires July 24, 2001 [page 69]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ b. REQUIRED Printer Description object attributes in section 6.
+ c. REQUIRED attributes in Event Notification content in section
+ 8.
+
+ 4.send Event Notifications that conform to the requirements of the
+ Delivery Method Document for each supported Delivery Method (the
+ conformance requirements for Delivery Method Documents is
+ specified in section 10).
+
+ 5.support all operations as described in Table 16:
+
+
+ Table 16 - Conformance Requirements for Operations
+
+
+
+ Operation Conformance
+ requirements
+
+
+ Create-Printer-Subscriptions (section 11.1.2) REQUIRED
+
+ Create-Job-Subscriptions (section 11.1.1) OPTIONAL
+
+ Get-Subscription-Attributes (section 11.2.2) REQUIRED
+
+ Get-Subscriptions (section 11.2.4) REQUIRED
+
+ Renew-Subscription (section 11.2.5) REQUIRED
+
+ Cancel-Subscription (section 11.2.6) REQUIRED
+
+
+
+13 IANA Considerations
+
+ This section contains the exact information for IANA to add to the
+ IPP Registries according to the procedures defined in RFC 2911
+ [RFC2911] section 6.
+
+ Note to RFC Editors: Replace RFC NNNN below with the RFC number
+ for this document, so that it accurately reflects the content of
+ the information for the IANA Registry.
+
+13.1 Attribute Registrations
+
+ The attributes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.2 with
+ the following path:
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 70]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ ftp.isi.edu/iana/assignments/ipp/attributes/
+
+ The registry entry will contain the following information:
+
+ Subscription Template attributes: Ref. Section:
+ notify-recipient-uri (uri) RFC NNNN 5.3.1
+ notify-events (1setOf type2 keyword) RFC NNNN 5.3.2
+ notify-attributes (1setOf type2 keyword) RFC NNNN 5.3.3
+ notify-user-data (octetString(63)) RFC NNNN 5.3.4
+ notify-charset (charset) RFC NNNN 5.3.5
+ notify-natural-language (naturalLanguage) RFC NNNN 5.3.6
+ notify-lease-duration (integer(0:67108863)) RFC NNNN 5.3.7
+ notify-time-interval (integer(0:MAX)) RFC NNNN 5.3.8
+
+ Subscription Description Attributes:
+ notify-subscription-id (integer (1:MAX))) RFC NNNN 5.4.1
+ notify-sequence-number (integer (0:MAX))) RFC NNNN 5.4.2
+ notify-lease-expiration-time (integer(0:MAX))) RFC NNNN 5.4.3
+ notify-printer-up-time (integer(1:MAX))) RFC NNNN 5.4.4
+ notify-printer-uri (uri)) RFC NNNN 5.4.5
+ notify-job-id (integer(1:MAX))) RFC NNNN 5.4.6
+ notify-subscriber-user-name (name(MAX))) RFC NNNN 5.4.7
+
+ Printer Description Attributes:
+ printer-state-change-time (integer(1:MAX))) RFC NNNN 6.1
+ printer-state-change-date-time (dateTime)) RFC NNNN 6.2
+
+ Attributes Only in Event Notifications
+ notify-subscribed-event (type2 keyword) RFC NNNN 8.1
+ notify-text (text(MAX)) RFC NNNN 8.2
+
+13.2 Keyword Attribute Value Registrations
+
+ The keyword attribute values defined in this document will be
+ published by IANA according to the procedures in RFC 2911 [RFC2911]
+ section 6.1 with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attribute-values/
+
+ The registry entry will contain the following information:
+
+ Keyword Attribute Values: Ref. Section:
+ New Values for Existing Printer Description Attributes
+ operations-supported (1setOf type2 enum) RFC NNNN 7.1
+
+13.3 Operation Registrations
+
+ The operations defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.4 with
+ the following path:
+
+
+Herriot, et al. Expires July 24, 2001 [page 71]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ ftp.isi.edu/iana/assignments/ipp/operations/
+
+ The registry entry will contain the following information:
+
+ Operations: Ref. Section:
+ Create-Job-Subscriptions Operation RFC NNNN 11.1.1
+ Create-Printer-Subscriptions operation RFC NNNN 11.1.2
+ Job Creation Operations - Extensions RFC NNNN 11.1.3
+ Validate-Job Operation - Extensions RFC NNNN 11.2.1
+ Get-Printer-Attributes - Extensions RFC NNNN 11.2.2
+ Get-Subscription-Attributes operation RFC NNNN 11.2.3
+ Get-Subscriptions operation RFC NNNN 11.2.4
+ Renew-Subscription operation RFC NNNN 11.2.5
+ Cancel-Subscription operation RFC NNNN 11.2.6
+
+13.4 Status code Registrations
+
+ The status codes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.6 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/status-codes/
+
+ The registry entry will contain the following information:
+
+ Status codes: Ref. Section:
+ successful-ok-ignored-subscriptions (0x0003) RFC NNNN 16.1
+ client-error-ignored-all-subscriptions (0x0414) RFC NNNN 16.2
+
+ Status Codes in Subscription Attributes Groups:
+ client-error-uri-scheme-not-supported (0x040C) RFC NNNN 17.1
+ client-error-too-many-subscriptions (0x0415) RFC NNNN 17.2
+ successful-ok-too-many-events (0x0005) RFC NNNN 17.3
+ successful-ok-ignored-or-substituted-attributes (0x0001)
+ RFC NNNN 17.4
+
+13.5 Attribute Group tag Registrations
+
+ The attribute group tags defined in this document will be published
+ by IANA according to the procedures in RFC 2911 [RFC2911] section 6.5
+ with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/
+
+ The registry entry will contain the following information:
+
+ Attribute Group Tags: Ref. Section:
+ subscription-attributes-tag RFC NNNN 18
+ event-notification-attributes-tag RFC NNNN 18
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 72]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+13.6 Format for Event Notification Delivery Method Registration
+ proposals
+
+ This section describes the procedures for registering Event
+ Notification Delivery Method proposals with IANA to be used with this
+ document. Such Delivery Method proposals that require a new URL
+ scheme MUST be IETF standards track documents according to RFC 2717
+ [RFC2717].
+
+13.7 Format and Requirements for IPP Delivery Method Registration
+ Proposals
+
+ This section defines the format and requirements for an IPP Event
+ Notification Delivery Method Registration Proposal. A Delivery
+ Method Registration Proposal:
+
+ 1.MUST contain the following information:
+
+ Type of registration: IPP Event Notification Delivery Method
+ Name of this delivery method:
+ Proposed URL scheme name of this delivery method:
+ Name of proposer:
+ Address of proposer:
+ Email address of proposer:
+ Is this delivery method REQUIRED or OPTIONAL for conformance to
+ the IPP Event Notification Specification document:
+ Is this delivery method defining Machine Consumable and/or Human
+ Consumable content:
+
+ 2.MUST meet the conformance requirements for Delivery Method
+ Documents specified in section 10.
+
+
+14 Internationalization Considerations
+
+ This IPP Notification specification continues support for the
+ internationalization of [RFC2911] of attributes containing text
+ strings and names. Allowing a Subscribing Client to specify a
+ different natural language and charset for each Subscription Object
+ increases the internationalization support.
+
+ The Printer MUST be able to localize the content of Human Consumable
+ Event Notifications and to localize the value of "notify-text"
+ attribute in Machine Consumable Event Notifications that it sends to
+ Notification Recipients. For localization, the Printer MUST use the
+ value of the "notify-charset" attribute and the "notify-natural-
+ language" attribute in the Subscription Object supplied by the
+ Subscribing Client.
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 73]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+15 Security Considerations
+
+ By far the biggest security concern is the abuse of notification:
+ sending unwanted Event Notifications to third parties (i.e., spam).
+ The problem is made worse by notification addresses that may be
+ redistributed to multiple parties (e.g., mailing lists). There exist
+ scenarios where third party notification is required (see Scenario #2
+ and #3 in [ipp-not-req]). The fully secure solution would require
+ active agreement of all recipients before sending out anything.
+ However, requirement #9 in [ipp-req] ("There is no requirement for
+ IPP Printer receiving the print request to validate the identity of
+ an Event recipient") argues against this. Certain systems may decide
+ to disallow third party Event Notifications (a traditional fax
+ model).
+
+ Clients submitting Notification requests to the IPP Printer has the
+ same security issues as submitting an IPP/1.1 print job request. The
+ same mechanisms used by IPP/1.1 can therefore be used by the client
+ Notification submission. Operations that require authentication can
+ use the HTTP authentication. Operations that require privacy can use
+ the HTTP/TLS privacy.
+
+ The Notification access control model should be similar to the IPP
+ access control model for Jobs. Creating a Per-Printer Subscription
+ Object is associated with a user. Only the creator or an Operator
+ can cancel the Subscription Object. The system may limit the listing
+ of items to only those items owned by the user. Some Subscription
+ Objects (e.g., those that have a lifetime longer than a job) can be
+ done only by privileged users (users having Operator and/or
+ Administrator access rights), if that is the authorization policy.
+
+ The standard security concerns (delivery to the right user, privacy
+ of content, tamper proof content) apply to the Delivery Method. IPP
+ should use the security mechanism of the Delivery Method used. Some
+ delivery mechanisms are more secure than others. Therefore,
+ sensitive Event Notifications should use the Delivery Method that has
+ the strongest security.
+
+
+16 Status Codes
+
+ The following status codes are defined as extensions for Notification
+ and are returned as the value of the "status-code" parameter in the
+ Operation Attributes Group of a response (see [RFC2911] section
+ 3.1.6.1). Operations in this document can also return the status
+ codes defined in section 13 of [RFC2911]. The 'successful-ok' status
+ code is an example of such a status code.
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 74]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+16.1 successful-ok-ignored-subscriptions (0x0003)
+
+ The Subscription Creation Operation was unable to create all
+ requested Subscription Objects.
+
+ For a Create-Job-Subscriptions or Create-Printer-Subscriptions
+ operation, this status code means that the Printer created one or
+ more Subscription Objects, but not all requested Subscription
+ Objects.
+
+ For a Job Creation operation, this status code means that the Printer
+ created the Job along with zero or more Subscription Objects. The
+ Printer returns this status code even if other job attributes are
+ unsupported or in conflict. That is, if an IPP Printer finds a
+ warning that would allow it to return 'successful-ok-ignored-
+ subscriptions' and either 'successful-ok-ignored-or-substituted-
+ attributes' and/or 'successful-ok-conflicting-attributes', it MUST
+ return 'successful-ok-ignored-subscriptions'.
+
+16.2 client-error-ignored-all-subscriptions (0x0414)
+
+ This status code is the same as 'successful-ok-ignored-subscriptions'
+ except that only the Create-Job-Subscriptions and Create-Printer-
+ Subscriptions operation return it. They return this status code only
+ when the Printer creates zero Subscription Objects.
+
+
+17 Status Codes in Subscription Attributes Groups
+
+ This section contains values of the "notify-status-code" (type2 enum)
+ attribute that the Printer returns in a Subscription Attributes Group
+ in a response when the corresponding Subscription Object:
+
+ 1.is not created or
+
+ 2.is created and some of the client-supplied attributes are not
+ supported.
+
+ The following sections are ordered in decreasing order of importance
+ of the status-codes.
+
+17.1 client-error-uri-scheme-not-supported (0x040C)
+
+ This status code is defined in [RFC2911]. This document extends its
+ meaning and allows it to be in a Subscription Attributes Group of a
+ response.
+
+ The scheme of the client-supplied URI in a "notify-recipient-uri"
+ Subscription Template Attribute in a Subscription Creation Operation
+ is not supported. See section 0.
+
+
+Herriot, et al. Expires July 24, 2001 [page 75]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+17.2 client-error-too-many-subscriptions (0x0415)
+
+ The number of Subscription Objects supported by the Printer would be
+ exceeded if this Subscription Object were created (see section 5.2).
+
+17.3 successful-ok-too-many-events (0x0005)
+
+ The client supplied more Events in the "notify-events" operation
+ attribute of a Subscription Creation Operation than the Printer
+ supports, as indicated in its "notify-max-events-supported" Printer
+ attribute (see section 5.3.2).
+
+17.4 successful-ok-ignored-or-substituted-attributes (0x0001)
+
+ This status code is defined in [RFC2911]. This document extends its
+ meaning to include unsupported Subscription Template Attributes and
+ it can appear in a Subscription Attributes Group.
+
+
+18 Encodings of Additional Attribute Tags
+
+ This section assigns values to two attributes tags as extensions to
+ the encoding defined in [RFC2910]).
+
+ The "subscription-attributes-tag" delimits Subscription Template
+ Attributes Groups in requests and Subscription Attributes Groups in
+ responses.
+
+ The "event-notification-attributes-tag" delimits Event Notifications
+ in Delivery Methods that use an IPP-like encoding.
+
+ The following table specifies the values for the delimiter tags:
+
+
+
+ Tag Value (Hex) Meaning
+
+
+ 0x06 "subscription-attributes-tag"
+
+ 0x07 "event-notification-attributes-tag"
+
+
+19 References
+
+ [IANA-CON]
+ Narte, T. and Alvestrand, H.T.: Guidelines for Writing an IANA
+ Considerations Section in RFCs, Work in Progress, draft-iesg-iana-
+ considerations-04.txt, May 21, 1998.
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 76]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ [ipp-not-req]
+ deBry, R., Lewis, H., Hastings, T., "Internet Printing
+ Protocol/1.1: Requirements for IPP Notifications", <draft-ietf-ipp-
+ not-05.txt>, work in progress, January 23, 2001.
+
+ [ipp-prog]
+ Hastings, T., Bergman, R., Lewis, H., "IPP: Job Progress
+ Attributes", <draft-ietf-ipp-job-prog-03.txt> work in
+ progress, January 23, 2001.
+
+ [ipp-set]
+ Kugler, C., Hastings, T., Herriot, R., Lewis, H, "Internet Printing
+ Protocol (IPP): Job and Printer Set Operations", <draft-ietf-ipp-
+ job-printer-set-ops-03.txt>, work in progress, January 22, 2001.
+
+ [RFC2026]
+ S. Bradner, "The Internet Standards Process -- Revision 3", RFC
+ 2026, October 1996.
+
+ [RFC2119]
+ S. Bradner, "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119 , March 1997
+
+ [RFC2566]
+ deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
+ "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
+ April 1999.
+
+ [RFC2567]
+ Wright, D., "Design Goals for an Internet Printing Protocol", RFC
+ 2567, April 1999.
+
+ [RFC2568]
+ Zilles, S., "Rationale for the Structure and Model and Protocol for
+ the Internet Printing Protocol", RFC 2568, April 1999.
+
+ [RFC2569]
+ Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
+ LPD and IPP Protocols", RFC 2569, April 1999.
+
+ [RFC2717]
+ R. Petke and I. King, "Registration Procedures for URL Scheme
+ Names", RFC 2717, November 1999.
+
+ [RFC2910]
+ Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 77]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ [RFC2911]
+ deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
+ "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911,
+ September 2000.
+
+
+20 Author's Addresses
+
+ Robert Herriot
+ Xerox Corporation
+ 3400 Hillview Ave., Bldg #1
+ Palo Alto, CA 94304
+
+ Phone: 650-813-7696
+ Fax: 650-813-6860
+ Email: robert.herriot@pahv.xerox.com
+
+ Tom Hastings
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+
+ Scott A. Isaacson
+ Novell, Inc.
+ 122 E 1700 S
+ Provo, UT 84606
+
+ Phone: 801-861-7366
+ Fax: 801-861-2517
+ e-mail: sisaacson@novell.com
+
+
+ Roger deBry
+ Utah Valley State College
+ Orem, UT 84058
+
+ Phone: (801) 222-8000
+ EMail: debryro@uvsc.edu
+
+ Jay Martin
+ Underscore Inc.
+ 9 Jacqueline St.
+ Hudson, NH 03051-5308
+ 603-889-7000
+ fax: 775-414-0245
+
+
+Herriot, et al. Expires July 24, 2001 [page 78]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ e-mail: jkm@underscore.com
+
+
+ Michael Shepherd
+ Xerox Corporation
+ 800 Phillips Road MS 128-51E
+ Webster, NY 14450
+
+ Phone: 716-422-2338
+ Fax: 716-265-8871
+ e-mail: mshepherd@crt.xerox.com
+
+
+ Ron Bergman
+ Hitachi Koki Imaging Solutions
+ 1757 Tapo Canyon Road
+ Simi Valley, CA 93063-3394
+
+ Phone: 805-578-4421
+ Fax: 805-578-4001
+ Email: rbergma@hitachi-hkis.com
+
+A. Appendix - Model for Notification with Cascading Printers
+
+ With this model (see Figure 2), there is an intervening Print server
+ between the human user and the output-device. So the system
+ effectively has two Printers. There are two cases to consider.
+
+ 1.When the Printer 1 (in the server) generates Events, the system
+ behaves like the client and Printer in Figure 1. In this case,
+ Printer 1 sends Event Notifications that are shown as Event
+ Notifications (A) of Figure 2,.
+
+ 2.When the Printer 2 (in the output-device) generates Events, there
+ are two possible system configurations:
+
+ a)Printer 1 forwards the client-supplied Subscription Creation
+ Operations to the downstream Printer 2 and lets Printer 2 send
+ the Event Notifications directly to the Notification Recipients
+ supplied by the Client (Event Notifications(C) in the diagram).
+
+ b)Printer 1 performs the client-supplied Subscription Creation
+ Operations and also forwards the Subscription Creation
+ Operations to Printer 2 with the Notification Recipient changed
+ to be the Printer 1. When an Event occurs in Printer 2, Printer
+ 2 sends the Event Notification (B) to Notification Recipient of
+ Printer 1, which relays the received Event Notification (B) to
+ the client-supplied Notification Recipient (as Event
+ Notifications(A) in the diagram). Note, when a client performs a
+ Subscription Creation Operation, Printer 1 need not forward the
+
+
+Herriot, et al. Expires July 24, 2001 [page 79]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ Subscription Creation Operation to Printer 2 if it would create
+ a duplicate Subscription Object on Printer 2.
+
+ Note: when Printer 1 is forwarding Subscription Creation Operations
+ to Printer 2, it may request Printer 2 to create additional
+ Subscription Objects (called "piggy-backing"). Piggy-backing is
+ useful when:
+
+ . Device A is configured to accept (IPP or non-IPP) requests from
+ other servers.
+
+ . Server S wants to receive Job Events that the client didn't
+ request and Server S wants these Events for jobs it submits and
+ not for other jobs.
+
+ server S device A
+ +------------+ +------------+
+ | | | |
+ +--------+ Subscription | ###########| | ###########|
+ | client |--Creation ----># Printer #| Subscription | # Printer #|
+ +--------+ Operation | # Object 1#|---Creation------|># Object 2#|
+ | ###|#######| Operation | ####|#|####|
+ +----|---^---+ +-----|-|----+
+ +--------+ Event | | | |
+ |Notific-|<-Notifications(A)-+ +-- Event Notifications(B)--+ |
+ |ation Re|<-------------Event Notifications(C)-----------------+
+ |cipient |
+ +--------+
+
+ Figure 2 - Model for Notification with Cascading Printers
+
+
+B. Appendix - Distributed Model for Notification
+
+ A Printer implementation could use some other remote notification
+ service to provide some or most of the service. For example, the
+ remote notification service could send Event Notifications using
+ Delivery Methods that are not directly supported by the output device
+ or server. Or, the remote notification service could store
+ Subscription Objects (passed to it from the output device in response
+ to Subscription Creation requests), accept Events, format the Event
+ Notification in the natural language of the Notification Recipient,
+ and send the Event Notifications to the Notification Recipient(s).
+
+ Figure 3 shows this partitioning. The interface between the output
+ device (or server) and the remote notification service is outside the
+ scope of this document and is intended to be transparent to the
+ client and this document. The combination of the output device (or
+ server) and the notification service together constitute an IPP
+ Printer conforming to this Notification document.
+
+
+Herriot, et al. Expires July 24, 2001 [page 80]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+
+
+ ***********************
+ *
+ * Printer (including
+ * the distributed
+ * Notification Service)
+ *
+ * output device or server
+ * +---------------+
+ PDA, desktop, or server * + ########### +
+ +--------+ * | # partial # |
+ | client |---IPP Subscription--------># Printer # |
+ +--------+ Creation operation * | # Object # |
+ * | #####|##### |
+ * +-------|-------+
+ * | Subscriptions
+ * | OR Event
+ +------------+ * | Notifications
+ |Notification| IPP-defined * +------v--------+
+ |Recipient |<--Event Notifications---| Notification |
+ +------------+ * | Service |
+ * +---------------+
+ *
+ *************************
+ *** = Implementation configuration opaque boundary
+
+
+ Figure 3 - Opaque Use of a Notification Service Transparent to the
+ Client
+
+
+C. Appendix - Extended Notification Recipient
+
+ The model allows for an extended Notification Recipient that is
+ itself a notification service that forwards each Event Notification
+ to another recipient (called the Ultimate Notification Recipient in
+ this section). The Delivery Method to the Ultimate Recipient is
+ probably different from the Delivery Method used by the Printer to
+ the extended Notification Recipient.
+
+ This extended Notification Recipient is transparent to the Printer
+ but not to the client.
+
+ When a client performs a Subscription Creation Operation, it
+ specifies the extended Notification Recipient as it would any
+ Notification Recipient. In addition, the client specifies the
+ Ultimate Notification Recipient in the Subscription Creation
+ Operation in a manner specified by the extended Notification
+ Recipient. Typically, it is either some bytes in the value of
+
+
+Herriot, et al. Expires July 24, 2001 [page 81]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ "notify-user-data" or some additional parameter in the value of
+ "notify-recipient-uri". The client also subscribes directly with the
+ extended Notification Recipient (by means outside this document),
+ since it is a notification service in its own right.
+
+ The IPP Printer treats the extended Notification Recipient like any
+ other Notification Recipient and the IPP Printer is not aware of the
+ forwarding. The Delivery Method that the extended Notification
+ Recipient uses for delivering the Event Notification to the Ultimate
+ Notification Recipient is beyond the scope of this document and is
+ transparent to the IPP Printer.
+
+ Examples of this extended Notification Recipient are paging,
+ immediate messaging services, general notification services, and NOS
+ vendors' infrastructure. Figure 4 shows this approach.
+
+
+ PDA, desktop, or server server or output device
+ +---------------+
+ +--------+ | ########### |
+ | client |---Subscription Creation -----------># Printer # |
+ +--------+ Operation | # Object # |
+ | #####|##### |
+ +------------+ +------------+ IPP-defined +-------|-------+
+ |Ultimate | any |Notification|<--Event Notifications----+
+ |Notification|<----|Recipient |
+ |Recipient | +------------+
+ +------------+ (Notification Service)
+
+ Figure 4 - Use of an Extended Notification Recipient transparent to
+ the Printer
+
+
+D. Appendix - Details about Conformance Terminology
+
+ The following paragraph provide more details about conformance
+ terminology.
+
+ REQUIRED - an adjective used to indicate that a conforming IPP
+ Printer implementation MUST support the indicated operation,
+ object, attribute, attribute value, status code, or out-of-band
+ value in requests and responses. See [RFC2911] "Appendix A -
+ Terminology for a definition of "support". Since support of this
+ entire Notification specification is OPTIONAL for conformance to
+ IPP/1.0 or IPP/1.1, the use of the term REQUIRED in this document
+ means "REQUIRED if this OPTIONAL Notification specification is
+ implemented".
+
+ RECOMMENDED - an adjective used to indicate that a conforming IPP
+ Printer implementation is recommended to support the indicated
+
+
+Herriot, et al. Expires July 24, 2001 [page 82]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ operation, object, attribute, attribute value, status code, or
+ out-of-band value in requests and responses. Since support of
+ this entire Notification specification is OPTIONAL for conformance
+ to IPP/1.0 or IPP/1.1, the use of the term RECOMMENDED in this
+ document means "RECOMMENDED if this OPTIONAL Notification
+ specification is implemented".
+
+ OPTIONAL - an adjective used to indicate that a conforming IPP
+ Printer implementation MAY, but is NOT REQUIRED to, support the
+ indicated operation, object, attribute, attribute value, status
+ code, or out-of-band value in requests and responses.
+
+
+E. Appendix - Object Model for Notification
+
+ This section describes the Notification object model that adds a
+ Subscription Object which together with the Job and Printer object
+ provide the complete Notification semantics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 83]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ The object relationships can be seen pictorially as:
+
+
+ Subscription Objects (Per-Printer Subscriptions) Printer object
+ +----+ +------------+
+ | s1 |<--------------------------------------------->| |
+ +----++ | |
+ | s2 |<-------------------------------------------->| p1 |
+ +----++ | |
+ | s3 |<------------------------------------------->| |
+ +----+ +------------+
+ Job objects
+ +---------+
+ | |
+ +----+ | j1 |
+ | s4 |<------->| |
+ +----+ | |
+ | | s4 is a Per-Job Subscription Object
+ ++--------++
+ | |
+ +----+ | j2 |
+ | s5 |<------>| |
+ +----++ | |
+ | s6 |<----->| | s5 and s6 are Per-Job Subscription
+ +----+ ++--------++ Objects
+ | |
+ | j3 |
+ | |
+ | | <----> indicates association
+ +---------+
+
+ Figure 5 - Object Model for Notification
+
+ s1, s2, and s3 are Per-Printer Subscription Objects and can
+ identify Printer and/or Job Events.
+ s4, s5, and s6 are Per-Job Subscription Objects and can identify
+ Printer and/or Job Events.
+
+E.1 Appendix - Object relationships
+
+ This sub-section defines the object relationships between the
+ Printer, Job, and Subscription Objects by example. Whether Per-
+ Printer Subscription Objects are actually contained in a Printer
+ object or are just bi-directionally associated with them in some way
+ is IMPLEMENTATION DEPENDENT and is transparent to the client.
+ Similarly, whether Per-Job Subscription Objects are actually
+ contained in a Job object or are just bi-directionally associated
+ with them in some way is IMPLEMENTATION DEPENDENT and is transparent
+ to the client. The object relationships are defined as follows:
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 84]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+E.2 Printer Object and Per-Printer Subscription Objects
+
+ 1.The Printer object contains (is associated with) zero or more
+ Per-Printer Subscription Objects (p1 contains s1-s3 Per-Printer
+ Subscription Objects).
+
+ 2.Each Per-Printer Subscription Object (s1, s2, and s3) is
+ contained in (or is associated with) exactly one Printer object
+ (p1).
+
+
+E.3 Job Object and Per-Job Subscription Objects
+
+ 1.A Job object (j1, j2, j3) is associated with zero or more Per-
+ Job Subscription Objects (s4-s6). Job j1 is associated with
+ Per-Job Subscription Object s4, Job j2 is associated with Per-
+ Job Subscription Objects s5 and s6, and Job j3 is not associated
+ with any Per-Job Subscription Object.
+
+ 2.Each Per-Job Subscription Object is associated with exactly one
+ Job object.
+
+
+F. Appendix - Per-Job versus Per-Printer Subscription Objects
+
+ Per-Job and Per-Printer Subscription Objects are quite similar.
+ Either type of Subscription Object can subscribe to Job Events,
+ Printer Events, or both. Both types of Subscription Objects can be
+ queried using the Get-Subscriptions and Get-Subscription-Attributes
+ operations and canceled using the Cancel-Subscription operation.
+ Both types of Subscription Objects create Subscription Objects which
+ have the same Subscription Object attributes defined. However, there
+ are some semantic differences between Per-Job Subscription Objects
+ and Per-Printer Subscription Objects. A Per-Job Subscription Object
+ is established by the client when submitting a job and after creating
+ the job using the Create-Job-Subscriptions operation by specifying
+ the "job-id" of the Job with the "notify-job-id" attribute. A Per-
+ Printer Subscription Object is established between a client and a
+ Printer using the Create-Printer-Subscriptions operation. Some
+ specific differences are:
+
+ 1.A client usually creates one or more Per-Job Subscription
+ Objects as part of the Job Creation operations (Create-Job,
+ Print-Job, and Print-URI), rather than using the OPTIONAL
+ Create-Job-Subscriptions operation, especially since Printer
+ implementations NEED NOT support the Create-Job-Subscriptions
+ operation, since it is OPTIONAL.
+
+ 2.For Per-Job Subscription Objects, the Subscription Object is
+ only valid while the job is "not-complete" (see sections 5.4.3)
+
+
+Herriot, et al. Expires July 24, 2001 [page 85]
+\f
+
+INTERNET-DRAFT IPP: Event Notification January 24, 2001
+
+
+ while for the Per-Printer Subscription Objects, the Subscription
+ Object is valid until the time (in seconds) that the Printer
+ returned in the "notify-lease-expiration-time" operation
+ attribute.
+
+ 3.Job Events in a Per-Job Subscription Object apply only to "one
+ job" (the Job created by the Job Creation operation or
+ references by the Create-Job-Subscriptions operation) while Job
+ Events in a Per-Printer Subscription Object apply to ALL jobs
+ contained in the IPP Printer.
+
+
+G. Appendix: Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998,1999,2000,2001). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires July 24, 2001 [page 86]
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Robert Herriot (editor)
+<draft-ietf-ipp-notify-get-02.txt> Xerox Corp.
+[Target category: standards track] Carl Kugler
+ IBM, Corp.
+ Harry Lewis
+ IBM, Corp.
+ February 28, 2001
+ Internet Printing Protocol (IPP):
+ The 'ippget' Delivery Method for Event Notifications
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Status of this Memo:
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of [rfc2026]. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed as
+ http://www.ietf.org/shadow.html.
+
+Abstract
+
+ The notification extension document [ipp-ntfy] defines operations
+ that a client can perform in order to create Subscription Objects in
+ a Printer and carry out other operations on them. A Subscription
+ Object represents a Subscription abstraction. The Subscription Object
+ specifies that when one of the specified Events occurs, the Printer
+ sends an asynchronous Event Notification to the specified
+ Notification Recipient via the specified Delivery Method (i.e.,
+ protocol).
+
+ The notification extension document [ipp-ntfy] specifies that each
+ Delivery Method is defined in another document. This document is one
+ such document, and it specifies the 'ippget' delivery method.
+
+ The 'ippget' Delivery Method is a 'pull and push' Delivery Method.
+ That is, the Printer saves Event Notification for a period of time
+ and expects the Notification Recipient to fetch the Event
+ Notifications (the pull part). The Printer continues to send Event
+
+Herriot, et al. Expires: August 28, 2001 [page 1]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Notifications to the Notification Recipient as Events occur (the push
+ part) if the client has selected the option to wait for additional
+ Event Notifications.
+
+ When a Printer supports this Delivery Method, it holds each Event
+ Notification for an amount of time, called the Event Notification
+ Lease Time.
+
+ When a Notification Recipient wants to receive Event Notifications,
+ it performs an IPP operation called 'Get-Notifications', which this
+ document defines. This operation causes the Printer to return all
+ Event Notifications held for the Notification Recipient. If the
+ Notification Recipient has selected the option to wait for additional
+ Event Notifications, the Printer continues sending Event
+ Notifications to the Notification Recipient as additional Events
+ occur.
+
+
+
+ The basic 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.1: Model and Semantics [RFC2911]
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+ Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
+ Mapping between LPD and IPP Protocols [RFC2569]
+ Internet Printing Protocol/1.0 & 1.1: IPP Event Notification
+ Specification [ipp-ntfy]
+
+ The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that
+ are satisfied in IPP/1.0. A few OPTIONAL operator operations have
+ been added to IPP/1.1.
+
+ The "Rationale for the Structure and Model and Protocol for the
+ Internet Printing Protocol" document describes IPP from a high level
+ view, defines a roadmap for the various documents that form the suite
+ of IPP specification documents, and gives background and rationale
+ for the IETF working group's major decisions.
+
+ The "Internet Printing Protocol/1.1: Model and Semantics" document
+ describes a simplified model with abstract objects, their attributes,
+ and their operations that are independent of encoding and transport.
+ It introduces a Printer and a Job object. The Job object optionally
+
+Herriot, et al. Expires: August 28, 2001 [page 2]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ supports multiple documents per Job. It also addresses security,
+ internationalization, and directory issues.
+
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document
+ is a formal mapping of the abstract operations and attributes defined
+ in the model document onto HTTP/1.1 [RFC2616]. It defines the
+ encoding rules for a new Internet MIME media type called
+ "application/ipp". This document also defines the rules for
+ transporting over HTTP a message body whose Content-Type is
+ "application/ipp". This document defines a new scheme named 'ippget'
+ for identifying IPP printers and jobs.
+
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document
+ gives insight and advice to implementers of IPP clients and IPP
+ objects. It is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some
+ advice to implementers of gateways between IPP and LPD (Line Printer
+ Daemon) implementations.
+
+ The "Event Notification Specification" document describes an
+ extension to the IPP/1.0, IPP/1.1, and future versions. This
+ extension allows a client to subscribe to printing related Events.
+ Subscriptions are modeled as Subscription Objects. The Subscription
+ Object specifies that when one of the specified Event occurs, the
+ Printer sends an asynchronous Event Notification to the specified
+ Notification Recipient via the specified Delivery Method (i.e.,
+ protocol). A client associates Subscription Objects with a
+ particular Job by performing the Create-Job-Subscriptions operation
+ or by submitting a Job with subscription information. A client
+ associates Subscription Objects with the Printer by performing a
+ Create-Printer-Subscriptions operation. Four other operations are
+ defined for Subscription Objects: Get-Subscriptions-Attributes, Get-
+ Subscriptions, Renew-Subscription, and Cancel-Subscription.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 3]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+
+Table of Contents
+
+
+ 1 Introduction....................................................6
+
+ 2 Terminology.....................................................6
+
+ 3 Model and Operation.............................................7
+
+ 4 General Information.............................................8
+
+ 5 Get-Notifications operation....................................10
+ 5.1 Get-Notifications Request...................................12
+ 5.2 Get-Notifications Response..................................13
+
+ 6 Subscription Template Attributes...............................18
+ 6.1 Subscription Template Attribute Conformance.................18
+ 6.2 Additional Information about Subscription Template Attributes18
+ 6.2.1 notify-recipient-uri (uri)................................18
+ 6.3 Subscription Description Attribute Conformance..............19
+
+ 7 Additional Printer Description Attributes......................19
+ 7.1 Printer Description Attribute Conformance...................19
+ 7.2 New Values for Existing Printer Description Attributes......19
+ 7.2.1 notify-schemes-supported (1setOf uriScheme)...............19
+ 7.2.2 operations-supported (1setOf type2 enum)..................19
+ 7.3 begin-to-expire-time-interval (integer(0:MAX))..............20
+
+ 8 New Status Codes...............................................20
+ 8.1 redirection-other-site (0x300)..............................21
+
+ 9 The IPPGET URL Scheme..........................................21
+ 9.1 The IPPGET URL Scheme Applicability and Intended Usage......21
+ 9.2 The IPPGET URL Scheme Associated Port.......................21
+ 9.3 The IPPGET URL Scheme Associated MIME Type..................21
+ 9.4 The IPPGET URL Scheme Character Encoding....................22
+ 9.5 The IPPGET URL Scheme Syntax in ABNF........................22
+ 9.5.1 IPPGET URL Examples.......................................23
+ 9.5.2 IPPGET URL Comparisons....................................23
+
+ 10 Encoding.......................................................24
+
+ 11 Conformance Requirements.......................................24
+ 11.1 Conformance for IPP Printers................................24
+ 11.2 Conformance for IPP Clients.................................25
+
+ 12 IANA Considerations............................................25
+ 12.1 Operation Registrations.....................................26
+ 12.2 Additional values of existing attributes....................26
+
+Herriot, et al. Expires: August 28, 2001 [page 4]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ 12.2.1 Additional values for the "notify-schemes-supported" Printer
+ attribute..............................................26
+ 12.2.2 Additional values for the "operations-supported" Printer
+ attribute..............................................26
+ 12.3 Attribute Registrations.....................................27
+ 12.4 Status code Registrations...................................27
+
+ 13 Internationalization Considerations............................27
+
+ 14 Security Considerations........................................27
+
+ 15 References.....................................................28
+
+ 16 Authors' Addresses.............................................29
+
+ 17 Full Copyright Statement.......................................30
+
+
+Table of Tables
+
+ Table 1 - Information about the Delivery Method....................9
+
+ Table 2 - Attributes in Event Notification Content................16
+
+ Table 3 - Additional Attributes in Event Notification Content for Job
+
+ Events ........................................................17
+
+ Table 4 - Combinations of Events and Subscribed Events for "job-
+
+ impressions-completed" ........................................17
+
+ Table 5 - Additional Attributes in Event Notification Content for
+
+ Printer Events ................................................18
+
+ Table 6 - Operation-id assignments................................20
+
+ Table 7 - The "event-notification-attributes-tag" value...........24
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 5]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+1 Introduction
+
+ The notification extension document [ipp-ntfy] defines operations
+ that a client can perform in order to create Subscription Objects in
+ a Printer and carry out other operations on them. A Subscription
+ Object represents a Subscription abstraction. The Subscription Object
+ specifies that when one of the specified Events occurs, the Printer
+ sends an asynchronous Event Notification to the specified
+ Notification Recipient via the specified Delivery Method (i.e.,
+ protocol).
+
+ The notification extension document [ipp-ntfy] specifies that each
+ Delivery Method is defined in another document. This document is one
+ such document, and it specifies the 'ippget' delivery method.
+
+ The 'ippget' Delivery Method is a 'pull and push' Delivery Method.
+ That is, the Printer saves Event Notification for a period of time
+ and expects the Notification Recipient to fetch the Event
+ Notifications (the pull part). The Printer continues to send Event
+ Notifications to the Notification Recipient as Events occur (the push
+ part) if the client has selected the option to wait for additional
+ Event Notifications.
+
+ When a Printer supports this Delivery Method, it holds each Event
+ Notification for an amount of time, called the Event Notification
+ Lease Time.
+
+ When a Notification Recipient wants to receive Event Notifications,
+ it performs an IPP operation called 'Get-Notifications', which this
+ document defines. This operation causes the Printer to return all
+ Event Notifications held for the Notification Recipient. If the
+ Notification Recipient has selected the option to wait for additional
+ Event Notifications, the Printer the Printer continues to send Event
+ Notifications to the Notification Recipient as Events occur.
+
+
+2 Terminology
+
+ This section defines the following terms that are used throughout
+ this document:
+
+ Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+ NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+ conformance to this specification. These terms are defined in
+ [RFC2911 section 13.1 on conformance terminology, most of which is
+ taken from RFC 2119 [RFC2119].
+
+ Event Notification Lease: The lease that is associated with an Event
+ Notification. When the lease expires, the Printer discards the
+ associated Event Notification.
+
+Herriot, et al. Expires: August 28, 2001 [page 6]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Event Notification Lease Time: The expiration time assigned to a
+ lease that is associated with an Event Notification.
+
+ Event Notification Attributes Group: The attributes group in a
+ response that contains attributes that are part of an Event
+ Notification.
+
+ For other capitalized terms that appear in this document, see [ipp-
+ ntfy].
+
+
+3 Model and Operation
+
+ In a Subscription Creation Operation, when the value of the "notify-
+ recipient-uri" attribute has the scheme 'ippget', the client is
+ requesting that the Printer use the 'ippget' Delivery Method for the
+ Event Notifications associated with the new Subscription Object. The
+ client SHOULD choose a value for the address part of the "notify-
+ recipient-uri" attribute that uniquely identifies the Notification
+ Recipient.
+
+ When an Event occurs, the Printer MUST generate an Event Notification
+ and MUST assign it the Event Notification Lease Time. The Printer
+ MUST hold an Event Notification for its assigned Event Notification
+ Lease Time. The Printer MUST assign the same Event Notification
+ Lease Time to each Event Notification.
+
+ When a Notification Recipient wants to receive Event Notifications,
+ it performs the Get-Notifications operation, which causes the Printer
+ to return all un-expired Event Notifications held for the
+ Notification Recipient. If the Notification Recipient has selected
+ the option to wait for additional Event Notifications, the response
+ to the Get-Notifications request continues indefinitely as the
+ Printer continues to send Event Notifications in the response as
+ Events occur. For the Get-Notification operation, the Printer sends
+ only those Event Notifications that are generated from Subscription
+ Objects whose "notify-recipient-uri" attribute value equals the value
+ of the "notify-recipient-uri" Operation Attribute in the Get-
+ Notifications operation.
+
+ If a Notification Recipient performs the Get-Notifications operation
+ twice in quick succession, it will receive nearly the same Event
+ Notification both times because most of the Event Notifications are
+ those that the Printer saves for a few seconds after the Event
+ occurs. There are two possible differences. Some old Event
+ Notifications may not be present in the second response because their
+ Event Notification Leases have expired. Some new Event Notifications
+ may be present in the second response but not the first response.
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 7]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ When the Notification Recipient requests Event Notifications for per-
+ Job Subscription Objects, the Notification Recipient typically
+ performs the Get-Notifications operation within a second of
+ performing the Subscription Creation operation. Because the Printer
+ is likely to save Event Notifications for several seconds, the
+ Notification Recipient is unlikely to miss any Event Notifications
+ that occur between the Subscription Creation and the Get-
+ Notifications operation.
+
+
+4 General Information
+
+ If a Printer supports this Delivery Method, the following are its
+ characteristics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 8]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Table 1 - Information about the Delivery Method
+
+
+ Document Method Conformance Delivery Method Realization
+ Requirement
+
+
+ 1. What is the URL scheme name ippget
+ for the Delivery Method?
+
+ 2. Is the Delivery Method RECOMMENDED
+ REQUIRED, RECOMMENDED or
+ OPTIONAL for an IPP Printer
+ to support?
+
+ 3. What transport and delivery
+ protocols does the Printer
+ use to deliver the Event
+ Notification Content, i.e.,
+ what is the entire network IPP with one new operation.
+ stack?
+
+ 4. Can several Event Yes.
+ Notifications be combined
+ into a Compound Event
+ Notification?
+
+ 5. Is the Delivery Method This Delivery Method is a pull
+ initiated by the Notification and a push.
+ Recipient (pull), or by the
+ Printer (push)?
+
+ 6. Is the Event Notification Machine Consumable
+ content Machine Consumable or
+ Human Consumable?
+
+ 7. What section in this document Section 5
+ answers the following
+ question? For a Machine
+ Consumable Event
+ Notification, what is the
+ representation and encoding
+ of values defined in section
+ 9.1 of [ipp-ntfy] and the
+ conformance requirements
+ thereof? For a Human
+ Consumable Event
+ Notification, what is the
+ representation and encoding
+
+
+Herriot, et al. Expires: August 28, 2001 [page 9]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+
+ of pieces of information
+ defined in section 9.2 of
+ [ipp-ntfy] and the
+ conformance requirements
+ thereof?
+
+ 8. What are the latency and Same as IPP and the underlying
+ reliability of the transport HTTP transport
+ and delivery protocol?
+
+ 9. What are the security aspects Same as IPP and the underlying
+ of the transport and delivery HTTP transport
+ protocol, e.g., how it is
+ handled in firewalls?
+
+ 10. What are the content length None
+ restrictions?
+
+ 11. What are the additional None
+ values or pieces of
+ information that a Printer
+ sends in an Event
+ Notification content and the
+ conformance requirements
+ thereof?
+
+ 12. What are the additional None
+ Subscription Template and/or
+ Subscription Description
+ attributes and the
+ conformance requirements
+ thereof?
+
+ 13. What are the additional None
+ Printer Description
+ attributes and the
+ conformance requirements
+ thereof?
+
+
+
+
+5 Get-Notifications operation
+
+ This operation causes the Printer to return all Event Notifications
+ held for the Notification Recipient.
+
+ A Printer MUST support this operation.
+
+
+Herriot, et al. Expires: August 28, 2001 [page 10]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ When a Printer performs this operation, it MUST return all and only
+ those Event Notifications:
+
+ 1. Whose associated Subscription Object's "notify-recipient-uri"
+ attribute equals the "notify-recipient-uri" Operation attribute
+ AND
+
+ 2. Whose associated Subscription Object's "notify-recipient-uri"
+ attribute has a scheme value of 'ippget' AND
+
+ 3. Whose Event Notification Lease Time has not yet expired AND
+
+ 4. Where the Notification Recipient is the owner of or has read-
+ access rights to the associated Subscription Object.
+
+ The Printer MUST respond to this operation immediately with whatever
+ Event Notifications it currently holds. If the Notification Recipient
+ has selected the option to wait for additional Event Notifications,
+ the Printer MUST continue to send Event Notifications as they occur
+ until all of the associated Subscription Objects are cancelled. A
+ Subscription Object is cancelled either via the Cancel-Subscription
+ operation or by the Printer (e.g. the Subscription Object is
+ cancelled when the associated Job completes).
+
+ Note, the Printer terminates the operation in the same way that it
+ normally terminates IPP operations. For example, if the Printer is
+ sending chunked data, it can send a 0 length chunk to denote the end
+ of the operation or it can close the connection. If the Notification
+ Recipient wishes to terminate the Get-Notifications operation, it can
+ close the connection.
+
+ The Printer MUST accept the request in any state (see [RFC2911]
+ "printer-state" and "printer-state-reasons" attributes) and MUST
+ remain in the same state with the same "printer-state-reasons"
+ values.
+
+ Access Rights: If the policy of the Printer is to allow all users to
+ access all Event Notifications, then the Printer MUST accept this
+ operation from any user. Otherwise, the authenticated user (see
+ [RFC2911] section 8.3) performing this operation MUST either be the
+ owner of each Subscription Object identified by the "notify-
+ recipient-uri" Operation attribute (as determined during a
+ Subscription Creation Operation) or an operator or administrator of
+ the Printer (see [RFC2911] Sections 1 and 8.5). Otherwise, the IPP
+ object MUST reject the operation and return: 'client-error-
+ forbidden', 'client-error-not-authenticated', or 'client-error-not-
+ authorized' status code as appropriate.
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 11]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+5.1 Get-Notifications Request
+
+ The following groups of attributes are part of the Get-Notifications
+ Request:
+
+ Group 1: Operation Attributes
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.1.
+
+ Target:
+ The "printer-uri" (uri) operation attribute which is the target
+ for this operation as described in [RFC2911] section 3.1.5.
+
+ Requesting User Name:
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be
+ supplied by the client as described in [RFC2911] section 8.3.
+
+ "notify-recipient-uri" (url):
+ The client MUST supply this attribute. The Printer object MUST
+ support this attribute. The Printer matches the value of this
+ attribute (byte for byte with no case conversion) against the
+ value of the "notify-recipient-uri" in each Subscription Object
+ in the Printer. If there are no matches, the IPP Printer MUST
+ return the 'client-error-not-found' status code. For each
+ matched Subscription Object, the IPP Printer MUST return all
+ unexpired Event Notifications associated with it. The Printer
+ MUST send additional Event Notifications as Events occur if and
+ only if the value of the "notify-no-wait" attribute is 'false'
+ or not supplied by the client (see the next attribute below).
+
+ Note: this attribute allows a subscribing client to pick URLs
+ that are unique, e.g. the client's own URL or a friend's URL,
+ which in both cases is likely the URL of the person's host. An
+ application could make a URL unique for each application.
+
+ "notify-no-wait" (boolean):
+ The client MAY supply this attribute. The Printer object MUST
+ support this attribute. If the value of this attribute is
+ 'false', the Printer MUST send all un-expired Event
+ Notifications (as defined in the previous attribute) and it
+ MUST continue to send responses for as long as the Subscription
+ Objects associated with the specified "notify-recipient-uri"
+ continue to exist. If the value of this attribute is 'true',
+ the Printer MUST send all un-expired Event Notifications (as
+ defined in the previous attribute) and the Printer MUST
+ conclude the operation without waiting for any additional
+ Events to occur. If the client doesn't supply this attribute,
+
+
+Herriot, et al. Expires: August 28, 2001 [page 12]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ the Printer MUST behave as if the client had supplied this
+ attribute with the value of 'false'.
+
+5.2 Get-Notifications Response
+
+ The following groups of attributes are part of the Get-Notifications
+ Response:
+
+ Group 1: Operation Attributes
+
+ Status Message:
+ In addition to the REQUIRED status code returned in every
+ response, the response OPTIONALLY includes a "status-message"
+ (text(255)) and/or a "detailed-status-message" (text(MAX))
+ operation attribute as described in [RFC2911] sections 13 and
+ 3.1.6.
+
+ The Printer can return any status codes defined in [RFC2911].
+ If the status code is not 'successful-', the Printer MUST NOT
+ return any Event Notification Attribute groups. The following
+ is a description of the important status codes:
+
+ successful-ok: the response contains all Event Notification
+ associated with the specified "notify-recipient-uri". If
+ the specified Subscription Objects have no associated
+ Event Notification, the response MUST contain zero Event
+ Notifications.
+ client-error-not-found: The Printer has no Subscription
+ Object's whose "notify-recipient-uri" attribute equals
+ the "notify-recipient-uri" Operation attribute.
+ server-error-busy: The Printer is too busy to accept this
+ operation. If the "suggested-ask-again-time-interval"
+ operation attribute is present in the Operation
+ Attributes of the response, then the Notification
+ Recipient SHOULD wait for the number of seconds specified
+ by the "suggested-ask-again-time-interval" attribute
+ before performing this operation again. If the
+ "suggested-ask-again-time-interval" Operation Attribute
+ is not present, the Notification Recipient should use the
+ normal network back-off algorithms for determining when
+ to perform this operation again.
+ redirection-other-site: The Printer does not handle this
+ operation and requests the Notification Recipient to
+ perform the operation with the uri specified by the
+ "notify-ippget-redirect" Operation Attribute in the
+ response.
+
+ Natural Language and Character Set:
+ The "attributes-charset" and "attributes-natural-language"
+ attributes as described in [RFC2911] section 3.1.4.2.
+
+Herriot, et al. Expires: August 28, 2001 [page 13]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+
+ The Printer MUST use the values of "notify-charset" and
+ "notify-natural-language", respectively, from one Subscription
+ Object associated with the Event Notifications in this
+ response.
+
+ Normally, there is only one matched Subscription Object, or the
+ value of the "notify-charset" and "notify-natural-language"
+ attributes is the same in all Subscription Objects. If not, the
+ Printer MUST pick one Subscription Object from which to obtain
+ the value of these attributes. The algorithm for picking the
+ Subscription Object is implementation dependent. The choice of
+ natural language is not critical because 'text' and 'name'
+ values can override the "attributes-natural-language" Operation
+ attribute. The Printer's choice of charset is critical because
+ a bad choice may leave it unable to send some 'text' and 'name'
+ values accurately.
+
+ "printer-up-time" (integer(0:MAX)):
+ The value of this attribute is the Printer's "printer-up-time"
+ attribute at the time the Printer sends this response. Because
+ each Event Notification also contains the value of this
+ attribute when the event occurred, the value of this attribute
+ lets a Notification Recipient know when each Event Notification
+ occurred relative to the time of this response.
+
+ "suggested-ask-again-time-interval" (integer(0:MAX)):
+ The value of this attribute is the number of seconds that the
+ Notification Recipient SHOULD wait before trying this operation
+ again when
+ a) the Printer returns the 'server-error-busy' status code
+ OR
+ b) the Printer returns the 'successful-ok' status code and
+ the client supplied the "notify-no-wait" attribute with a
+ value of 'true'.
+ This value is intended to help the client be a good network
+ citizen.
+
+ "notify-ippget-redirect" (uri):
+ The value of this attribute is uri that the Notification
+ Recipient MUST use for the Get-Notifications operation. This
+ attribute is present in the Operation Attributes if and only if
+ the status code has the value 'redirection-other-site'.
+
+ Group 2: Unsupported Attributes
+
+ See [RFC2911] section 3.1.7 for details on returning
+ Unsupported Attributes.
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 14]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ If the "subscription-ids" attribute contained subscription-ids
+ that do not exist, the Printer returns them in this group as
+ value of the "subscription-ids" attribute.
+
+ Group 3 through N: Event Notification Attributes
+
+ The Printer responds with one Event Notification Attributes
+ Group per matched Event Notification. The initial matched Event
+ Notifications are all un-expired Event Notification associated
+ with the matched Subscription Objects. If the Notification
+ Recipient has selected the option to wait for additional Event
+ Notifications, the Printer the subsequent Event Notifications
+ in the response are Event Notifications associated with the
+ matched Subscription Objects as the corresponding Event occurs.
+
+ From the Notification Recipient's view, the response appears as
+ an initial burst of data, which includes the Operation
+ Attributes Group and one Event Notification Attributes Groups
+ per Event Notification that the Printer is holding. After the
+ initial burst of data, if the Notification Recipient has
+ selected the option to wait for additional Event Notifications,
+ the Notification Recipient receives occasional Event
+ Notification Attribute Groups. Proxy servers may delay some
+ Event Notifications or cause time-outs to occur. The client
+ MUST be prepared to perform the Get-Notifications operation
+ again when time-outs occur.
+
+ Each Event Notification Group MUST start with an 'event-
+ notification-attributes-tag' (see the section "Encodings of
+ Additional Attribute Tags" in [ipp-ntfy]).
+
+ Each attribute is encoded using the IPP rules for encoding
+ attributes [RFC2910] and may be encoded in any order. Note:
+ the Get-Jobs response in [RFC2911] acts as a model for encoding
+ multiple groups of attributes.
+
+ Each Event Notification Group MUST contain all of attributes
+ specified in section 9.1 ("Content of Machine Consumable Event
+ Notifications") of [ipp-ntfy] with exceptions denoted by
+ asterisks in the tables below.
+
+ The tables below are copies of the tables in section 9.1
+ ("Content of Machine Consumable Event Notifications") of [ipp-
+ ntfy] except that each cell in the "Sends" column is a "MUST".
+
+ For an Event Notification for all Events, the Printer includes
+ the attributes shown in Table 2.
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 15]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Table 2 - Attributes in Event Notification Content
+
+
+ Source Value Sends Source Object
+
+
+ notify-subscription-id (integer(1:MAX)) MUST Subscription
+
+ notify-printer-uri (uri) MUST Subscription
+
+ notify-subscribed-event (type2 keyword) MUST Event
+ Notification
+
+ printer-up-time (integer(MIN:MAX)) MUST Printer
+
+ printer-current-time (dateTime) * MUST * Printer
+
+ notify-sequence-number (integer (0:MAX)) MUST Subscription
+
+ notify-charset (charset) MUST Subscription
+
+ notify-natural-language (naturalLanguage) MUST Subscription
+
+ notify-user-data (octetString(63)) ** MUST Subscription
+
+ notify-text (text) MUST Event
+ Notification
+
+ attributes from the "notify-attributes" MUST Printer
+ attribute ***
+
+ attributes from the "notify-attributes" MUST Job
+ attribute ***
+
+ attributes from the "notify-attributes" MUST Subscription
+ attribute ***
+
+
+ * The Printer MUST send the "printer-current-time" attribute if
+ and only if it supports the "printer-current-time" attribute on
+ the Printer object.
+
+ ** If the associated Subscription Object does not contain a
+ "notify-user-data" attribute, the Printer MUST send an octet-
+ string of length 0.
+
+ *** If the "notify-attributes" attribute is present on the
+ Subscription Object, the Printer MUST send all attributes
+ specified by the "notify-attributes" attribute. Note: if the
+
+
+Herriot, et al. Expires: August 28, 2001 [page 16]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Printer doesn't support the "notify-attributes" attribute, it
+ is not present on the associated Subscription Object.
+
+ For Event Notifications for Job Events, the Printer includes
+ the additional attributes shown in Table 3.
+
+ Table 3 - Additional Attributes in Event Notification Content for
+ Job Events
+
+
+ Source Value Sends Source
+ Object
+
+
+ job-id (integer(1:MAX)) MUST Job
+
+ job-state (type1 enum) MUST Job
+
+ job-state-reasons (1setOf type2 keyword) MUST Job
+
+ job-impressions-completed (integer(0:MAX)) * MUST Job
+
+
+ * The Printer MUST send the "job-impressions-completed"
+ attribute in an Event Notification only for the combinations of
+ Events and Subscribed Events shown in Table 4.
+
+
+ Table 4 - Combinations of Events and Subscribed Events for "job-
+ impressions-completed"
+
+
+ Job Event Subscribed Job Event
+
+
+ 'job-progress' 'job-progress'
+
+ 'job-completed' 'job-completed'
+
+ 'job-completed' 'job-state-changed'
+
+
+
+ For Event Notification for Printer Events, the Printer includes
+ the additional attributes shown in Table 5.
+
+
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 17]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Table 5 - Additional Attributes in Event Notification Content for
+ Printer Events
+
+
+ Source Value Sends Source
+ Object
+
+
+ printer-state (type1 enum) MUST Printer
+
+ printer-state-reasons (1setOf type2 keyword) MUST Printer
+
+ printer-is-accepting-jobs (boolean) MUST Printer
+
+
+6 Subscription Template Attributes
+
+ This section defines the Subscription object conformance requirements
+ for Printers.
+
+
+6.1 Subscription Template Attribute Conformance
+
+ The 'ippget' Delivery Method has the same conformance requirements
+ for Subscription Template attributes as defined in [ipp-ntfy]. The
+ 'ippget' Delivery Method does not define any addition Subscription
+ Template attributes.
+
+
+6.2 Additional Information about Subscription Template Attributes
+
+ This section defines additional information about Subscription
+ Template attributes defined in [ipp-ntfy].
+
+
+6.2.1 notify-recipient-uri (uri)
+
+ This section describes the syntax of the value of this attribute for
+ the 'ippget' Delivery Method. The syntax for values of this
+ attribute for other Delivery Method is defined in other Delivery
+ Method Documents.
+
+ In order to support the 'ippget' Delivery Method and Protocol, the
+ Printer MUST support the following syntax:
+
+ The 'ippget://' URI scheme. The remainder of the URI indicates
+ something unique about the Notification Recipient, such as its host
+ name or host address (and optional path) that the Printer uses to
+ match the "notify-recipient-uri" Operation attribute supplied in
+ the Get-Notifications request.
+
+Herriot, et al. Expires: August 28, 2001 [page 18]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+6.3 Subscription Description Attribute Conformance
+
+ The 'ippget' Delivery Method has the same conformance requirements
+ for Subscription Description attributes as defined in [ipp-ntfy].
+ The 'ippget' Delivery Method does not define any addition
+ Subscription Description attributes.
+
+
+7 Additional Printer Description Attributes
+
+ This section defines the Printer Description Attributes conformance
+ requirements for Printers.
+
+
+7.1 Printer Description Attribute Conformance
+
+ The 'ippget' Delivery Method has the same conformance requirements
+ for Printer Description attributes as defined in [ipp-ntfy]. The
+ 'ippget' Delivery Method does not define any addition Printer
+ Description attributes.
+
+
+7.2 New Values for Existing Printer Description Attributes
+
+ This section defines additional values for existing Printer
+ Description attributes.
+
+
+7.2.1 notify-schemes-supported (1setOf uriScheme)
+
+ The following value for the "notify-schemes-supported" attribute is
+ added in order to support the new Delivery Method defined in this
+ document:
+
+ 'ippget' - The IPP Notification Delivery Method defined in this
+ document.
+
+7.2.2 operations-supported (1setOf type2 enum)
+
+ Table 6 lists the "operation-id" value defined in order to support
+ the new Get-Notifications operation defined in this document.
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 19]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Table 6 - Operation-id assignments
+
+
+ Value Operation Name
+
+
+ 0x001C Get-Notifications
+
+
+
+
+7.3 begin-to-expire-time-interval (integer(0:MAX))
+
+ This Printer Description attribute specifies the number of seconds
+ that a Printer keeps an Event Notification that is associated with
+ the 'ippget' Delivery Method.
+
+ The Printer MUST support this attribute if it supports the 'ippget'
+ Delivery Method.
+
+ The value of this attribute is the minimum number of seconds that
+ MUST elapse between the time the Printer creates an Event
+ Notification object for the 'ippget' Delivery Method and the time the
+ Printer discards the same Event Notification.
+
+ For example, assume the following:
+
+ 1.a client performs a Job Creation operation that creates a
+ Subscription Object associated with this Delivery Method, AND
+
+ 2.an Event associated with the new Job occurs immediately after
+ the Subscription Object is created, AND
+
+ 3.the same client or some other client performs a Get-
+ Notifications operation N seconds after the Job Creation
+ operation.
+
+ Then, if N is less than the value of this attribute, the client
+ performing the Get-Notifications operations can expect not miss any
+ Event-Notifications, barring some unforeseen lack of memory space in
+ the Printer.
+
+
+8 New Status Codes
+
+ The following status codes are defined as extensions for this
+ Delivery Method and are returned as the status code of the Get-
+ Notifications operation.
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 20]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+8.1 redirection-other-site (0x300)
+
+ This status code means that the Printer doesn't perform that Get-
+ Notifications operation and that the "notify-ippget-redirect"
+ Operation Attribute in the response contains the uri that the
+ Notification Recipient MUST use for performing the Get-Notifications
+ operation.
+
+
+9 The IPPGET URL Scheme
+
+ This section defines the 'ippget' URL and the conformance
+ requirements for using it.
+
+
+9.1 The IPPGET URL Scheme Applicability and Intended Usage
+
+ This section is intended for use in registering the 'ippget' URL
+ scheme with IANA and fully conforms to the requirements in [RFC2717].
+ This document defines the 'ippget'" URL (Uniform Resource Locator)
+ scheme for specifying a unique identifier for an IPP Client which
+ implements the IPP Get-Notifications operation specified in this
+ document (see section 5).
+
+ The intended usage of the 'ippget' URL scheme is COMMON.
+
+
+9.2 The IPPGET URL Scheme Associated Port
+
+ None.
+
+ An 'ippget' URL behaves as a unique identifier for IPP Clients and is
+ NOT used to initiate any over-the-wire protocol associations.
+
+ See: IANA Port Numbers Registry [IANA-PORTREG].
+
+
+9.3 The IPPGET URL Scheme Associated MIME Type
+
+ All IPP Get-Notifications operations (requests and responses) MUST be
+ conveyed in an 'application/ipp' MIME media type as registered in
+ [IANA-MIMEREG]. An 'ippget' URL MUST uniquely identify an IPP Client
+ that support this 'application/ipp' MIME media type.
+
+ See: IANA MIME Media Types Registry [IANA-MIMEREG].
+
+
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 21]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+9.4 The IPPGET URL Scheme Character Encoding
+
+ The 'ippget' URL scheme defined in this document is based on the ABNF
+ for the URI Generic Syntax [RFC2396] and further updated by [RFC2732]
+ and [RFC2373] (for IPv6 addresses in URLs). The 'ippget' URL scheme
+ is case-insensitive in the host name or host address part; however,
+ the path part is case-sensitive, as in [RFC2396]. Code points
+ outside [US-ASCII] MUST be hex escaped by the mechanism specified in
+ [RFC2396].
+
+
+9.5 The IPPGET URL Scheme Syntax in ABNF
+
+ This document is intended for use in registering the 'ippget' URL
+ scheme with IANA and fully conforms to the requirements in [RFC2717].
+ This document defines the 'ippget' URL (Uniform Resource Locator)
+ scheme for specifying a unique identifier for an IPP Client which
+ implements IPP 'Get-Notifications' operation specified in this
+ document.
+
+ The intended usage of the 'ippget' URL scheme is COMMON.
+
+ The IPP protocol places a limit of 1023 octets (NOT characters) on
+ the length of a URI (see section 4.1.5 'uri' in [RFC2911]). An IPP
+ Printer MUST return the 'client-error-request-value-too-long' status
+ code (see section 13.1.4.10 in [RFC2911]) when a URI received in a
+ request is too long.
+
+ Note: IPP Clients and IPP Printers ought to be cautious about
+ depending on URI lengths above 255 bytes, because some older client
+ or proxy implementations might not properly support these lengths.
+
+ An 'ippget' URL MUST be represented in absolute form. Absolute URLs
+ always begin with a scheme name followed by a colon. For definitive
+ information on URL syntax and semantics, see "Uniform Resource
+ Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This
+ specification adopts the definitions of "authority", "abs_path",
+ "query", "reg_name", "server", "userinfo", and "hostport" from
+ [RFC2396], as updated by [RFC2732] and [RFC2373] (for IPv6 addresses
+ in URLs).
+
+ The 'ippget' URL scheme syntax in ABNF is as follows:
+
+ ippget_URL = "ippget:" "//" authority [ abs_path [ "?" query ]]
+ authority = server | reg_name
+ reg_name = 1*( unreserved | escaped | "$" | "," |
+ ";" | ":" | "@" | "&" | "=" | "+" )
+ server = [ [ userinfo "@" ] hostport ]
+ userinfo = *( unreserved | escaped |
+ ";" | ":" | "&" | "=" | "+" | "$" | "," )
+
+Herriot, et al. Expires: August 28, 2001 [page 22]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ hostport = host [ ":" port ]
+ abs_path = "/" path_segments
+
+ If the port is empty or not given, then no port is assumed. The
+ semantics are that the 'ippget' URL is a unique identifier for an IPP
+ Client that will retrieve IPP event notifications via the IPP Get-
+ Notifications operation.
+
+ Note: The use of IP addresses in URLs SHOULD be avoided whenever
+ possible (see [RFC1900]).
+
+
+9.5.1 IPPGET URL Examples
+
+ The following are examples of valid 'ippget' URLs for IPP Clients
+ (using DNS host names):
+
+ ippget://abc.com
+ ippget://abc.com/listener
+ ippget://bob@abc.com/listener/1232
+
+ Note: The use of IP addresses in URLs SHOULD be avoided whenever
+ possible (see [RFC1900]).
+
+ The choice of 'userinfo@hostport' versus the simpler 'hostport'
+ production in an 'ippget' URL may be influenced by the intended
+ usage.
+
+ If a given IPP Client creates an IPP Subscription object for event
+ notifications intended for retrieval by the same IPP Client, then the
+ simple 'hostport' production may be most appropriate.
+
+ On the other hand, if a given IPP Client creates an IPP Subscription
+ object for event notifications intended for retrieval by a different
+ IPP Client, then the 'userinfo@hostport' production (using, for
+ example, the right-hand side of a 'mailto:' URL, see [RFC2368]) may
+ be most appropriate.
+
+
+9.5.2 IPPGET URL Comparisons
+
+ When comparing two 'ippget' URLs to decide if they match or not, an
+ IPP Client or IPP Printer SHOULD use a case-sensitive octet-by-octet
+ comparison of the entire URLs, with these exceptions:
+
+ - Comparisons of host names MUST be case-insensitive;
+
+ - Comparisons of scheme names MUST be case-insensitive;
+
+ - An empty 'abs_path' is equivalent to an 'abs_path' of "/".
+
+Herriot, et al. Expires: August 28, 2001 [page 23]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Characters other than those in the "reserved" and "unsafe" sets (see
+ [RFC2396] and [RFC2732]) are equivalent to their ""%" HEX HEX"
+ encoding.
+
+ For example, the following three URIs are equivalent:
+
+ ippget://abc.com/~smith/listener
+
+ ippget://ABC.com/%7Esmith/listener
+
+ ippget://ABC.com:/%7esmith/listener
+
+
+10 Encoding
+
+ This notification delivery method uses the IPP transport and encoding
+ [RFC2910] for the Get-Notifications operation with one extension
+ allocated in [ipp-ntfy]:
+
+
+ Table 7 - The "event-notification-attributes-tag" value
+
+
+ Tag Value (Hex) Meaning
+
+
+ 0x07 "event-notification-attributes-tag"
+
+
+
+11 Conformance Requirements
+
+
+11.1 Conformance for IPP Printers
+
+ IPP Printers that conform to this specification:
+
+ 1. MUST meet the conformance requirements defined in [ipp-ntfy];
+
+ 2. MUST support the Get-Notifications operation defined in section
+ 5;
+
+ 3. MUST support the Subscription object attributes as defined in
+ section 6;
+
+ 4. MUST support the additional values for IPP/1.1 Printer
+ Description attributes defined in section 7.2;
+
+ 5. MUST support the "begin-to-expire-time-interval" Printer
+ Description attribute defined in section 7.3;
+
+Herriot, et al. Expires: August 28, 2001 [page 24]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ 6. MUST support the "redirection-other-site" status code defined
+ 8.1;
+
+ 7. SHOULD reject received 'ippget' URLs in 'application/ipp'
+ request bodies (e.g., in the "notify-recipient-uri" attribute in
+ a Get-Notifications request) that do not conform to the ABNF for
+ 'ippget' URLs specified in section 9.5 of this document;
+
+ 8. MUST listen for the IPP Get-Notifications operation requests on
+ IANA-assigned well-known port 631, unless explicitly configured
+ by system administrators or site policies;
+
+ 9. SHOULD NOT listen for IPP Get-Notifications operation requests
+ on any other port, unless explicitly configured by system
+ administrators or site policies.
+
+
+11.2 Conformance for IPP Clients
+
+ IPP Clients that conform to this specification:
+
+ 1.MUST create unambiguously unique 'ippget' URLs in all cases;
+
+ 2.MUST send 'ippget' URLs (e.g., in the "notify-recipient-uri"
+ attribute in a Get-Notifications request) that conform to the
+ ABNF specified in section 9.5 of this document;
+
+ 3.MUST send IPP Get-Notifications operation requests via the port
+ specified in the associated 'ipp' URL (if present) or otherwise
+ via IANA assigned well-known port 631;
+
+ 4.MUST convert the associated 'ipp' URLs to their corresponding
+ 'http' URL forms according to the rules in section 5 "IPP URL
+ Scheme" in [RFC2910].
+
+ Note: The use of ambiguous 'ippget' URLs is NOT an optional feature
+ for IPP Clients; it is a non-conformant implementation error.
+
+
+12 IANA Considerations
+
+ IANA is requested to register the 'ippget' URL scheme as defined in
+ section 9 according to the procedures of [RFC2717].
+
+ The rest of this section contains the exact information for
+ additional IPP entities for IANA to add to the IPP Registries
+ according to the procedures defined in RFC 2911 [RFC2911] section 6.
+
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 25]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Note to RFC Editors: Replace RFC NNNN below with the RFC number
+ for this document, so that it accurately reflects the content of
+ the information for the IANA Registry.
+
+
+12.1 Operation Registrations
+
+ The operations defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.4 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/operations/
+
+ The registry entry will contain the following information:
+
+ Operations: Ref. Section:
+ Get-Notifications operation RFC NNNN 5
+
+
+12.2 Additional values of existing attributes
+
+
+12.2.1 Additional values for the "notify-schemes-supported" Printer
+ attribute
+
+ The "notify-schemes-supported" 'uriScheme' attribute value defined in
+ this document will be published by IANA according to the procedures
+ in RFC 2911 [RFC2911] section 6.1 with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attribute-values/notify-schemes-
+ supported/
+
+ The registry entry will contain the following information:
+
+ Ref. Section:
+ ippget RFC NNNN 7.2.1
+
+
+12.2.2 Additional values for the "operations-supported" Printer
+ attribute
+
+ The "operations-supported" type2 enum attribute value defined in this
+ document will be published by IANA according to the procedures in RFC
+ 2911 [RFC2911] section 6.1 with the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attribute-values/operations-
+ supported/
+
+ The registry entry will contain the following information:
+
+
+Herriot, et al. Expires: August 28, 2001 [page 26]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Value Ref. Section:
+ Get-Notifications 0x001C RFC NNNN 7.2.2
+
+
+12.3 Attribute Registrations
+
+ The attributes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.2 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/attributes/
+
+ The registry entry will contain the following information:
+
+ Printer Description attributes: Ref. Section:
+ begin-to-expire-time-interval (integer(0:MAX)) RFC NNNN 7.3
+
+12.4 Status code Registrations
+
+ The status codes defined in this document will be published by IANA
+ according to the procedures in RFC 2911 [RFC2911] section 6.6 with
+ the following path:
+
+ ftp.isi.edu/iana/assignments/ipp/status-codes/
+
+ The registry entry will contain the following information:
+
+ Status codes: Ref. Section:
+ redirection-other-site (0x300) RFC NNNN 8.1
+
+
+13 Internationalization Considerations
+
+ The IPP Printer MUST localize the "notify-text" attribute as
+ specified in section 14 of [ipp-ntfy].
+
+ In addition, when the client receives the Get-Notifications response,
+ it is expected to localize the attributes that have the 'keyword'
+ attribute syntax according to the charset and natural language
+ requested in the Get-Notifications request.
+
+
+14 Security Considerations
+
+ The IPP Model and Semantics document [RFC2911] discusses high-level
+ security requirements (Client Authentication, Server Authentication
+ and Operation Privacy). Client Authentication is the mechanism by
+ which the client proves its identity to the server in a secure
+ manner. Server Authentication is the mechanism by which the server
+ proves its identity to the client in a secure manner. Operation
+
+Herriot, et al. Expires: August 28, 2001 [page 27]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ Privacy is defined as a mechanism for protecting operations from
+ eavesdropping.
+
+ Unlike other Event Notification delivery methods in which the IPP
+ Printer initiates the Event Notification, with the method defined in
+ this document, the Notification Recipient is the client who s the
+ Get-Notifications operation. Therefore, there is no chance of "spam"
+ notifications with this method. Furthermore, such a client can close
+ down the HTTP channel at any time, and so can avoid future unwanted
+ Event Notifications at any time.
+
+
+15 References
+
+ [ipp-iig]
+ Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P.,
+ "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers-
+ guide-v11-02.txt, work in progress, January 25, 2001
+
+ [ipp-ntfy]
+ R. Herriot, Hastings, T., Isaacson, S., Martin, J., deBry, R.,
+ Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP
+ Event Notification Specification", <draft-ietf-ipp-not-spec-
+ 06.txt>, February 24, 2001.
+
+ [RFC1900]
+ B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC 1900,
+ February 1996.
+
+ [RFC2026]
+ S. Bradner, "The Internet Standards Process -- Revision 3", RFC
+ 2026, October 1996.
+
+ [RFC2119]
+ S. Bradner, "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119 , March 1997
+
+ [RFC2368]
+ P. Hoffman, L. Masinter, J. Zawinski. The "mailto" URL Scheme, RFC
+ 2368, July 1998.
+
+ [RFC2373]
+ R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC
+ 2373, July 1998.
+
+ [RFC2396]
+ Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic
+ Syntax, RFC 2396, August 1998
+
+
+
+Herriot, et al. Expires: August 28, 2001 [page 28]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ [RFC2567]
+ Wright, D., "Design Goals for an Internet Printing Protocol", RFC
+ 2567, April 1999.
+
+ [RFC2568]
+ Zilles, S., "Rationale for the Structure and Model and Protocol for
+ the Internet Printing Protocol", RFC 2568, April 1999.
+
+ [RFC2569]
+ Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
+ LPD and IPP Protocols", RFC 2569, April 1999.
+
+ [RFC2616]
+ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
+ Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2717]
+ R. Petke and I. King, "Registration Procedures for URL Scheme
+ Names", RFC 2717, November 1999.
+
+ [RFC2732]
+ R. Hinden, B. Carpenter, L. Masinter. Format for Literal IPv6
+ Addresses in URL's, RFC 2732, December 1999.
+
+ [RFC2910]
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
+
+ [RFC2911]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
+ "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911,
+ September 2000.
+
+
+16 Authors' Addresses
+
+
+ Robert Herriot
+ Xerox Corp.
+ 3400 Hill View Ave, Building 1
+ Palo Alto, CA 94304
+
+ Phone: 650-813-7696
+ Fax: 650-813-6860
+ e-mail: robert.herriot@pahv.xerox.com
+
+
+ Carl Kugler
+ IBM
+
+Herriot, et al. Expires: August 28, 2001 [page 29]
+\f
+
+INTERNET-DRAFT IPP: The 'ippget' Delivery Method February 28, 2001
+
+
+ P.O. Box 1900
+ Boulder, CO 80301-9191
+
+ Phone:
+ Fax:
+ e-mail: kugler@us.ibm.com
+
+ Harry Lewis
+ IBM
+ P.O. Box 1900
+ Boulder, CO 80301-9191
+
+ Phone: 303-924-5337
+ FAX:
+ e-mail: harryl@us.ibm.com
+
+
+17 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). 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 RFC Editor function is currently provided by the
+ Internet Society.
+
+
+Herriot, et al. Expires: August 28, 2001 [page 30]
+++ /dev/null
-
-
-
-
-
-
-
-INTERNET-DRAFT
-<draft-ietf-ipp-notify-mailto-00.txt> Henrik Holst
- i-data international a/s
- Tom Hastings
- Xerox Corp.
- March 9, 2000
-
- Internet Printing Protocol (IPP):
- The 'mailto:' Notification Delivery Method
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [rfc2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-The IPP notification specification [ipp-ntfy] is an OPTIONAL extension
-to IPP/1.0 and IPP/1.1 that requires the definition of one or more
-delivery methods for dispatching event notification reports to
-Notification Recipients. This document describes the semantics and
-syntax of the 'mailto:' event notification delivery method. For this
-delivery method, the IPP Printer uses the SMTP mail protocol to send
-(push) Human Consumable and/or Machine Consumable Notifications to
-Notification Recipients. The Subscriber specifies the mail address
-using the mailto: URL. This mail address can be any user or can be any
-of the mail services defined to perform such notification using
-parameters in the URL, such as paging. The Subscriber can specify the
-MIME media type of both the Human Consumable and Machine Consumable
-Notifications. The Subscriber can also specify a mail address in the
-"subscriber-user-data" Subscription attribute to which the Notification
-Recipient can reply and to which the mail system delivers undeliverable
-mail messages. That mail address is usually the Subscribers mail
-address, but can be any mail address.
-
-The mail messages appear to come from the Printer, so that mail agents
-can sort and filter on the From: field. Also the beginning of the
-
-
-
-Holst, Hastings [page 1]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-Subject line starts with the localized "Printer message: " prefix, so
-that mail agents can filter from any Printer.
-
- There are 7 ISSUES called out in the text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Holst, Hastings [page 2]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-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.1: Model and Semantics [ipp-mod]
- Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
- Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
- Mapping between LPD and IPP Protocols [RFC2569]
- Internet Printing Protocol (IPP): Event Notification Specification
- [ipp-ntfy]
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Model and Semantics" document
-describes a simplified model with abstract objects, their attributes,
-and their operations that are independent of encoding and transport. It
-introduces a Printer and a Job object. The Job object optionally
-supports multiple documents per Job. It also addresses security,
-internationalization, and directory issues.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting over HTTP a message
-body whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-Holst, Hastings [page 3]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-The "Event Notification Specification" document extends the Job Creation
-operations and defines additional operations that allow a client to
-subscribe to printing related events. Subscriptions are modeled as
-Subscription objects which can be Per-Job or Per-Printer Subscriptions.
-Additional operations are defined to query, renew, and cancel
-Subscription objects.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Holst, Hastings [page 4]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
- Table of Contents
-
-1 Introduction......................................................6
-
-2 Terminology.......................................................6
- 2.1Conformance Terminology..........................................6
- 2.2Other terminology................................................7
-
-3 Model and Operation...............................................7
-
-4 Sending Notifications.............................................8
- 4.1notify-recipient (uri)...........................................8
- 4.2notify-events (1setOf type2 keyword).............................8
- 4.3notify-format (mimeMediaType)....................................9
- 4.4subscriber-user-data (octetString(63))...........................9
- 4.5notify-charset (charset)........................................10
- 4.6notify-natural-language (naturalLanguage).......................10
- 4.7request-id......................................................10
- 4.8subscription-id (integer (1:MAX))...............................10
- 4.9notify-lease-expiration-time (integer(0:MAX))...................10
- 4.10 printer-uri (uri).............................................10
- 4.11 subscriber-user-name (name(MAX))..............................11
- 4.12 notify-printer-up-time (integer(1:MAX)).......................11
- 4.13 notify-persistence-granted (boolean)..........................11
-
-5 Mail Notification Content........................................11
- 5.1Human Consumable Form...........................................13
- 5.2Machine Consumable Form.........................................13
-
-6 Printer Description attributes specific to the 'mailto:' delivery
-method...............................................................13
- 6.1"printer-smtp-mail-service-address" (1setOf text(MAX))..........13
-
-7 Conformance Requirements.........................................13
-
-8 IANA Considerations..............................................14
-
-9 Internationalization Considerations..............................14
-
-10 Security Considerations..........................................14
-
-11 References.......................................................15
-
-12 Author's Addresses...............................................16
-
-13 Full Copyright Statement.........................................16
-
- Table of Tables
-
-Table 1 - SMTP Fields to be filled in................................12
-
-
-
-
-
-Holst, Hastings [page 5]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-
-
-1 Introduction
-
-An IPP Printer that supports the OPTIONAL IPP notification extension
-[ipp-ntfy] is called a Notification Source which sends event
-Notifications to Notification Recipients. As such, a Printer either a)
-accepts, stores, and uses notification Subscription objects to generate
-event Notification reports and implement one or more delivery methods
-for notifying interested parties, or b) supports a subset of these tasks
-and farms out the remaining tasks to a Notification Delivery Service.
-This document describes the semantics and syntax of the 'mailto:' event
-notification delivery method. Such a Notification Delivery Service then
-delivers the event Notification to the Ultimate Notification Recipient.
-
-For this delivery method, the IPP Printer uses the SMTP mail protocol to
-send (push) Human Consumable and/or Machine Consumable Notifications to
-Notification Recipients. The Subscriber specifies the mail address
-using the mailto: URL. This mail address can be any user or can be any
-of the mail services defined to perform such notification using
-parameters in the URL, such as paging. The Subscriber can specify the
-MIME media type of both the Human Consumable and Machine Consumable
-Notifications. The Subscriber can also specify a mail address in the
-"subscriber-user-data" Subscription attribute to which the Notification
-Recipient can reply and to which the mail system delivers undeliverable
-mail messages. That mail address is usually the Subscribers mail
-address, but can be any mail address.
-
-The mail messages appear to come from the Printer, so that mail agents
-can sort and filter on the From: field. Also the beginning of the
-Subject line starts with the localized "Printer message: " prefix, so
-that mail agents can filter from any Printer.
-
-
-2 Terminology
-
-This section defines terminology used throughout this document:
-
-
-2.1 Conformance Terminology
-
- Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
- NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
- conformance to this specification. These terms are defined in
- [ipp-mod section 13.1 on conformance terminology, most of which is
- taken from RFC 2119 [RFC2119].
- REQUIRED - an adjective used to indicate that a conforming IPP
- Printer implementation MUST support the indicated operation,
- object, attribute, attribute value, status code, or out-of-band
- value in requests and responses. See [ipp-mod] "Appendix A -
- Terminology for a definition of "support". Since support of this
- entire notification specification is OPTIONAL for conformance to
- IPP/1.0 or IPP/1.1, the use of the term REQUIRED in this document
-
-
-Holst, Hastings [page 6]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
- means "REQUIRED if this OPTIONAL notification specification is
- implemented".
- OPTIONAL - an adjective used to indicate that a conforming IPP
- Printer implementation MAY, but is NOT REQUIRED to, support the
- indicated operation, object, attribute, attribute value, status
- code, or out-of-band value in requests and responses.
-
-2.2 Other terminology
-
- Event Notification (Notification for short) - See [ipp-ntfy]
- Notification Source - See [ipp-ntfy]
- Notification Recipient - See [ipp-ntfy]
- Subscription object - See [ipp-ntfy]
- Ultimate Notification Recipient - See [ipp-ntfy]
-
-3 Model and Operation
-
-In the IPP Notification Model [ipp-ntfy], a client is able to:
-
- 1. supply one or more Per-Job Subscriptions in the Job Creation
- operation
-
- 2. OPTIONALLY supply Per-Job Subscriptions as subsequent Create-Job-
- Subscription operations
-
- 3. supply one Per-Printer Subscription in the Create-Printer-
- Subscription operation. The client that creates these Subscription
- objects becomes the owner of the Subscription object.
-
-The client that creates these Subscription objects becomes the owner of
-the Subscription object.
-
-When creating each Subscription object, the client supplies the "notify-
-recipient" (uri) attribute. The "notify-recipient" attribute specifies
-both a single Notification Recipient that is to receive the
-Notifications when subsequent events occur and the method for
-Notification delivery that the IPP Printer is to use. For the 'mailto:'
-Notification delivery method defined in this document, the "notify-
-recipient" consists of the 'mailto:' scheme followed by an SMPT mail
-address [RFC822].
-
-Notification Sources that implement the 'mailto:' event notification
-delivery method will need to include an SMTP mail agent while
-Notification Recipients that implement this delivery method will need to
-support an SMTP server. ISSUE 01: Is this SMTP terminology correct?
-
-The IPP Printer can be the Notification Source or could use some other
-Notification Delivery Service that actually delivers the mail message.
-In this latter case, the protocol between the IPP Printer and the
-Notification Delivery Service is implementation defined and could be the
-INDP protocol (see [indp]).
-
-
-
-
-Holst, Hastings [page 7]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-Also the Notification Recipient specified by the "notify-recipient"
-Subscription attribute can be either (1) the Ultimate Notification
-Recipient or can be a Notification Delivery Service, such as a paging
-system that accept 'mailto:' parameters to indicate the Ultimate
-Notification Recipient, such as a phone number or paging subscriber's
-id.
-
-
-4 Sending Notifications
-
-This section defines the processing that the IPP Printer MUST perform
-when sending an event Notification using the 'mailto:' delivery method.
-The usage of each of the Subscription object attributes defined in [ipp-
-ntfy] is described here as it applies to the 'mailto:' delivery method.
-The description of each Subscription attribute in this document is not
-the complete description, but is just the application of the attribute
-to this 'mailto:' delivery method. See the complete definition of each
-Subscription object attribute in [ipp-ntfy]. ISSUE 02: Is it a good
-idea to list each Subscription object attribute in this spec with the
-applicability to this delivery method? If yes, should all delivery
-method specs also do it this way? Section 5 defines how the IPP Printer
-populates the SMTP fields in the mail message.
-
-
-4.1 notify-recipient (uri)
-
-
-This REQUIRED READ-ONLY Subscription object attribute contain the
-'mailto:' URI delivery method followed by the SMTP mail address [RFC821]
-of the Notification Recipient. As required by the [ipp-ntfy] document,
-the following information is given for this notification delivery
-method:
-
-ISSUE 03 - What should we say about any mailto parameters, if any? For
-example, if you want to send over secure mail, etc.
-
-ISSUE 04 - Do we want to define any IPP-specific mailto parameters to
-this document?
-
-
-4.2 notify-events (1setOf type2 keyword)
-
-
-This REQUIRED READ-ONLY Subscription object attribute identifies the job
-and/or printer events that are to be delivered to the Notification
-Recipient as Notifications as defined in [ipp-ntfy] section 7.
-
-Note: Some rapidly recurring events, such as page events, are not
-appropriate to use with this delivery method, especially if the
-recipient mail address is a mailing list. Implementations MAY choose
-either not to support page events with the 'mailto:' delivery method
-and/or not permit a mailing list to be supplied, if they can detect that
-a mail address is a mailing list.
-
-
-
-
-Holst, Hastings [page 8]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-4.3 notify-format (mimeMediaType)
-
-
-This REQUIRED READ-ONLY Subscription object attribute indicates the type
-of Human Consumable and/or Machine Consumable format content that is to
-be sent in the Notifications as a mail message attachment. For the
-'mailto:' delivery method, any registered 'mimeMediaType' value is
-allowed, including types that allow pictures to be represented, e.g.,
-'application/postscript' or 'image/tiff', and/or sounds to be
-represented, e.g., 'audio/32kadpcm'. The body of the mail message MUST
-always be 'text/plain; charset=us-ascii, since that is the default for
-'mailto:'.
-
-There is no "notify-default" Printer attribute to configure. If the
-client did not supply the "notify-format" attribute in the Subscription
-Creation operation, the Printer MUST populate this attribute with an
-implementation-defined default value. Such a default value MAY include
-multi-part mixed media, so that the Printer can send multi-part mixed
-MIME type attachments by default (though there is no way for the client
-to explicitly request such). If the out-of-band 'none' value [ipp-col]
-was supplied in the Subscription Creation operation, the Printer MUST
-NOT send any attachment in the Notification.
-
-If the MIME media type registration definition permits a charset
-parameter, than the client MUST use such a specification (instead of the
-"notify-charset" attribute) in order to indicate the charset to be used
-in the Notification content.
-
-
-4.4 subscriber-user-data (octetString(63))
-
-
-This REQUIRED READ-ONLY Subscription object attribute holds an SMTP mail
-address value that the Printer copies to the "From:" inside <> (see RFC
-822 [rfc822] section 4.4.1) and the "Sender:" SMTP fields (see section
-5). For the 'mailto:' notification delivery method, the client MUST
-supply the "subscriber-user-data" attribute. If the client omits this
-attribute, the Printer MUST either (1) reject the operation with the
-'client-error-bad-request' or (2) ignore this Subscription, since the
-Printer will not have a mail address to put in the "From:" and in the
-"Sender:" SMTP fields, depending on implementation.
-
-When the subscribing user selects the 'mailto:' delivery scheme, the
-client SHOULD obtain the user's mail address automatically from the
-client system (in an implementation-dependent manner) and supply it as
-the value of the "subscriber-user-data" attribute by default, rather
-than require the user to explicitly supply it. Allowing users to supply
-the mail address explicitly would allow the malicious user to hide
-his/her identity when sending notifications by email.
-
-
-
-
-
-
-
-Holst, Hastings [page 9]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-4.5 notify-charset (charset)
-
-
-This OPTIONAL READ-ONLY Subscription object attribute specifies the
-charset to be used in the Notification content sent to the Notification
-Recipient, whether the notification content is Machine Consumable or
-Human Consumable. The client MUST NOT supply and the Printer MUST NOT
-use this attribute when the MIME media type registration definition
-supplied in the "notify-format" attribute value allows the charset
-parameter in its MIME media type value, e.g., 'text/plain; charset=utf-
-8'.
-
-
-4.6 notify-natural-language (naturalLanguage)
-
-
-This OPTIONAL READ-ONLY Subscription object attribute specifies the
-natural language for the IPP object to use in the localized Notification
-content that is sent to the Notification Recipient, whether the
-notification content is Machine Consumable or Human Consumable.
-
-
-4.7 request-id
-
-
-This REQUIRED READ-ONLY Subscription object attribute holds the most
-recent request-id sequence number delivered in a Notification content to
-the Notification Recipient. A value of 0 indicates that no
-Notifications have been sent for this subscription. The first request-
-id sent for a subscription MUST be 1. Each Notification Recipient has
-its own monotonically increasing series of request-ids, i.e., no gaps,
-in order to be able to detect a missing notification.
-
-
-4.8 subscription-id (integer (1:MAX))
-
-
-This REQUIRED READ-ONLY Subscription object attribute uniquely
-identifies this Subscription object instance on this Printer object or
-this Job object..
-
-
-4.9 notify-lease-expiration-time (integer(0:MAX))
-
-
-This REQUIRED READ-ONLY Subscription object attribute specifies the time
-in the future when the subscription lease will expire, i.e., the
-"printer-up-time" value at which the lease will expire.
-
-
-4.10printer-uri (uri)
-
-This REQUIRED READ-ONLY Subscription object attribute identifies the
-Printer object that created this Subscription object.
-
-
-
-
-
-Holst, Hastings [page 10]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-4.11subscriber-user-name (name(MAX))
-
-This REQUIRED READ-ONLY Subscription object attribute contains the name
-of the user that created the Subscription object. The Printer includes
-the value of this attribute as the value of the SMTP "FROM" field
-outside the <> (see RFC 822 [rfc822] section 4.4.1). For the 'mailto:'
-notification delivery method, the client MUST supply the "requesting-
-user-name" operation attribute so that the Printer can populate the
-"subscriber-user-name" Subscription attribute, in case the Printer does
-not have a more authenticated printable name (see [ipp-ntfy]). If the
-client omits "requesting-user-name" attribute and the Printer doesn't
-have a more authenticated printable name, the Printer MUST either (1)
-reject the operation with the 'client-error-bad-request' or (2) ignore
-this Subscription, since the Printer will not have a User Display Name
-to put in the "From:" field outside the <>, depending on implementation.
-
-ISSUE 05: Ok that we made "subscriber-user-name" be REQUIRED for the
-Printer to support and indicate that the client MUST supply the
-"requester-user-name" operation attribute when the delivery method is
-'mailto:', in case the Printer does not have a more authenticated
-printable name?
-
-
-4.12notify-printer-up-time (integer(1:MAX))
-
-
-This REQUIRED READ-ONLY Subscription object attribute indicates the
-amount of time (in seconds) that the Printer implementation has been up
-and running. The Printer includes the value of this attribute in both
-the Human Consumable and Machine Consumable forms.
-
-
-4.13notify-persistence-granted (boolean)
-
-
-This REQUIRED Subscription object attribute whether or not the Per-Job
-or Per-Printer Subscription is persistent, i.e., saved across power
-cycles in an implementation-define manner.
-
-
-5 Mail Notification Content
-
-The intent of the mail message is that the Notification Recipient is
-receiving a Human Consumable and/or Machine Consumable mail message from
-the Printer with the subject line indicating that it is a printer
-notification message and some implementation-defined salient
-information, such as the Job name and submitting user name. The body of
-the message duplicates this information and includes other information
-as REQUIRED by [ipp-ntfy].
-
-Table 1 shows the SMPT fields that the IPP Printer MUST fill in from the
-indicated sources of the data.
-
-
-
-
-
-Holst, Hastings [page 11]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
- Table 1 - SMTP Fields to be filled in
-
-SMTP RFC SMTP Subscription object attribute source for SNMP field
-822 Field
-section Name
-
-4.4.1 From: "printer-name" <"subscriber-user-data">
-
- For example, if Bob Jones submits a print job to the
- Printer "George Washington" and his email address is
- jones@acme.com, the From: line will be displayed as:
-
- From: George Washington <jones@acme.com>
-
- Mail messages appear to the Notification Recipient
- to come from the Printer, so that mail agents can
- sort and filter on the From: field.
-
- Note: The "printer-name" is the Mail Display name.
- And the "subscriber-user-data" inside <> is assumed
- to be an SMTP mail address so that the Notification
- Recipient can reply to the subscriber. For example,
- to say "I picked up your document, thanks."
-
-4.4.2 Sender: "subscriber-user-name" <"subscriber-user-data">
-
- For example, if Bob Jones submits a print job to the
- Printer "George Washington" and his email address is
- jones@acme.com, the Sender: line will be displayed
- as:
-
- Sender: Bob Jones <jones@acme.com>
-
- Note: The "subscriber-user-name" is the Mail
- Display name (Bob Jones). And the "subscriber-user-
- data" inside <> is assumed to be an SMTP mail
- address so that the mail system will send failure to
- deliver mail messages to the mail address specified
- by the "subscriber-user-data", not the Printer.
-
-4.5.1 To: The rest of the URI following the 'mailto:' scheme
- in the value of the "notify-recipient" attribute.
-
-4.7.1 Subject: Implementation-dependent, but SHOULD start with
- "Printer message: " (localized) followed by the job
- or printer event name, job name, etc. The beginning
- of the Subject line is a standardized prefix, so
- that mail agents can filter from any Printer.
-
-The Printer MUST repeat any of this information in these fields in the
-body of the message, plus additional information REQUIRED by the
-Notification Specification [ipp-ntfy].
-
-
-Holst, Hastings [page 12]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-5.1 Human Consumable Form
-
-
-If the format specified by the "notify-format" (mimeMediaType) is a
-Human Consumable form, then it MUST be sent as a MIME according to
-[rfc1341] and [rfc2046] if the MIME type is anything but 'text/plain'.
-Even 'text/plain; charset=utf-8' MUST be represented as a MIME type in
-the body of the message.
-
-ISSUE 06: What if "notify-format" is 'text/plain; charset=utf-8', does
-that have to be sent as a mail attachment, since it isn't 'text/plain'
-which assumes charset=us-ascii, or can it be sent as the body of the
-mail message properly identified as 'text/plain; charset=us-ascii'?
-
-
-5.2 Machine Consumable Form
-
-
-If the format specified by the "notify-format" (mimeMediaType) is a
-Machine Consumable form, then it MUST be sent as a MIME attachment
-according to [rfc1341] and [rfc2046], including the 'application/ipp'.
-
-
-6 Printer Description attributes specific to the 'mailto:' delivery
- method
-
-This section defines Printer Description attributes that are REQUIRED
-when supporting the 'mailto:' delivery method.
-
-
-6.1 "printer-smtp-mail-service-address" (1setOf text(MAX))
-
-
-This REQUIRED Printer Description attribute contains the DNS or IP
-address of the SMTP relaying mail server (see [rfc822]) that the Printer
-is to use to send mail messages when supporting the 'mailto:' delivery
-method. The System Administrator is expected to configure this
-attribute with one or more values.
-
-
-7 Conformance Requirements
-
-If the IPP Printer supports the 'mailto:' notification delivery scheme,
-the Printer MUST meet these conformance requirements:
-
-1.MUST meet the conformance requirements defined in [ipp-ntfy].
-
-2.MUST support at least the 'text/plain' Notification Content format.
- Being able to support any other MIME media types (MUST be sent as
- mail attachments) is OPTIONAL..
-
-3.MUST support the Subscription attribute semantics specified in
- section 4 when sending Notifications.
-
-4.MUST fill in the SMTP fields in the mail message as specified in
- section 5.
-
-
-Holst, Hastings [page 13]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-5.MUST support the "printer-smtp-mail-service-address" (1setOf
- text(MAX)) Printer Description attribute defined in section 6.
-
-
-8 IANA Considerations
-
-Since the 'mailto:' URL scheme is already defined in a standards track
-document and registered with IANA, this document does not require
-anything further of IANA.
-
-
-9 Internationalization Considerations
-
-This notification delivery method presents no additional
-internationalization considerations already covered in the [ipp-ntfy]
-document. The IPP Printer MUST localize the Human Consumable format and
-the 'text' attributes in the Machine Consumable form. The Notification
-Recipient is expected to localize the attributes in the Machine
-Consumable that have the 'keyword' attribute syntax according to the
-charset and natural language supplied in the Notification Content which
-is derived from the Subscription object as supplied by the Subscriber.
-
-
-10 Security Considerations
-
-By far the biggest security concern is the abuse of notification:
-sending unwanted notifications to third parties (i.e., spam). The
-problem is made worse by notification addresses that may be
-redistributed to multiple parties (e.g. mailing lists). There exist
-scenarios where third party notification is required (see Scenario #2
-and #3 in [ipp-not-req]). The fully secure solution would require
-active agreement of all recipients before sending out anything.
-However, requirement #9 in [ipp-req] ("There is no requirement for IPP
-Printer receiving the print request to validate the identity of an event
-recipient") argues against this. Certain systems may decide to disallow
-third party notifications (a traditional facsimile model).
-
-Sometimes the Notification Recipient is not the same person as the
-person who created the Subscription. It is possible for the
-Notification Recipient to find out who created the Subscription, since
-the subscriber MUST supply the "subscriber-user-name" Subscription
-attribute in the Subscription Creation operation.
-
-The [ipp-ntfy] document discusses general security considerations for
-notifications. Some delivery methods, such as the 'ipp:' delivery
-method, avoid the spam problem because the Notification Recipient pulls
-the Notifications when desired. The 'indp:' [indp-method] delivery
-method allows the Notification Recipient to return a special status code
-reply to the IPP Printer Send-Notifications operation to cancel the
-subscription. The 'mailto:' delivery method does not permit either of
-these remedies.
-
-ISSUE 07 - Is there any way that a Notification Recipient could reply to
-the message in such a way as to cancel the subscription and thereby
-solve the spam problem?
-
-
-Holst, Hastings [page 14]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-Some firewall administrators are preventing mail attachments from being
-accepted into their organizations because of the problem of the
-attachments containing computer viruses. The 'mailto:' delivery method
-allows the subscriber to suppress sending any attachments, by specifying
-only the 'text/plain' MIME media type.
-
-
-11 References
-
-[ipp-coll]
- deBry, R., , Hastings, T., Herriot, R., "Internet Printing
- Protocol/1.0 & 1.1: collection attribute syntax", <draft-ietf-ipp-
- collection-00.doc>, work in progress, September 9, 1999.
-
-[ipp-mod]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
- ipp-model-v11-04.txt>, June, 1999.
-
-[ipp-ntfy]
- Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
- Bergman, R., "Internet Printing Protocol/1.1: IPP Event
- Notification Specification", <draft-ietf-ipp-not-spec-01.txt>,
- October 14, 1999.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 03.txt, June, 1999.
-
-[rfc821]
- Jonathan B. Postel, "Simple Mail Transfer Protocol", August, 1982.
-
-[rfc822]
- David H. Crocker, "Standard For The Format Of ARPA Internet Text
- Messages", August 13, 1982.
-
-[rfc1341]
- N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
- Extensions): Mechanisms for Specifying and Describing the Format of
- Internet Message Bodies", June, 1992.
-
-[rfc2026]
- S. Bradner, "The Internet Standards Process -- Revision 3", RFC
- 2026, October 1996.
-
-[rfc2046]
- Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
- N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521,
- RFC1522, RFC1590), RFC 2046.
-
-
-
-
-
-
-Holst, Hastings [page 15]
-
- Expires: September 9, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'mailto:' Notification Delivery Method 3/9/00
-
-
-[rfc2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-
-12 Author's Addresses
-
- Henrik Holst
- i-data international a/s
- Vadstrupvej 35-43
- 2880 Bagsvaerd, Denmark
-
- Phone: +45 4436-6000
- Fax: +45 4436-6111
- e-mail: hh@i-data.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
-
-
-13 Full Copyright Statement
-
-Copyright (C) The Internet Society (2000). 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.
-
-
-
-Holst, Hastings [page 16]
-
- Expires: September 9, 2000
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT
+<draft-ietf-ipp-notify-mailto-03.txt> Robert Herriot
+Category: standards track Xerox Corp.
+ Henrik Holst
+ i-data international a/s
+ Tom Hastings
+ Xerox Corp.
+ Carl-Uno Manros
+ Xerox Corp.
+ August 30, 2000
+
+ Internet Printing Protocol (IPP):
+ The 'mailto' Delivery Method for Event Notifications
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of [RFC2026]. Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its areas, and
+its working groups. Note that other groups may also distribute working
+documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as "work in progress".
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed as
+http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+
+The notification extension document [ipp-ntfy] defines operations that a
+client can perform in order to create Subscription Objects in a Printer
+and carry out other operations on them. The Subscription Object
+specifies that when one of the specified Events occurs, the Printer
+sends an asynchronous Event Notification to the specified Notification
+Recipient via the specified Delivery Method (i.e., protocol).
+
+
+The notification extension document [ipp-ntfy] specifies that each
+Delivery Method is defined in another document. This document is one
+such document, and it specifies the 'mailto' delivery method.
+
+Herriot, et al. Expires: March 1, 2001 [page 1]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+For this Delivery Method, when an Event occurs, the Printer immediately
+sends an Event Notification via an email message to the Notification
+Recipient specified in the Subscription Object. The message body of the
+email consists of Human Consumable text that is not intended to be
+parsed by a machine.
+
+
+The Notification Recipient receives the Event Notification in the same
+way as it receives any other email message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 2]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+The basic 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.1: Model and Semantics [ipp-mod]
+ Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
+ Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
+ Mapping between LPD and IPP Protocols [RFC2569]
+ Internet Printing Protocol (IPP): IPP Event Notification
+ Specification [ipp-ntfy]
+
+The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
+satisfied in IPP/1.0. A few OPTIONAL operator operations have been
+added to IPP/1.1.
+
+The "Rationale for the Structure and Model and Protocol for the Internet
+Printing Protocol" document describes IPP from a high level view,
+defines a roadmap for the various documents that form the suite of IPP
+specification documents, and gives background and rationale for the IETF
+working group's major decisions.
+
+The "Internet Printing Protocol/1.1: Model and Semantics" document
+describes a simplified model with abstract objects, their attributes,
+and their operations that are independent of encoding and transport. It
+introduces a Printer and a Job object. The Job object optionally
+supports multiple documents per Job. It also addresses security,
+internationalization, and directory issues.
+
+The "Internet Printing Protocol/1.1: Encoding and Transport" document is
+a formal mapping of the abstract operations and attributes defined in
+the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
+rules for a new Internet MIME media type called "application/ipp". This
+document also defines the rules for transporting over HTTP a message
+body whose Content-Type is "application/ipp". This document also
+defines a new scheme named 'ipp' for identifying IPP printers and jobs.
+
+The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
+insight and advice to implementers of IPP clients and IPP objects. It
+is intended to help them understand IPP/1.1 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.
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 3]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+The "Mapping between LPD and IPP Protocols" document gives some advice
+to implementers of gateways between IPP and LPD (Line Printer Daemon)
+implementations.
+
+
+The "Event Notification Specification" document describes an extension
+to the IPP/1.0, IPP/1.1, and future versions. This extension allows a
+client to subscribe to printing related Events. The Subscription Object
+specifies that when one of the specified Event occurs, the Printer sends
+an asynchronous Event Notification to the specified Notification
+Recipient via the specified Delivery Method (i.e., protocol). A client
+associates Subscription Objects with a particular Job by performing the
+Create-Job-Subscriptions operation or by submitting a Job with
+subscription information. A client associates Subscription Objects with
+the Printer by performing a Create-Printer-Subscriptions operation.
+Four other operations are defined for Subscription Objects: Get-
+Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and
+Cancel-Subscription.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 4]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+ Table of Contents
+
+1 Introduction ......................................................7
+
+2 Terminology .......................................................7
+
+3 Model and Operation ...............................................7
+
+4 General Information ...............................................9
+
+5 Subscription Template Attributes .................................11
+ 5.1 Additional Subscription Template Attributes ...................11
+ 5.1.1 notify-mailto-text-only (boolean)..........................11
+ 5.2 Additional Information about Subscription Template Attributes .12
+ 5.2.1 notify-recipient-uri (uri).................................12
+ 5.2.2 notify-user-data (octetString(63)).........................12
+
+6 Event Notification Content .......................................13
+ 6.1 Headers .......................................................13
+ 6.1.1 'Date' header..............................................13
+ 6.1.2 'From' header..............................................14
+ 6.1.3 'Subject' header...........................................14
+ 6.1.4 'Sender' header............................................15
+ 6.1.5 'Reply-to' header..........................................15
+ 6.1.6 'To' header................................................15
+ 6.1.7 'Content-type' header......................................16
+ 6.2 Message Body ..................................................16
+ 6.3 Plain Text Content ............................................17
+ 6.3.1 Event Notification Content Common to All Events............18
+ 6.3.2 Additional Event Notification Content for Job Events.......20
+ 6.3.3 Additional Event Notification Content for Printer Events...21
+ 6.4 Examples ......................................................21
+ 6.4.1 Job Event Example..........................................22
+ 6.4.2 Printer Event Example......................................23
+ 6.4.3 Printer Event Example (localized to Danish)...............24
+
+7 Conformance Requirements .........................................25
+
+8 IANA Considerations ..............................................26
+
+9 Internationalization Considerations ..............................26
+
+10 Security Considerations ..........................................26
+
+11 References .......................................................27
+
+12 Author's Addresses ...............................................28
+
+13 Full Copyright Statement .........................................29
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 5]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+ Table of Tables
+
+Table 1 - Information about the Delivery Method.......................9
+
+
+Table 2 - Additional Subscription Template Attributes................11
+
+
+Table 3 - Printer Name in Event Notification Content.................19
+
+
+Table 4 - Event Name in Event Notification Content...................19
+
+
+Table 5 - Job Name in Event Notification Content.....................20
+
+
+Table 6 - Job State in Event Notification Content....................20
+
+
+Table 7 - Printer State in Event Notification Content................21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 6]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+1 Introduction
+
+The notification extension document [ipp-ntfy] defines operations that a
+client can perform in order to create Subscription Objects in a Printer
+and carry out other operations on them. A Subscription Object represents
+a Subscription abstraction. The Subscription Object specifies that when
+one of the specified Events occurs, the Printer sends an asynchronous
+Event Notification to the specified Notification Recipient via the
+specified Delivery Method (i.e., protocol).
+
+
+The notification extension document [ipp-ntfy] specifies that each
+Delivery Method is defined in another document. This document is one
+such document, and it specifies the 'mailto' delivery method.
+
+
+For this Delivery Method, when an Event occurs, the Printer immediately
+sends an Event Notification via an email message to the Notification
+Recipient specified in the Subscription Object. The message body of the
+email consists of Human Consumable text that is not intended to be
+parsed by a machine. The 'mailto' Delivery Method is a 'push' Delivery
+Method as defined in [ipp-ntfy].
+
+
+The Notification Recipient receives the Event Notification in the same
+way as it receives any other email message.
+
+
+2 Terminology
+
+This section defines the following terms that are used throughout this
+document:
+
+
+Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
+MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+conformance to this specification. These terms are defined in [ipp-mod
+section 13.1 on conformance terminology, most of which is taken from RFC
+2119 [RFC2119].
+
+
+For capitalized terms that appear in this document, see [ipp-ntfy].
+
+
+3 Model and Operation
+
+In a Subscription Creation Operation, when the value of the "notify-
+recipient-uri" attribute contains the scheme "mailto", the client is
+requesting that the Printer use the 'mailto' Delivery Method for Event
+Notifications generated from the new Subscription Object.
+
+
+Herriot, et al. Expires: March 1, 2001 [page 7]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+For this Delivery Method, the "notify-recipient-uri" attribute value
+MUST consist of a "mailto" scheme followed by a colon, and then followed
+by an address part (e.g. 'mailto:smith@abc.com'). See section 5.2.1 for
+the syntax of the "notify-recipient-uri" attribute value for this
+Delivery Method.
+
+
+A Printer MUST support SMTP [RFC821], and it MAY support other email
+protocols. A Printer MAY use additional services, such as SMTP delivery
+status notification [RFC1891] or S/MIME encryption [RFC2633].
+
+
+If the client wants the Printer to send Event Notifications via the
+'mailto' Delivery Method, the client MUST choose a value for "notify-
+recipient-uri" attribute which conforms to the rules of section 5.2.1.
+To avoid denial-of-service attacks, a client SHOULD NOT use distribution
+lists as the Notification Recipient.
+
+
+When an Event occurs, the Printer MUST immediately:
+
+
+ 1. Find all pertinent Subscription Objects P according to the rules of
+ section 9 of [ipp-ntfy], AND
+
+
+ 2. Find the subset M of these Subscription Objects P whose "notify-
+ recipient-uri" attribute has a scheme value of 'mailto', AND
+
+
+ 3. For each Subscription Object in M, the Printer MUST
+
+
+ a)generate an email message as specified in section 5.2.2 AND
+
+
+ b)send the email message to the Notification Recipient specified
+ by the address part of the "notify-recipient-uri" attribute
+ value (see section 5.2.1).
+
+
+If the Printer supports only SMTP, it MUST send the email message via
+SMTP. If the Printer supports additional email protocols, it MUST
+determine the protocol from the address part of the "notify-recipient-
+uri" attribute value and then send the email message via the appropriate
+email protocol.
+
+
+When a Subscribing Client is subscribing to the 'job-progress' event
+(which is a frequently occurring event), it SHOULD supply the "notify-
+
+
+Herriot, et al. Expires: March 1, 2001 [page 8]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+time-interval" attribute (see [ipp-ntfy]) in the Subscription Creation
+request with a suitable value to limit the time between 'job-progress'
+Event Notifications sent by the Printer.
+
+
+4 General Information
+If a Printer supports this Delivery Method, the following are its
+characteristics.
+
+
+ Table 1 - Information about the Delivery Method
+
+
+
+ Document Method Conformance Delivery Method Realization
+ Requirement
+
+
+ 1.What is the URL scheme name mailto
+ for the Delivery Method?
+
+ 2.Is the Delivery Method
+ REQUIRED, RECOMMENDED, or
+ OPTIONAL for an IPP Printer to RECOMMENDED
+ support?
+
+ 3.What transport and delivery A Printer MUST support SMTP. It MAY
+ protocols does the Printer use support other email protocols.
+ to deliver the Event
+ Notification Content, i.e.,
+ what is the entire network
+ stack?
+
+ 4.Can several Event A Printer implementation MAY
+ Notifications be combined into combine several Event Notifications
+ a Compound Event Notification? into a single email message.
+
+ 5.Is the Delivery Method This Delivery Method is a push.
+ initiated by the Notification
+ Recipient (pull), or by the
+ Printer (push)?
+
+ 6.Is the Event Notification Human Consumable
+ content Machine Consumable or
+ Human Consumable?
+
+ 7.What section in this document Section 6
+ answers the following
+ question? For a Machine
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 9]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+
+ Consumable Event Notification,
+ what is the representation and
+ encoding of values defined in
+ section 9.1 of [ipp-ntfy] and
+ the conformance requirements
+ thereof? For a Human
+ Consumable Event Notification,
+ what is the representation and
+ encoding of pieces of
+ information defined in section
+ 9.2 of [ipp-ntfy] and the
+ conformance requirements
+ thereof?
+
+ 8.What are the latency and Same as the underlying SMTP (or
+ reliability of the transport other optional) email transport
+ and delivery protocol?
+
+ 9.What are the security aspects Same as the underlying SMTP (or
+ of the transport and delivery other optional) email transport
+ protocol, e.g., how it is
+ handled in firewalls?
+
+ 10. What are the content length None
+ restrictions?
+
+ 11. What are the additional None
+ values or pieces of
+ information that a Printer
+ sends in an Event Notification
+ content and the conformance
+ requirements thereof?
+
+ 12. What are the additional See section 5.1.1 on "notify-
+ Subscription Template and/or mailto-text-only"
+ Subscription Description
+ attributes and the conformance
+ requirements thereof?
+
+ 13. What are the additional None
+ Printer Description attributes
+ and the conformance
+ requirements thereof?
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 10]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+5 Subscription Template Attributes
+
+5.1 Additional Subscription Template Attributes
+
+
+This Delivery Method introduces one additional Subscription Template
+Attribute (See Table 2).
+
+
+ Table 2 - Additional Subscription Template Attributes
+
+
+
+Attribute in Subscription Default and Supported Printer
+Object Attributes
+
+
+notify-mailto-text-only N/A
+(boolean)
+
+
+5.1.1notify-mailto-text-only (boolean)
+
+
+When the Printer generates an Event Notification from a Subscription
+Object, this attribute specifies whether the Printer generates the Event
+Notification with only plain text (i.e. 'text/plain') or with Content-
+Types that the Printer chooses.
+
+
+The Printer MUST support this attribute if it supports the 'mailto'
+Delivery Method.
+
+
+A client MAY supply this attribute. If a client does not supply this
+attribute, the Printer MUST populate this attribute with the value of
+'false' on the Subscription Object. There is no "notify-mailto-text-
+only-default" attribute.
+
+
+If the value of this attribute is 'true' in a Subscription Object, the
+message body of each Event Notification that the Printer generates from
+the Subscription Object MUST contain plain text only (i.e. 'text/plain'
+with the charset specified by the "notify-charset' Subscription Object
+attribute).
+
+
+If the value of this attribute is 'false' in a Subscription Object, the
+Content-Type of the message body of each Event Notification that the
+Printer generates from the Subscription Object MUST be either
+
+
+Herriot, et al. Expires: March 1, 2001 [page 11]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+'text/plain' or 'multipart', depending on implementation. If the
+Content-Type is 'multipart', one message body of the 'multipart' MUST be
+the same as the 'text/plain' message body when this attribute has the
+value of 'true'. Each of the other message bodies of the 'multipart' MAY
+be any Content-Type (e.g. 'text/html', 'image/gif', 'audio/basic',
+etc.).
+
+
+A Printer MUST support both values ('true' and 'false') of this
+attribute. There is no "notify-mailto-text-only-supported" attribute.
+
+
+5.2 Additional Information about Subscription Template Attributes
+
+
+This section describes additional values for attributes defined in [ipp-
+ntfy].
+
+
+5.2.1notify-recipient-uri (uri)
+
+This section describes the syntax of the value of this attribute for the
+'mailto' Delivery Method. The syntax for values of this attribute for
+other Delivery Method is defined in other Delivery Method Documents.
+
+
+In order to support the 'mailto' Delivery Method, the Printer MUST
+support the following syntax for the 'mailto' Delivery Method when the
+Printer uses SMTP. The line below use RFC 822 syntax rules and terms.
+
+
+ "mailto:" mailbox
+
+Note: the above syntax allows 1 occurrence of 'mailbox'. The occurrence
+of 'mailbox' represents an email address of a Notification Recipient.
+
+For SMTP, the phrase 'address part' of the "notify-recipient-uri"
+attribute value refers to the 'mailbox' part of the value.
+
+The Printer MAY support other syntax for the 'address part' if it
+supports email protocols in addition to SMTP.
+
+
+5.2.2notify-user-data (octetString(63))
+
+This attributes has a special use for the 'mailto' Delivery Method. It
+specifies the email address of the Subscribing Client. It is primarily
+useful when the Notification Recipient is some person other than the
+Subscribing Client. Then the Notification Recipient has a way to reply
+to the Subscribing Client.
+
+
+Herriot, et al. Expires: March 1, 2001 [page 12]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+If a client specifies this Delivery Method in a Subscription Creation
+Operation, and the specified Notification Recipient is not associated
+with the same person as the client, the client SHOULD supply its email
+address as the value of the "notify-user-data" attribute. If the client
+does not supply this attribute, the Printer MUST NOT populate the
+Subscription Object with this attribute.
+
+
+6 Event Notification Content
+
+This section describes the content of an Event Notification sent via the
+'mailto' Delivery Method using the SMTP protocol. This document does
+not describe the content for other email protocols, but an
+implementation should use this section as a model.
+
+
+When a Printer sends an email message via SMTP, the content MUST conform
+to RFC 822. The following sections define the content that a Printer
+MUST send. A Printer MAY send additional content as long as the
+resulting content conforms to RFC 822.
+
+
+Each subsection below specifies the syntax that pertains to the
+subsection. The syntax rules and syntactic terms (e.g. 'date-time') in
+each subsection come from RFC 822, except for the section on "Content-
+Type" which comes from RFC 1521.
+
+
+The Event Notification content has two parts, the headers and the
+message body. The headers precede the message body and are separated by
+a blank line (see [RFC 822]).
+
+
+6.1 Headers
+
+
+When a Printer sends an Event Notification via SMTP, it MUST include the
+following headers. RFC 822 RECOMMENDS that the headers be in the order
+that they appear below.
+
+
+6.1.1'Date' header
+
+Syntax: "Date" ":" date-time
+
+This header contains the date and time that the Event occurred.
+
+The Printer MUST include a "Date" header if and only if it supports the
+"printer-current-time" Printer attribute.
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 13]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+6.1.2 'From' header
+
+Syntax: "From" ":" mailbox
+
+ where
+
+ mailbox = addr-spec / phrase route-addr
+
+This header causes a typical email reader to show the email as coming
+from the Printer that is sending the Event Notification.
+
+The Printer MUST include a "From" header whose syntax is specified
+above.
+
+The Printer MUST use the second alternative of the syntax for 'mailbox'
+defined above (i.e. 'phrase route-addr'). The 'phrase' is the
+Printer's display name and it MUST be the value of the "printer-name"
+Printer attribute. The 'route-addr' MUST contain an email address
+(inside angle brackets) belonging to either an administrator or the
+output-device. This email address NEED NOT be capable of receiving mail.
+There is no Printer attribute to hold this email address, so that it
+cannot be configured using the IPP protocol without an implementation-
+defined attribute extension.
+
+
+6.1.3'Subject' header
+
+Syntax: "Subject" ":" *text
+
+This header specifies the subject of the message and contains a short
+summary of the Event Notification.
+
+The Printer MUST include a "Subject" header whose syntax is specified
+above.
+
+
+The Printer MUST localize the '*text' using the values of the "notify-
+charset" and "notify-natural-language" Subscription Object attributes.
+
+For Printer Events, the '*text' SHOULD start with the localized word
+"printer:", followed by the Printer name, and then followed by the
+localized Event name, e.g., in English: "printer: 'tiger' stopped" or in
+Danish: 'Printeren 'tiger' er standset'.
+
+For Job Events, the '*text' SHOULD start with the localized phrase
+"print job:", followed by the Job name, and then followed by the
+localized Event name, e.g., in English: "print job: 'financials'
+completed".
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 14]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+The wording is implementation dependent. A Notification Recipient MUST
+NOT expect to be able to parse this text. But an email filter might look
+for "printer" or "print job".
+
+
+6.1.4 'Sender' header
+
+Syntax: "Sender" ":" mailbox
+
+This header causes a typical email reader to show the email as coming on
+behalf of the person associated with the Subscribing Client.
+
+
+If the Subscription Object contains the "notify-user-data" attribute,
+and if its value satisfies the RFC 822 syntax rules for 'mailbox', the
+Printer MUST include a "Sender" header whose syntax is specified above.
+Otherwise, the Printer MUST NOT include a "Sender" header.
+
+For the "Sender" header, the 'mailbox' MUST be the value of the "notify-
+user-data" Subscription Object attribute. See section 5.2.2 for details
+about the "notify-user-data" attribute.
+
+
+6.1.5 'Reply-to' header
+
+Syntax: "Reply-to" ":" mailbox
+
+If the Notification Recipient replies to Event Notification email, this
+header causes a typical email reader to send email to the person acting
+as the Subscribing Client. The rules are identical to the "Sender"
+header.
+
+
+If the Subscription Object contains the "notify-user-data" attribute,
+and if its value satisfies the RFC 822 syntax rules for "mailbox", the
+Printer MUST include a "Reply-to" header whose syntax is specified
+above. Otherwise, the Printer MUST NOT include a "Reply-to" header.
+
+For the "Reply-to" header, the "mailbox" MUST be the value of the
+"notify-user-data" Subscription Object attribute. See section 5.2.2 for
+details about the "notify-user-data" attribute.
+
+
+6.1.6 'To' header
+
+
+Syntax: "To" ":" 1#mailbox
+
+See [RFC 1521] for the syntax.
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 15]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+This header specifies the Notification Recipient(s).
+
+The Printer MUST include a "To" header whose syntax is specified above.
+
+The '1#mailbox' MUST be the '1#mailbox' part of the value of the
+"notify-recipient-uri" Subscription attribute, i.e. the part after the
+"mailto:".
+
+
+6.1.7 'Content-type' header
+
+
+Syntax: "Content-Type" ":" type "/" subtype *(";"parameter)
+
+ See [RFC 1521] for the syntactic terms (e.g. 'type').
+
+This header specifies the format of the message body.
+
+The Printer MUST include the "Content-Type" header.
+
+The "notify-mailto-text-only" attribute determines the 'type' and
+'subtype' values. The possible values are "text/plain" and "multipart"
+values.
+
+
+6.2 Message Body
+
+
+The message body MUST contain Human Consumable content as plain text. It
+MAY also contain other types of implementation dependent content.
+
+
+For plain text, the Content-Type of Human Consumable content MUST be
+'text/plain'. For implementation dependent content, the Content-Type of
+Human Consumable content MUST be 'multipart'. The Content-Type of one
+body part MUST be 'text/plain' and the Content-Types of the other body
+parts are implementation dependent. See section 6.3 for a description of
+plain text content.
+
+
+The following table shows the Content-Type of the message body for the
+"notify-mailto-text-only" attribute:
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 16]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+
+
+ "notify- Content-Type Message Body
+ mailto-text- of Message
+ only" Body
+ attribute
+
+
+ false 'text/plain' Human Consumable
+
+ true 'text/plain' Human Consumable plain
+ or* text
+
+ 'multipart' Human Consumable where
+ one body part is plain
+ text
+
+
+
+ * The Content-Type depends on the implementation. A Printer MAY send
+ 'text/plain' only or it MAY send several body parts of various
+ Content-Types within a message body whose Content-Type is
+ 'multipart'.
+
+
+6.3 Plain Text Content
+
+
+When a Printer sends a plain text message, it MUST localize the text
+using the values of the "notify-charset" and "notify-natural-language"
+Subscription Object attributes.
+
+
+Section 9.2 in [ipp-ntfy] specifies the information that a Delivery
+Method MUST specify and a Printer SHOULD send.
+
+
+A Printer SHOULD send the following localized information in the message
+body. The specific wording of this information and its layout are
+implementation dependent.
+
+ a)the Printer name (see Table 3)
+ b)omitted (see below).
+ c)for Printer Events only:
+ i) the Event (see Table 4) and/or Printer state information
+ (see Table 7)
+ d)for Job Events only:
+ i) the job identity (see Table 5)
+ ii) the Event (see Table 4) and/or Job state information (see
+ Table 6)
+
+
+Herriot, et al. Expires: March 1, 2001 [page 17]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+Item b) in the above list is omitted because the Printer sends the time
+of the Event as an email header (see section 6.1.1 on the 'Date'
+header).
+
+
+The subsections of this section specify the attributes that a Printer
+MUST use to obtain this information.
+
+
+The Printer MAY send additional information, depending on
+implementation.
+
+
+Notification Recipients MUST NOT expect to be able to parse the message.
+
+
+The next three sections define the attributes in Event Notification
+Contents that are:
+
+
+ a)for all Events
+
+
+ b)for Job Events only
+
+
+ c)for Printer Events only
+
+
+6.3.1Event Notification Content Common to All Events
+
+
+The Printer MUST send the following information.
+
+
+There is a separate table for each piece of information. Each row in the
+table represents a source value for the information and the values are
+listed in order of preference, with the first one being the preferred
+one. An implementation SHOULD use the source value from the earliest row
+in each table. It MAY use the source value from another row instead, or
+it MAY combine the source values from several rows. An implementation is
+free to determine the best way to present this information.
+
+
+The tables in this section and following sections contain the following
+columns for each piece of information:
+
+
+ a)Source of Value: the name of the attribute that supplies the
+ value for the Event Notification
+
+
+Herriot, et al. Expires: March 1, 2001 [page 18]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+ b)Sends:
+
+ MAY: this is the only value used in the tables. It means that
+ the Printer OPTIONALLY sends this value. However, the Printer
+ SHOULD use at least one value from each table.
+
+
+ c)Source Object: the object from which the source value comes.
+
+
+Table 3 lists the source of the information for the Printer Name. The
+"printer-name" is more user-friendly unless the Notification Recipient
+is in a place where the Printer name is not meaningful. For example, an
+implementation could have the intelligence to send the value of the
+"printer-name" attribute to a Notification Recipient that can access the
+Printer via value of the "printer-name" attribute and otherwise send the
+value of the "notify-printer-uri" attribute.
+
+
+ Table 3 - Printer Name in Event Notification Content
+
+
+
+Source Value Sends Source Object
+
+
+printer-name (name(127)) MAY Printer
+
+notify-printer-uri (uri) MAY Subscription
+
+
+
+
+
+Table 4 lists the source of the information for the Event name. A
+Printer MAY combine this information with state information described
+for Jobs in Table 6 or for Printers in Table 7.
+
+
+ Table 4 - Event Name in Event Notification Content
+
+
+
+Source Value Sends Source Object
+
+
+notify-subscribed-event (type2 keyword) MAY Subscription
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 19]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+6.3.2Additional Event Notification Content for Job Events
+
+
+This section lists the source of the additional information that a
+Printer MUST send for Job Events.
+
+
+Table 5 lists the source of the information for the job name. The "job-
+name" is likely more meaningful to a user than "job-id".
+
+
+ Table 5 - Job Name in Event Notification Content
+
+
+
+Source Value Sends Source Object
+
+
+job-name (name(MAX)) MAY Job
+
+job-id (integer(1:MAX)) MAY Job
+
+
+
+
+
+Table 6 lists the source of the information for the job-state. If a
+Printer supports the "job-state-message" and "job-detailed-state-
+message" attributes, it SHOULD use those attributes for the job state
+information, otherwise, it should fabricate such information from the
+"job-state" and "job-state-reasons". For some Events, a Printer MAY
+combine this information with Event information.
+
+
+ Table 6 - Job State in Event Notification Content
+
+
+
+Source Value Sends Source
+ Object
+
+
+job-state-message (text(MAX)) MAY Job
+
+job-detailed-status-messages (1setOf MAY Job
+text(MAX))
+
+job-state (type1 enum) MAY Job
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 20]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+
+
+Source Value Sends Source
+ Object
+
+
+job-state-reasons (1setOf type2 keyword) MAY Job
+
+
+6.3.3Additional Event Notification Content for Printer Events
+
+
+This section lists the source of the additional information that a
+Printer MUST send for Printer Events.
+
+
+Table 7 lists the source of the information for the printer-state. If a
+Printer supports the "printer-state-message", it SHOULD use that
+attribute for the job state information, otherwise it SHOULD fabricate
+such information from the "printer-state" and "printer-state-reasons".
+For some Events, a Printer MAY combine this information with Event
+information.
+
+
+ Table 7 - Printer State in Event Notification Content
+
+
+
+Source Value Sends Source Object
+
+
+printer-state-message (text(MAX)) MAY Printer
+
+printer-state (type1 enum) MAY Printer
+
+printer-state-reasons (1setOf type2 MAY Printer
+keyword)
+
+printer-is-accepting-jobs (boolean) MAY Printer
+
+
+6.4 Examples
+
+
+This section contains three examples. One is a Job Event and the other
+two are Printer Events, the latter in Danish.
+
+
+A Printer implementation NEED NOT generate Event Notification content
+that is identical or even similar to these examples. In fact it would be
+
+
+Herriot, et al. Expires: March 1, 2001 [page 21]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+unfortunate if every implementation copied these example as is. These
+examples merely show some possibilities and are not necessarily the best
+way to convey information about an Event.
+
+
+6.4.1Job Event Example
+
+
+This section contains an example of an Event Notification of a Job
+Event.
+
+
+A Subscribing Client Mike Jones (who works for xyz Corp.) performs a
+Subscription Creation Operation as part of the Print-Job operation on
+Printer "ipp://tiger@abc.com". Mike Jones specifies that the "job-name"
+is "financials". Mike is printing the Job for Bill Smith at abc Corp.
+The Subscription Object then has the following attributes:
+
+
+
+ Attribute Name Attribute Value
+
+
+ notify-recipient-uri mailto:bsmith@abc.com
+
+ notify-events job-completed
+
+ notify-user-data mjones@xyz.com
+
+ notify-mailto-text-only true
+
+ notify-charset us-ascii
+
+ notify-natural-language en-us
+
+ notify-subscription-id 35692
+
+ notify-sequence-number 0
+
+ notify-printer-up-time 34593
+
+ notify-printer-uri ipp://tiger@abc.com
+
+ notify-job-id 345
+
+ notify-subscriber-user- mjones
+ name
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 22]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+When the Job completes, the Printer generates and sends the following
+email message:
+
+ Date: 17 Jul 00 1632 PDT
+ From: tiger <printAdmin@abc.com>
+ Subject: print job: 'financials' completed
+ Sender: mjones@xyz.com
+ Reply-to: mjones@xyz.com
+ To: bsmith@abc.com
+ Content-type: text/plain
+
+ printer: tiger
+ job: financials
+ job-state: completed
+
+The reader should note that the phrases are not identical to IPP
+keywords. They have been localized to English.
+
+
+6.4.2Printer Event Example
+
+
+This section contains an example of an Event Notification of a Printer
+Event.
+
+
+A Subscribing Client Peter Williams, a Printer admin, performs a Create-
+Printer-Subscriptions operation on Printer "ipp://tiger@abc.com". The
+Subscription Object then has the following attributes:
+
+
+
+ Attribute Name Attribute Value
+
+
+ notify-recipient-uri mailto:pwilliams@abc.com
+
+ notify-events printer-state-changed
+
+ notify-mailto-text-only true
+
+ notify-charset us-ascii
+
+ notify-natural-language en-us
+
+ notify-subscription-id 4623
+
+ notify-sequence-number 0
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 23]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+
+
+ Attribute Name Attribute Value
+
+
+ notify-printer-uptime 23002
+
+ notify-printer-uri ipp://tiger@abc.com
+
+ notify-lease-expiration- 0
+ time
+
+ notify-subscriber-user- pwilliams
+ name
+
+
+When the Printer jams, the Printer generates and sends the following
+email message:
+
+ Date: 29 Aug 00 0832 PDT
+ From: tiger <printAdmin@abc.com>
+ Subject: printer: 'tiger' has stopped
+ To: pwilliams@abc.com
+ Content-type: text/plain
+
+ Printer tiger has stopped with a paper jam.
+
+
+The reader should note that the phrases are not identical to IPP
+keywords. They have been localized to English.
+
+
+6.4.3Printer Event Example (localized to Danish)
+
+
+This section contains an example of an Event Notification of a Printer
+Event localized to Danish.
+
+
+A Subscribing Client Per Jensen, a Printer admin, performs a a Create-
+Printer-Subscriptions operation on Printer "ipp://tiger@def.dk". The
+Subscription Object then has the following attributes:
+
+
+
+ Attribute Name Attribute Value
+
+
+ notify-recipient-uri mailto:pjensen@def.dk
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 24]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+
+
+ Attribute Name Attribute Value
+
+
+ notify-events printer-state-changed
+
+ notify-mailto-text-only true
+
+ notify-charset utf-8
+
+ notify-natural-language da
+
+ notify-subscription-id 50225
+
+ notify-sequence-number 0
+
+ notify-printer-uptime 53217
+
+ notify-printer-uri ipp://tiger@def.dk
+
+ notify-lease-expiration- 0
+ time
+
+ notify-subscriber-user- pjensen
+ name
+
+
+When the Printer jams, the Printer generates and sends the following
+email message:
+
+ Date: 29 Jan 00 0832 CET
+ From: tiger <admin@def.dk>
+ Subject: Printeren 'tiger' er standset
+ To: pjensen@def.dk
+ Content-type: text/plain;charset=utf-8
+
+ Printerens navn er 'tiger'.
+ Printeren er standset.
+ Aarsagen er papir stop.
+
+7 Conformance Requirements
+
+The 'mailto' Delivery Method is RECOMMENDED for a Printer to support.
+
+
+If the Printer supports the 'mailto' Delivery Method, the Printer MUST:
+
+
+1.meet the conformance requirements defined in [ipp-ntfy].
+
+
+Herriot, et al. Expires: March 1, 2001 [page 25]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+2.support the "notify-mailto-text-only " Subscription Object attribute
+ defined in section 5.1.1.
+
+
+3.support the syntax for the "notify-recipient-uri" Subscription Object
+ attribute defined in section 5.2.1
+
+
+4.support the use for the "notify-user-data" Subscription Object
+ attribute defined in section 5.2.2
+
+
+5.support SMTP for sending Event Notifications.
+
+
+6.support the 'text/plain' Content-Type for the message body.
+
+
+7.support sending Event Notification via email with the content
+ specified in section 5.2.
+
+
+8 IANA Considerations
+
+Because the 'mailto' URL scheme is already defined in a standards track
+document [RFC 2368] and registered with IANA, this document does not
+require anything further of IANA.
+
+
+9 Internationalization Considerations
+
+This Delivery Method presents no internationalization considerations
+beyond those covered in the [ipp-ntfy] document, and sections 6.1.3 and
+6.2 of this document.
+
+
+The Notification Recipient is expected to present the email as received
+because the Printer does all necessary localization to the Event
+Notification contents.
+
+
+10 Security Considerations
+
+The biggest security concern is that a Subscribing Client will cause
+unsolicited Event Notifications to be sent to third parties, potentially
+creating denial-of-service problems (i.e., spam). The problem is even
+worse if the third parties are distribution lists.
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 26]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+There exist scenarios where third party notification is required (see
+Scenario #2 and #3 in [ipp-not-req]). The fully secure solution would
+require active agreement of all persons before they can become
+Notification Recipients. However, requirement #9 in [ipp-req] ("There
+is no requirement for IPP Printer receiving the print request to
+validate the identity of an event recipient") argues against this. To
+minimize the risk, a Printer could disallow third party Notification
+Recipients (a traditional facsimile model).
+
+
+The Delivery Method recommends that the Subscribing Client supply his or
+her email address as the value of the "notify-user-data" attribute in
+the Subscription Creation Operation when the Notification Recipient is a
+third party. To reduce the chance of spamming or identify the spammer, a
+Printer could disallow third party Notification Recipients if the
+Subscribing Client doesn't supply the "notify-user-data" attribute with
+a valid email address.
+
+
+Some firewall administrators prevent mail attachments from being
+accepted into their organizations because of the problem of the
+attachments containing computer viruses. The 'mailto' Delivery Method
+allows the Subscribing Client to request that the Content-Type of a
+message body be 'text/plain'.
+
+
+11 References
+ [ipp-iig]
+ Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P.,
+ "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers-
+ guide-v11-01.txt, work in progress, May 9, 2000
+
+[ipp-mod]
+ R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet
+Printing Protocol/1.0: Model and Semantics", <draft-ietf-ipp-model-v11-
+07.txt>, May 22, 2000.[ipp-ntfy]
+ Herriot, R., Hastings, T., Isaacson, S., Martin, J., deBry, R.,
+ Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP
+ Event Notification Specification", <draft-ietf-ipp-not-spec-
+ 04.txt>, August 30, 2000.
+
+[ipp-pro]
+ Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
+ Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
+ 06.txt, May 20, 2000.
+
+[RFC821]
+ Jonathan B. Postel, "Simple Mail Transfer Protocol", RFC 821,
+ August, 1982.
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 27]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+[RFC822]
+ David H. Crocker, "Standard For The Format Of ARPA Internet Text
+ Messages", RFC 822, August 13, 1982.
+
+[RFC1341]
+ N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
+ Extensions): Mechanisms for Specifying and Describing the Format of
+ Internet Message Bodies", RFC 1341, June, 1992.
+
+
+[RFC1521]
+
+ N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
+ Extensions) Part One: Mechanisms for Specifying and Describing the
+ Format of Internet Message Bodies", RFC 1521, September 1993.
+
+[RFC1891]
+ K. Moore, "SMTP Service Extension for Delivery Status
+ Notifications", RFC 1891, January 1996
+
+[RFC2026]
+ S. Bradner, "The Internet Standards Process -- Revision 3", RFC
+ 2026, October 1996.
+
+[RFC2046]
+ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
+ Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+ RFC 2616, June 1999.
+
+[RFC2368]
+ P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL scheme", RFC
+ 2616, July 1998.
+
+ [RFC2616]
+ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
+ Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2633]
+ B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633,
+ June 1999.
+
+
+12 Author's Addresses
+
+ Robert Herriot
+ Xerox Corporation
+ 3400 Hillview Ave., Bldg #1
+ Palo Alto, CA 94304
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 28]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+ Phone: 650-813-7696
+ Fax: 650-813-6860
+ Email: robert.herriot@pahv.xerox.com
+
+ Henrik Holst
+ i-data international a/s
+ Vadstrupvej 35-43
+ 2880 Bagsvaerd, Denmark
+
+ Phone: +45 4436-6000
+ Fax: +45 4436-6111
+ e-mail: hh@i-data.com
+
+ Tom Hastings
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+
+ Phone: 310-333-6413
+ Fax: 310-333-5514
+ e-mail: hastings@cp10.es.xerox.com
+
+
+ Carl-Uno Manros
+ Xerox Corporation
+ 737 Hawaii St. ESAE 231
+ El Segundo, CA 90245
+
+ Phone: 310-333-8273
+ Fax: 310-333-5514
+ e-mail: manros@cp10.es.xerox.com
+
+
+13 Full Copyright Statement
+Copyright (C) The Internet Society (2000). 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.
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 29]
+\f
+
+PWG-DRAFT IPP: The 'mailto:' Delivery Method August 30, 2000
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al. Expires: March 1, 2001 [page 30]
+++ /dev/null
-
-
-
-
-
-
-
-INTERNET-DRAFT
-<draft-ietf-ipp-notify-poll-00.txt> Carl-Uno Manros
- Tom Hastings
- Robert Herriot
- Xerox Corp.
- Harry Lewis
- IBM, Corp.
- March 8, 2000
- Internet Printing Protocol (IPP):
- The 'ipp' Notification Polling Method
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [rfc2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-The IPP notification specification [ipp-ntfy] is an OPTIONAL extension
-to IPP/1.0 and IPP/1.1 that requires the definition of one or more
-delivery methods for dispatching Event Notification reports to
-Notification Recipients. This document describes the semantics and
-syntax of the 'ipp' event Notification delivery method. For this
-delivery method, the client uses an explicit IPP Get-Notifications
-Printer operation in order to request (pull) Event Notifications from
-the IPP Printer.
-
-When a Printer supports the 'ipp' delivery method, it holds each Event
-Notification for a certain length of time. The amount of time is called
-the "event-lease time".. A Printer may assign the same event-lease time
-to each Event Notification or different times. If a Notification
-Recipient does not want to miss Event Notifications, the time between
-consecutive pollings of Subscription objects must be less than the
-event-lease time of the events that occur between pollings. The Get-
-Notifications request indicates whether the client wants to receive all
-pending event Notifications for (1) any Subscription for which the
-client is the owner, (2) any Subscription associated with a Job, (3) any
-Subscription with a particular delivery-method URL, or (4) an identified
-
-
-Manros, Hastings, Herriot, Lewis [page 1]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-set of Subscription objects. With the Get-Notifications operation, the
-Printer returns all existing Event Notifications along with two time
-intervals. One specifies the minimum time at which event-leases of
-future events of the type returned will begin to expire and the other
-specifies the recommended interval for the client to wait before sending
-the next Get-Notifications operation. The second time interval is less
-than the first.
-
-The Printer may keep the channel open if the recommended interval is
-sufficiently short, but in any case the client performs a new Get-
-Notifications operation each time it wants more Event Notifications.
-Since the time interval between consecutive client requests is normally
-less than the event-lease time, consecutive responses will normally
-contain some Event Notifications that are identical. The youngest ones
-in the previous response will become the oldest in the next response.
-The client is expected to filter out these duplicates, which is easy to
-do because of the sequence number in each Event Notification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 2]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-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.1: Model and Semantics [ipp-mod]
- Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
- Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
- Mapping between LPD and IPP Protocols [RFC2569]
- Internet Printing Protocol/1.0 & 1.1: Event Notification
- Specification [ipp-ntfy]
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Model and Semantics" document
-describes a simplified model with abstract objects, their attributes,
-and their operations that are independent of encoding and transport. It
-introduces a Printer and a Job object. The Job object optionally
-supports multiple documents per Job. It also addresses security,
-internationalization, and directory issues.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting over HTTP a message
-body whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 3]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-The "Event Notification Specification" document defines OPTIONAL
-operations that allow a client to subscribe to printing related events.
-Subscriptions include "Per-Job subscriptions" and "Per-Printer
-subscriptions". Subscriptions are modeled as Subscription objects.
-Four other operations are defined for subscription objects: get
-attributes, get subscriptions, renew a subscription, and cancel a
-subscription.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 4]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-
-
- Table of Contents
-
-
-1 Introduction......................................................6
-
-2 Terminology.......................................................7
-
-3 Model and Operation...............................................7
-
-4 Get-Notifications operation.......................................8
- 4.1GET-NOTIFICATIONS REQUEST........................................9
- 4.2GET-NOTIFICATIONS RESPONSE......................................11
-
-5 Extension to Print-Job, Print-URI, Create-Job, Create-Printer-
-Subscription and Create-Printer-Subscription.........................12
- 5.1RESPONSE........................................................12
-
-6 Encoding.........................................................13
-
-7 IANA Considerations..............................................13
-
-8 Internationalization Considerations..............................14
-
-9 Security Considerations..........................................14
-
-10 References.......................................................14
-
-11 Authors' Addresses...............................................15
-
-12 Full Copyright Statement.........................................15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 5]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-
-
-1 Introduction
-
-IPP printers that support the OPTIONAL IPP notification extension [ipp-
-ntfy] either a) accept, store, and use notification subscriptions to
-generate Event Notification reports and implement one or more delivery
-methods for notifying interested parties, or b) support a subset of
-these tasks and farm out the remaining tasks to a Notification Delivery
-Service. The 'ipp' Event Notification delivery method specified in this
-document defines a Get-Notifications operation that may be used in a
-variety of notification scenarios. Its primary intended use is for
-clients that want to be Notification Recipients. However, the Get-
-Notifications operation may also be used by Notification Delivery
-Services for subsequent distribution to the Ultimate Notification
-Recipients.
-
-When a Printer supports the 'ipp' delivery method, it holds each Event
-Notification for a certain length of time. The amount of time is called
-the "event-lease time". A Printer may assign the same event-lease time
-to each event or different times. If a Notification Recipient does not
-want to miss Event Notifications, the time between consecutive pollings
-of Subscription objects must be less than the event-lease time of the
-Event Notifications that occur between pollings. The Get-Notifications
-request indicates whether the client wants to receive all pending Event
-Notifications for (1) any Subscription for which the client is the
-owner, (2) any Subscription associated with a particular Job, (3) any
-Subscription with a particular notification recipient URL, or (4) an
-identified set of Subscription objects. With the Get-Notifications
-operation, the Printer returns all existing Event Notifications along
-with two time intervals. One specifies the minimum time at which event-
-leases of future events of the type returned will begin to expire and
-the other specifies the recommended interval for the client to wait
-before sending the next Get-Notifications operation. The second time
-interval is less than the first.
-
-The Printer may keep the channel open if the recommended interval is
-sufficiently short, but in any case the client performs a new Get-
-Notifications operation each time it wants more Notifications. Since the
-time interval between consecutive client requests is normally less than
-the event-lease time, consecutive responses will normally contain some
-events that are identical. The youngest ones in the previous response
-will become the oldest in the next response. The client is expected to
-filter out these duplicates, which is easy to do because of the sequence
-number in each Notification. The reason for not removing the
-Notifications from the Subscription object with every Get-Notifications
-request, is so that multiple Notification Recipients can be polling the
-same subscription object and so the Get-Notification operation satisfies
-the rule of idempotency. The former is useful if someone is logged in
-to several desktops at the same time and wants to see the same events at
-both places. The latter is useful if the network loses the response.
-
-
-
-Manros, Hastings, Herriot, Lewis [page 6]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-2 Terminology
-
-This section defines the following additional terms that are used
-throughout this document:
-
- REQUIRED: if an implementation supports the extensions described in
- this document, it MUST support a REQUIRED feature.
- OPTIONAL: if an implementation supports the extensions described in
- this document, it MAY support an OPTIONAL feature.
- Notification Recipient - See [ipp-ntfy]
- Subscription object - See [ipp-ntfy]
- Ultimate Notification Recipient - See [ipp-ntfy]
-
-3 Model and Operation
-
-In the IPP Notification Model [ipp-ntfy], one or more Per-Job
-Subscriptions can be supplied in the Job Creation operation or
-OPTIONALLY as subsequent Create-Job-Subscription operations; one Per-
-Printer Subscription can be supplied in the Create-Printer operation.
-The client that creates these Subscription objects becomes the owner of
-the Subscription object.
-
-When creating each Subscription object, the client supplies the "notify-
-recipient" (uri) attribute. The "notify-recipient" attribute specifies
-both a single Notification Recipient that is to receive the
-Notifications when subsequent events occur and the method for
-Notification delivery that the IPP Printer is to use. For the
-Notification delivery method defined in this document, the scheme of the
-URL is 'ipp' and the host SHOULD be the client host's URL. In addition,
-the URL MAY contains a path to allow for applications to have a unique
-URL.
-
-ISSUE 1: The 'ipp' is a convenient reuse of 'ipp', but does it imply the
-existence of a print service at each client that is not a reality?
-
-For most Notification delivery methods, a Printer sends Event
-Notifications to the delivery URL and the Printer does not perform any
-authentication or authorization with the receivers of the Event
-Notifications. For the Notification delivery method defined in this
-document, the client requests Event Notifications from the Printer via a
-Get-Notifications operation, and the Printer performs the same
-authentication and authorization as it does for the Get-Job-Attributes
-operation. That is, a Printer MAY allow a client to perform a Get-
-Notifications operation on any Subscription object or it MAY restrict
-access as follows. Any client that is authenticated (1) as an operator
-or administrator or (2) as the owner of the Subscription object can
-initiate a Get-Notifications operation for that Subscription object.
-
-Because a Printer has to wait for a client to request Event
-Notifications for the 'ipp' delivery method, any Printer that supports
-the 'ipp' notification delivery method MUST hold each Event Notification
-at least for the event-lease time that it advertises to clients. With
-this rule, a single user can login at different places, say his/her
-office, the lab, and/or several desktops in the same room, and receive
-
-Manros, Hastings, Herriot, Lewis [page 7]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-the same Event Notifications from a single Subscription object. In
-addition, a client that gets no response, perhaps because of a network
-failure, can perform the Get-Notifications operations two or more times
-in quick succession and get the same results except for a few newly
-arrived Event Notifications and a few old Event Notifications whose
-event-leases have expired.
-
-The event-lease time assigned to Event Notifications MAY be different
-for each implementation. Furthermore, a particular implementation MAY
-assign different event-lease times to each Event Notification. If a
-Printer assigns different event-lease times to each Event Notification,
-the event-lease time returned with Get-Notifications MUST be a value
-that ensures a client will not miss future Event Notifications.
-
-The client issues a Get-Notifications Printer operation in order to
-initiate the delivery of the pending Notifications held by the Printer
-for the Subscription objects requested. The client can indicate in the
-Get-Notifications request whether it wants to receive all pending
-Notifications for:
-
- 1) any existing Subscription objects for which the client is the
- owner,
-
- 2) any existing Subscription objects whose notification-recipient is a
- specified URL
-
- 3) any existing Subscription objects associated with a job-id or
-
- 4) particular Subscription object(s) (for which it MUST be the owner
- or have read-access rights).
-
-In any case, the Notifications are returned in a response to the Get-
-Notifications request.
-
-If the client requests a persistent channel, then the Printer MAY keep
-the channel open. Either the client or the IPP Printer can disconnect
-the HTTP connection.
-
-
-4 Get-Notifications operation
-
-This REQUIRED operation allows the client to request that pending Event
-Notifications be delivered as a response to this request. The client
-MUST be the owner or have read-access rights of the Subscription objects
-that are involved and the delivery method specified when the
-Subscription objects were created MUST be ipp'. When the Printer
-creates a Subscription Object, either with a Job Creation operation or
-with a Create-Printer-Subscription or Create-Job-Subscription operation
-and a subscription object contains the 'ipp' value for the "notify-
-recipient" operation attribute, the Printer returns the event-lease time
-for Events and the recommended time interval before the client to
-performs the next Get-Notifications operation. The client SHOULD
-perform a Get-Notifications operation at about the recommended interval
-
-
-Manros, Hastings, Herriot, Lewis [page 8]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-and if the Printer receives the Get-Notifications before the event-lease
-time has elapsed, it MUST have all of the Notifications since the
-previous Get-Notification operation or the Subscription object creation,
-whichever was most recent.
-
-Issue 2: Now that the Get-Notification operation does not affect the
-Event Notifications in the Printer, it should not require write access
-to access them.
-
-The IPP Printer MUST accept the request in any state (see [ipp-mod]
-"printer-state" and "printer-state-reasons" attributes) and MUST remain
-in the same state with the same "printer-state-reasons".
-
-Access Rights: The authenticated user (see [ipp-mod] section 8.3)
-performing this operation must either be the Subscription object owner
-(as determined when the Subscription object was created by the Job
-Creation operation, Create-Job-Subscription, or Create-Printer-
-Subscription operations) or an operator or administrator of the Printer
-object (see [ipp-mod] Sections 1 and 8.5). Otherwise, the IPP object
-MUST reject the operation and return: 'client-error-forbidden', 'client-
-error-not-authenticated', or 'client-error-not-authorized' as
-appropriate.
-
-Issue 3: Is it possible for this operation to have an option that causes
-it to delay completing its response? It would initially returns all
-existing Event Notifications. Then it would return additional
-notifications as they occur for some period of time. The client would
-receive these Event Notifications as they occur. The question is
-whether http servers or proxies would behave in this manner so that the
-client would get the Event Notifications without delay after they are
-sent by the http server? It has been suggested that the Printer send
-each burst of Event Notifications be in a separate message body where
-each message body is part of a multipart MIME content-type.
-
-
-4.1 Get-Notifications Request
-
-The following groups of attributes are part of the Get-Notifications
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.1.
-
- Target:
- The "printer-uri" (uri) operation attribute which is the target for
- this operation as described in [ipp-mod] section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in [ipp-mod] section 8.3.
-
-
-
-Manros, Hastings, Herriot, Lewis [page 9]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
- "notification-recipient" (url):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It is a URL that identifies one or
- more Subscription objects for which Event Notifications are being
- requested. If the client supplies this attribute, but no
- notification-recipients are found, the IPP Printer MUST return the
- 'client-error-not-found' status code. If some are found and others
- are not, the ones that are not found are return in the Unsupported
- Attributes. By definition, if a notification-recipient URL
- exists, there must be at least one Subscription object.
-
-
-
- Note: this attribute allows a subscribing client to pick URLs that
- are unique, e.g. the client's own URL or a friend's URL, which in
- both cases is likely the URL of the person's host. An application
- could make a URL unique for each application if it wants. If a
- client uses such a URL as the value of this attribute, the client
- gets event Notifications for all Subscription objects whose
- "notification-recipient" is the specified URL. This mechanism is
- more general than getting all subscriptions owned by a client. It
- allows clients who didn't subscribe to get Event Notifications
- without knowing job-ids or subscription-ids.
-
-
-ISSUE 4: The "notification-recipient" option allows a client to group
-multiple Subscription-ids with a single URL. A client might decide to
-use the same URL for all subscriptions for a user, or it might have a
-separate URL for each client program. In addition a client might use an
-URL belonging to some other known user and let that user access Event
-Notifications using that URL. Is the above option useful?
-
- "subscription-ids" (1setOf integer(1:MAX)):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It is an integer value that identifies
- one or more Subscription objects for which Event Notifications are
- being requested. If the client supplies this attribute, but none
- of the Subscription objects are found, the IPP Printer MUST return
- the 'client-error-not-found' status code. If some are found and
- others are not, the ones that are not found are return in the
- Unsupported Attributes.
-
-
- "job-ids" (1setOf integer(1:MAX)):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute. It is an integer value that identifies
- one or more job-ids. These job-ids identify the Subscription
- objects for which Event Notifications are being requested. If the
- client supplies this attribute, but no Jobs are found, the IPP
- Printer MUST return the 'client-error-not-found' status code. If
- some are found and others are not, the ones that are not found are
- returned in the Unsupported Attributes. It is not an error if
- there are no Subscription objects for a Job.
-
-
-Manros, Hastings, Herriot, Lewis [page 10]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
- If the client supplies none of the last three attributes described
- for this operation, then the IPP Printer returns Event
- Notifications for all Subscription objects for which the client is
- the owner and the "notify-recipients" attribute is 'ipp'. It is
- not an error if there are currently no Subscription objects for
- this client; the response then contains no Notifications.
-
-
-ISSUE 5: Does the mechanism described in the above paragraph describe a
-useful option that "notification-recipient" alone cannot do? Should this
-case be an error instead?
-
-
- If a client supplies more than one of the last three attributes
- described for this operation, the Printer returns Event
- Notifications for all Subscription objects specified by all
- attributes. If these attributes describe duplicate Event
- Notifications, the Printer MAY remove them.
-
-
-ISSUE 6: Is it better if "notification-recipient" is the only way to
-request Event Notification? If so, this behaves more like other
-notification delivery methods where a recipient receives those and only
-those events with its delivery URL. Furthermore, if there is a single
-mechanism of "notification-recipient" for a client to specify Event
-Notifications, a Printer can better optimize event-leases because it
-knows which events will be accessed together. If client can specify
-subscription-ids, each request can contain a different mix of
-subscription-ids.
-
-
-
-4.2 Get-Notifications Response
-
-The Printer object returns either an immediate error response or a
-successful response with status code: 'successful-ok' when the first
-event occurs, i.e., when the Printer delivers the first Event
-Notification.
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in [ipp-mod] sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.2.
-
- "recommended-time-interval" (integer(0:MAX)):
- The value of this attribute is the recommended number of seconds
- that SHOULD elapse before the client performs this operation again
- for these Subscription objects. A client MAY perform this operation
-
-
-Manros, Hastings, Herriot, Lewis [page 11]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
- at any time, and a Printer MUST respond with all existing
- Notifications. A client observes this value in order to be a "good
- network citizen". The value that a Printer returns for this
- attribute MUST NOT exceed 80% of the "event-lease-time-interval" in
- order to give a client plenty of time to perform another Get-
- Notifications operation before the event-lease of the oldest Event
- Notifications expire.
-
- "event-lease-time-interval" (integer(0:MAX)):
- The value of this attribute is the minimum number of seconds until
- the event-lease expiration time for all future Event Notifications
- associated with the Subscription objects generating the requested
- Event Notifications. Thus this number is the maximum number of
- seconds that elapses before this client SHOULD issue this operation
- again for these Subscription objects. A Printer MUST preserve all
- Notifications that occur for the number of seconds specified by
- this attribute starting at the time it is sent in a response. A
- client MAY perform this operation at any time, and a Printer MUST
- respond with all existing Event Notifications. If a Printer
- receives this operation after this time interval, it MAY have
- discarded some Notifications since the last response.
-
-
-Group 2: Unsupported Attributes
-
- See [ipp-mod] section 3.1.7 for details on returning Unsupported
- Attributes.
-
- If the "subscription-ids" attribute contained subscription-ids that
- do not exist, the Printer returns them in this group as value of
- the "subscription-ids" attribute.
-
-Group 3 through N: Notification Attributes
-
- The Printer object responds with one Event Notification per Group
- for each Notification that meets the criteria specified by the
- request.(see [ipp-ntfy]).
-
-5 Extension to Print-Job, Print-URI, Create-Job, Create-Printer-
- Subscription and Create-Printer-Subscription
-
-
-5.1 Response
-
-When Print-Job, Print-URI or Create-Job contains a "job-notify"
-attribute and the "notify-recipient" is 'ipp', the response contains two
-additional Operation Attributes that pertain to subscriptions.
-
-When Create-Job-Subscription or Create-Printer-Subscription operation
-contains a "notify-recipient" that is 'ipp', the response contains two
-additional Operation Attributes that pertain to subscriptions.
-
-Group 1: Operation Attributes
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 12]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
- "recommended-time-interval" (integer(0:MAX)):
- The value of this attribute is the recommended number of seconds
- that SHOULD elapse before the client SHOULD perform the Get-
- Notification operation for the first time with any Subscription
- objects returned with this job. A client MAY perform the Get-
- Notification operation at any time, and a Printer MUST respond with
- all existing Notifications. A client observes this value in order
- to be a "good network citizen". The value that a Printer returns
- for this attribute MUST NOT exceed 80% of the "event-lease-time-
- interval" in order to give a client plenty of time to perform
- another Get-Notifications operation before the event-lease of the
- oldest events expire.
-
-
- "event-lease-time-interval" (integer(0:MAX)):
- The value of this attribute is the minimum number of seconds until
- the event-lease expiration time for all future Event Notifications
- associated with the Subscription objects generating the requested
- Event Notifications. Thus this number is the maximum number of
- seconds that elapses before a client SHOULD perform the Get-
- Notification operation for the first time with any Subscription
- objects returned with this job. A Printer MUST preserve all
- Notifications that occur for the number of seconds specified by
- this attribute starting at the time it is sent in a response. A
- client MAY perform the Get-Notification operation at any time, and
- a Printer MUST respond with all existing Event Notifications. If a
- Printer receives a Get-Notification operation after this time
- interval, it may have discarded some Notifications since the last
- response.
-
-
-
-6 Encoding
-
-The operation-id assigned for the Get-Notification operation is:
-
- 0x00??
-
-and should be added to the next version of [ipp-mod] section 4.4.15
-"operations-supported".
-
-This notification delivery method uses the IPP transport and encoding
-[ipp-pro] for the Get-Notifications operation with one extension:
-
- notification-attributes-tag = %x07 ; tag of 7
-
-
-7 IANA Considerations
-
-There is nothing to register.
-
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 13]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-8 Internationalization Considerations
-
-With the 'ipp' method defined in this document, the client cannot
-request the Human Consumable form by supplying the "notify-format"
-operation attribute (see [ipp-ntfy]). The only supported value for this
-delivery method is "application/ipp". Therefore, the IPP Printer does
-not have to perform any localization with this notification delivery
-method. However, the client when it receives the Get-Notifications
-response is expected to localize the attributes that have the 'keyword'
-attribute syntax according to the charset and natural language requested
-in the Get-Notifications request.
-
-
-9 Security Considerations
-
-The IPP Model and Semantics document [ipp-mod] discusses high level
-security requirements (Client Authentication, Server Authentication and
-Operation Privacy). Client Authentication is the mechanism by which the
-client proves its identity to the server in a secure manner. Server
-Authentication is the mechanism by which the server proves its identity
-to the client in a secure manner. Operation Privacy is defined as a
-mechanism for protecting operations from eavesdropping.
-
-Unlike other Event Notification delivery methods in which the IPP
-Printer initiates the Event Notification, with the method defined in
-this document, the Notification Recipient is the client who issues the
-Get-Notifications operation. Therefore, there is no chance of "spam"
-notifications with this method. Furthermore, such a client can close
-down the HTTP channel at any time, and so can avoid future unwanted
-Event Notifications at any time.
-
-
-10 References
-
-[ipp-mod]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.1: Model and Semantics", <draft-ietf-
- ipp-model-v11-06.txt>, March 1, 2000.
-
-[ipp-ntfy]
- Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
- Bergman, R., "Internet Printing Protocol/1.1: IPP Event
- Notification Specification", <draft-ietf-ipp-not-spec-02.txt>,
- March 8, 2000.
-
-[ipp-pro]
- Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
- 05.txt, March 1, 2000.
-
-[rfc2026]
- S. Bradner, "The Internet Standards Process -- Revision 3", RFC
- 2026, October 1996.
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 14]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-[RFC2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-
-11 Authors' Addresses
-
-
- Carl-Uno Manros
- Xerox Corporation
- 701 Aviation Blvd.
- El Segundo, CA 90245
-
- Phone: 310-333-
- Fax: 310-333-5514
- e-mail: manros@cp10.es.xerox.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
- Robert Herriot
- Xerox Corp.
- 3400 Hill View Ave, Building 1
- Palo Alto, CA 94304
-
- Phone: 650-813-7696
- Fax: 650-813-6860
- e-mail: robert.herriot@pahv.xerox.com
-
- Harry Lewis
- IBM
- P.O. Box 1900
- Boulder, CO 80301-9191
-
- Phone: (303) 924-5337
- FAX:
- e-mail: harryl@us.ibm.com
-
-
-12 Full Copyright Statement
-
-Copyright (C) The Internet Society (2000). 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,
-
-
-Manros, Hastings, Herriot, Lewis [page 15]
-
- Expires: September 8, 2000
-\f
-
-
-INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manros, Hastings, Herriot, Lewis [page 16]
-
- Expires: September 8, 2000
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML><HEAD>
+<TITLE>404 Not Found</TITLE>
+</HEAD><BODY>
+<H1>Not Found</H1>
+The requested URL /internet-drafts/draft-ietf-ipp-notify-poll-02.txt was not found on this server.<P>
+<HR>
+<ADDRESS>Apache/1.3.11 Server at www2.ietf.org Port 80</ADDRESS>
+</BODY></HTML>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML><HEAD>
+<TITLE>404 Not Found</TITLE>
+</HEAD><BODY>
+<H1>Not Found</H1>
+The requested URL /internet-drafts/draft-ietf-ipp-ops-admin-req-00.txt was not found on this server.<P>
+<HR>
+<ADDRESS>Apache/1.3.11 Server at www2.ietf.org Port 80</ADDRESS>
+</BODY></HTML>
+++ /dev/null
-INTERNET-DRAFT Carl Kugler
-<draft-ietf-ipp-ops-set2-00.txt> IBM Corporation
- T. Hastings
- Xerox Corporation
- H. Lewis
- IBM Corporation
- September 19, 1999
-
- Internet Printing Protocol/1.1: Set2 Operations
-
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
- Abstract
-
-This document specifies 14 additional OPTIONAL operations for use with
-the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1
-[ipp-mod, ipp-pro]. These operations are 7 Printer object operations
-that operators/administrators may perform on a Printer object:
-
- Set-Printer-Attributes
- Enable-Printer
- Disable-Printer
- Reset-Printer
- Restart-Printer
- Non-Process-Run-Out
- Shutdown-Printer
-
-and 7 Job object operations that end-users may perform on their jobs and
-operators/administrators may perform on any job, depending on
-circumstances:
-
- Set-Job-Attributes
- Reprocess-Job
- Cancel-Current-Job (though the target is the Printer object)
-
-Kugler, Hastings, Lewis [Page 1]
- Expires: March 19, 200
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- Pause-Current-Job (though the target is the Printer object)
- Resume-Job
- Promote-Job
- Space-Current-Job (though the target is the Printer object)
-
-In addition, two operation attributes are defined: "printer-message-
-from-operator" and "job-message-from-operator" are included to set the
-corresponding Printer and Job Description attributes with the same
-names. And the "when" operation attribute is added to the IPP/1.1
-Pause-Printer operation.
-
-Finally, new status codes: 'client-error-attributes-not-settable' and
-'server-error-printer-is-in-standby-mode' are added.
-
-The scope of IPP, is characterized in RFC2526 "Design Goals for an
-Internet Printing Protocol". It is not the intent of this document to
-revise or clarify this scope or conjecture as to the degree of industry
-adoption or trends related to IPP within printing systems. It is the
-intent of this document to extend the original set of operations - in a
-similar fashion to the Set1 extensions which referred to IPP/1.0 and
-were later incorporated into IPP/1.1.
-
-This document is intended for registration following the registration
-procedures of IPP/1.0 [RFC2566] and IPP/1.1 [ipp-mod]. This version
-includes the comments discussed at the IPP telecon, on 6/23/1999,
-6/30/1999, at the IETF IPP WG meeting, 7/7/99-7/8/99, in Copenhagen, and
-the IPP telecon, 7/17/1999, the August, 1999 IPP meeting in Alaska and
-subsequent phone conferences and discussions. Specifically, the 9/16
-update refers to this set of extensions simply as "Set2" rather than
-using the term "Administrative" which was misleading, controversial and
-incorrect as an overall description. Also, two new attributes have been
-proposed to clarify the intent of each operation in terms of its target,
-the Printer vs. the Print Job. Unresolved ISSUES are highlighted like
-this in the .doc and .pdf files.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 2]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-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.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
-
-
-The "Design Goals for an Internet Printing Protocol" document 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.0. A few OPTIONAL operator operations have been
-added to IPP/1.1.
-
-The "Rationale for the Structure and Model and Protocol for the Internet
-Printing Protocol" document describes IPP from a high level view,
-defines a roadmap for the various documents that form the suite of IPP
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The "Internet Printing Protocol/1.1: Encoding and Transport" document is
-a formal mapping of the abstract operations and attributes defined in
-the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
-rules for a new Internet MIME media type called "application/ipp". This
-document also defines the rules for transporting over HTTP a message
-body whose Content-Type is "application/ipp". This document defines a
-new scheme named 'ipp' for identifying IPP printers and jobs.
-
-The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
-insight and advice to implementers of IPP clients and IPP objects. It
-is intended to help them understand IPP/1.1 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 "Mapping between LPD and IPP Protocols" document gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 3]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- Table of Contents
-
-
-1. Introduction.....................................................6
-
-2. New objects......................................................6
- 2.1 Interpreter object............................................6
-
-3. New Operation attributes.........................................6
- 3.1 New operation attribute: "printer-message-from-operator"
- (text(127))6
- 3.2 New operation attribute: "job-message-from-operator" (text(127))
- 8
- 3.3 New operation attribute for Get-Printer-Attributes: "factory-
- settings" (boolean)................................................9
- 3.4 New operation attribute for Pause-Printer: "when" (type2 keyword)
- 10
- 3.5 New OPTIONAL operation attribute for any Job or Printer operation:
- "device-name" (name(127)).........................................11
- 3.5.1 Revised text for [ipp-mod] for the "device-name" extension12
- 3.6 Summary of the operation attributes for the Printer operations13
- 3.7 Summary of the operation attributes for the Job operations...13
-
-4. New Printer Description Attributes..............................15
- 4.1 printer-settable-attributes (1setOf type2 keyword)...........15
- 4.2 interpreter-settable-attributes (1setOf type2 keyword).......15
- 4.3 job-settable-attributes (1setOf type2 keyword)...............16
- 4.4 printer-controls-other-protocols (boolean)...................16
- 4.5 printer-message-time (integer(MIN:MAX))......................18
- 4.6 printer-message-date-time (dateTime).........................19
- 4.7 printer-message-operation (type2 keyword)....................19
- 4.8 when-values-supported (1setOf type2 keyword).................20
- 4.9 device-names-supported (1setOf name(127))....................21
-
-5. Additional values for "printer-state-reasons" and "job-state-reasons"
-attributes.........................................................21
- 5.1 Value for "printer-state-reasons": 'standby'................21
- 5.2 Value for "job-state-reasons": 'job-paused'.................22
-
-6. New status codes................................................22
- 6.1 New status code: 'client-error-attributes-not-settable'......22
- 6.2 New status code: 'server-error-printer-is-in-standby-mode'...23
-
-7. Summary of Set 2 operations and Operation-Id Assignments........23
- 7.1 Printer Operations...........................................24
- 7.1.1 Set-Printer-Attributes Operation.........................24
- 7.1.2 Disable-Printer Operation................................29
- 7.1.3 Enable-Printer Operation.................................30
- 7.1.4 Reset-Printer operation..................................31
- 7.1.5 Restart-Printer operation................................32
- 7.1.6 Non-Process-Run-Out Operation............................33
-
-
-Kugler, Hastings, Lewis [Page 4]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- 7.1.7 Shutdown-Printer Operation...............................34
- 7.2 Job Operations...............................................36
- 7.2.1 Set-Job-Attributes.......................................36
- 7.2.2 Reprocess-Job Operation..................................40
- 7.2.3 Cancel-Current-Job Operation.............................40
- 7.2.4 Pause-Current-Job operation..............................41
- 7.2.5 Resume-Job operation.....................................43
- 7.2.6 Promote-Job operation....................................43
- 7.2.7 Space-Current-Job operation..............................44
-
-8. IANA Considerations.............................................45
-
-9. Internationalization Considerations.............................45
-
-10.Security Considerations........................................46
-
-11.Author's Addresses.............................................46
-
-12.References.....................................................46
-
-13.Change History.................................................47
- 13.1Changes to the July 19, 1999 version to make the September 19,
- 1999 version......................................................47
- 13.2Changes to the June 30, 1999 version to make the July 19, 1999
- version 47
-
-14.Appendix A: Full Copyright Statement...........................49
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 5]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-1. Introduction
-
-
-The Internet Printing Protocol (IPP) is an application level protocol
-that can be used for distributed printing using Internet tools and
-technologies. IPP version 1.1 (IPP/1.1) focuses only on end user
-functionality with a few administrative operations included. This
-document defines additional OPTIONAL end user, operation, and
-administrator operations used to control Jobs and Printers. This
-document is a registration proposal for an extension to IPP/1.0 and
-IPP/1.1 following the registration procedures in those documents.
-
-
-
-2. New objects
-
-
-This section defines the new Interpreter object.
-
-
-2.1 Interpreter object
-
-
-The Interpreter object models the document format interpreters that are
-contained in the Printer object. Depending on implementation, the
-Printer object attributes whose values depend on the interpreter, i.e.,
-on the "document-format" of the document being processed, are considered
-to be Interpreter object attributes instead. A Get-Printer-Attributes
-operations returns Printer and Interpreter objects as specified in the
-"requested-attributes" supplied by the client. Depending on the value
-of the "document-format" attribute supplied by the client in the Get-
-Printer-Attributes request (or the "document-format-default", if the
-client omits the "document-format" attribute), selects the corresponding
-Interpreter object.
-
-Note: the addition of the Interpreter object is completely compatible
-with IPP/1.0 and IPP/1.1 (see the description of the "document-format"
-operation attribute in [ipp-mod] section 3.2.5.1 Get-Printer-Attributes
-request). The protocol and semantics are the same whether or not the
-Interpreter object is used to distinguish attributes that depend on the
-"document-format".
-
-
-3. New Operation attributes
-
-This section defines the new "printer-message-from-operation" and "job-
-message-from-operator" operation attributes that set the corresponding
-Printer and Job Description attributes.
-
-3.1 New operation attribute: "printer-message-from-operator"
-(text(127))
-
-Type of registration: attribute
-
-
-Kugler, Hastings, Lewis [Page 6]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Proposed keyword name of this attribute: "printer-message-from-
-operator"
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Operation
-Operations to be used with if the attribute is an operation attribute:
-See below
-Object (Job, Printer, etc. if bound to an object): Printer (already in
-IPP/1.0 and IPP/1.1)
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-text(127)
-
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-"printer-message-from-operator" (text(127))
- The client OPTIONALLY supplies this attribute. The Printer object
- SHOULD supports this operation attribute if it supports the
- corresponding Printer Description attribute. The value of this
- attribute is a message from the operator about the Printer object
- on which the operator is performing the operation. If supported,
- the Printer copies the value to the Printer's "printer-message-
- from-operator" Printer Description attribute (see [ipp-mod] section
- 4.4.25), automatically sets the value of the Printer's "printer-
- message-time" with the current value of the Printer's "printer-up-
- time" attribute, the value of the "printer-message-date-time" with
- the current value of the Printer's printer-current-date-time"
- attribute, and the value of the Printer's "printer-message-
- operation" with the operation-id value of this operation (see [ipp-
- mod] section 4.4.15).
-
- If the client omits this attribute, the Printer does not change the
- value of its "printer-message-from-operator", "printer-message-
- time", "printer-message-date-time", and "printer-message-operation"
- Printer Description attributes.
-
- If the client supplies this attribute with a zero-length text value
- or with a value consisting solely of white space, the Printer
- copies that value as any other value to the Printer's "printer-
- message-from-operator" and sets the "printer-message-time",
- "printer-message-date-time", and "printer-message-operation"
- attributes. Supplying such a value is the way that the operator
- indicates that there is no longer a printer message from the
- operator (rather than using the "out-of-band" 'no-value' value).
-
-
-This operation attribute is defined for use with the following operator
-operations on the Printer object:
-
- Pause-Printer - see [ipp-mod] section 3.2.7
- Resume-Printer - see [ipp-mod] section 3.2.8
- Purge-Jobs - see [ipp-mod] section 3.2.9
- Disable-Printer - see section 7.1.2
-
-Kugler, Hastings, Lewis [Page 7]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- Enable-Printer - see section 7.1.3
- Reset-Printer - see section 7.1.4
- Restart-Printer - see section 7.1.5
- Non-Process-Run-Out - see section 7.1.6
- Shutdown-Printer - see section 7.1.7
-
-
-The "printer-message-from-operator" operation attribute MUST NOT be
-supported as an operation attribute for the Set-Printer-Attributes
-operation. If the operator wants to set the Printer's "printer-message-
-from-operator" Printer Description attribute when issuing the Set-
-Printer-Attributes operation, the client supplies the "printer-message-
-from-operator" with its new value as one of the Printer Description
-attributes in Group 2 in the request. The Printer also updates the
-Printer's "printer-message-date-time" and "printer-message-operation"
-Printer Description attributes. If the client does not explicitly
-supply the "printer-message-from-operator" with its new value, the
-Printer leaves the value of the Printer's "printer-message-from-
-operator" Printer Description attribute unchanged.
-
-
-3.2 New operation attribute: "job-message-from-operator" (text(127))
-
-Type of registration: attribute
-Proposed keyword name of this attribute: "job-message-from-operator"
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Operation
-Operations to be used with if the attribute is an operation attribute:
-See below
-Object (Job, Printer, etc. if bound to an object): Job (already in
-IPP/1.0 and IPP/1.1)
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-text(127)
-
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-"job-message-from-operator" (text(127))
- The client OPTIONALLY supplies this attribute. The Printer object
- SHOULD supports this operation attribute if it supports the
- corresponding Job Description attribute. The value of this
- attribute is a message from the operator about the Job object on
- which the operator has just performed an operation. If supported,
- the Printer copies the value to the Job's "job-message-from-
- operator" Job Description attribute (see [ipp-mod] section 4.3.16).
-
- If the client omits this attribute, the Printer does not change the
- value of its "printer-message-from-operator" Job Description
- attribute.
-
- If the client supplies this attribute with a zero-length text value
- or with a value consisting solely of white space, the Printer
-
-Kugler, Hastings, Lewis [Page 8]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- copies that value as any other value to the job's "job-message-
- from-operator". Supplying such a value is the way that the
- operator indicates that there is no longer a job message from the
- operator (rather than using the "out-of-band" 'no-value' value).
-
- Note: There are no corresponding 'job-message-time", "job-message-
- date-time", and "job-message-operation" Job Description attributes,
- since the usual lifetime of a job is limited.
-
-
-This operation attribute is defined for use with the following operator
-operations on the Job object:
-
- Cancel-Job - see [ipp-mod] section 3.2.4
- Hold-Job - see [ipp-mod] section 3.3.5
- Release-Job - see [ipp-mod] section 3.3.6
- Restart-Job - see [ipp-mod] section 3.3.7
- Reprocess-Job - see section 7.2.2
- Cancel-Current-Job - see section 7.2.3
- Pause-Current-Job - see section 7.2.4
- Resume-Job - see section 7.2.5
- Promote-Job - see section 7.2.6
- Space-Current-Job - see section 7.2.7
-
-
-The "job-message-from-operator" operation attribute MUST NOT be
-supported as an operation attribute for the Set-Job-Attributes
-operation. If the operator wants to set the Job's "job-message-from-
-operator" Job Description attribute when issuing the Set-Job-Attributes
-operation, the client supplies the "job-message-from-operator" with its
-new value as one of the Job Description attributes in Group 2 in the
-request. Otherwise, the Printer leaves the value of the Job's "job-
-message-from-operator" Job Description attribute unchanged by not
-explicitly setting the attribute.
-
-
-3.3 New operation attribute for Get-Printer-Attributes: "factory-
-settings" (boolean)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: "factory-settings"
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Operation
-Operations to be used with if the attribute is an operation attribute:
-Get-Printer-Attributes
-Object (Job, Printer, etc. if bound to an object): N/A
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-boolean
-
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-
-
-Kugler, Hastings, Lewis [Page 9]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- "factory-settings" (boolean)
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute, if it supports the Set-Printer-
- Attributes operation. If the client omits this attribute or
- supplies the 'false' value, the Printer returns the current values
- of the requested attributes that are settable, i.e., the values
- that have been set by previous Set-Printer-Attributes. If the
- client supplies the 'true' value, the Printer returns the factory
- settings, i.e., the inherent values supported by the implementation
- as shipped from the manufacturer or established at install time.
- This operation attribute allows an operator to determine which
- values are supported in an implementation after having modified a
- settable attribute. Attributes that are not settable are not
- affected by this operation attribute, so that the Printer returns
- the same values for non-settable attribute when either the 'true'
- or 'false' value has been supplied. If this operation attribute is
- supported, both values MUST be supported.
-
-3.4 New operation attribute for Pause-Printer: "when" (type2 keyword)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: "when"
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Operation
-Operations to be used with if the attribute is an operation attribute:
-Pause-Printer, Reset-Printer, Non-Process-Run-Out, Shutdown-Printer, and
-Pause-Current-Job
-Object (Job, Printer, etc. if bound to an object): N/A
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-type2 keyword
-
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
- "when" (type2 keyword)
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute, if it supports this operation.
- The value of this attribute indicates when to pause, reset, or
- shutdown the printer. If the client omits this attribute, the
- Printer assumes the 'after-current-job' value. The 'after-current-
- job' value is REQUIRED to be supported if the "when" attribute is
- supported; the remaining values are OPTIONAL.
-ISSUE 1: Can a client determine the values of "when" that are supported
-for operations (Pause-Printer, Reset-Printer, Shutdown-Printer, and
-Pause-Current-Job)?
- TH> Just add a "when-values-supported" that applies to all of the
- four operations supported, with the exception of Pause-Current-Job.
- For Pause-Current-Job, only the 'now' and 'after-current-copy' have
- any meaning, so the other two values ('after-current-job' and
- 'after-all') don't apply.
-
- HRL> Or, "just say NO". The client can't determine the values of
-
-Kugler, Hastings, Lewis [Page 10]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- "when" supported. The client may specify a value of when and the
- implementation will do it's best to deliver as close to the desired
- behavior as possible within the constraints of the device or
- environment. The client may determine the actual result based on
- final status and/or notification feedback.
-
-
- Standard keyword values are:
- 'now' - cancel the currently printing job(s) and shutdown the
- Printer. Jobs in the 'held' and 'pending' state remain
- in those states.
- 'after-current-copy' - shutdown the Printer after the current
- job finishes printing its current copy. Jobs in the
- 'held' and 'pending' state remain in those states.
- 'after-current-job' - shutdown the Printer after the current
- job finishes printing (all its copies). Jobs in the
- 'held' and 'pending' state remain in those states.
- 'after-all' - shutdown the Printer after all 'pending' jobs
- finish printing. Jobs in the 'held' state remain in the
- 'held' state.
-
-
-3.5 New OPTIONAL operation attribute for any Job or Printer operation:
-"device-name" (name(127))
-
-Type of registration: attribute
-Proposed keyword name of this attribute: "device-name"
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Operation
-Operations to be used with if the attribute is an operation attribute:
-all
-Object (Job, Printer, etc. if bound to an object): N/A
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-name(127)
-
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
- "device-name" (name(127))
- This OPTIONAL Printer operation attribute contains the name of a
- device which is associated with this Printer object. The named
- device is the actual target of the specified Printer operation,
- that is, the Printer object MUST pass the operation through to the
- device rather than affecting the Printer object specified by the
- "printer-uri" operation attribute. See the Job object attribute
- "output-device-assigned" in [IPP-MOD] which identifies the named
- device that the job was assigned to by the Printer object. See the
- Printer object attribute "device-names-supported" in section 4.9 of
- this document.
-
- ISSUE 2 - Shouldn't the Printer object also be affected? In other
- words, if the "device-name" is supplied with the Pause-Printer
-
-
-Kugler, Hastings, Lewis [Page 11]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- operation to pause the actual device, shouldn't the Printer object
- also enter the 'stopped' state with the 'paused' "printer-state-
- reasons" value set?
-
- ISSUE 3 - An implementation is free to support the "device-name"
- operation attribute on any operation, but NEED NOT support it on
- all operations, if it supports it on some, correct?
-
- ISSUE 4 - Could we specify a minimum set of operations which, if
- supported, MUST also support the "device-name" operation attribute,
- if the implementation supports the "device-name" operation
- attribute on any operation?
-
-
-3.5.1 Revised text for [ipp-mod] for the "device-name" extension
-
-The "device-name" extension recommends that the following text be added
-to the IPP-MOD document in section 3.2, "Printer Operations":
-
- All Printer operations are directed at Printer objects OR at named
- devices associated with Printer objects. A client MUST always
- supply the "printer-uri" operation attribute in order to identify
- the correct target of the operation. A client MAY also supply the
- "device-name" operation attribute in order to pass the operation to
- the named device (rather than affecting the Printer object
- specified by "printer-uri")."
-
- ISSUE 5 (repeat of 2) - Shouldn't the Printer object also be
- affected? In other words, if the "device-name" is supplied with
- the Pause-Printer operation to pause the actual device, shouldn't
- the Printer object also enter the 'stopped' state with the 'paused'
- "printer-state-reasons" value set?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 12]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-
-
-
-3.6 Summary of the operation attributes for the Printer operations
-
-The following table shows the operation attributes for the Printer
-operations that a client MAY supply in a request. Operation parameters
-and attributes that a client MUST supply are not shown. Also
-"requesting-user-name" is not shown, though it is RECOMMENDED that a
-client supply it in every request.
-Legend:
- R - REQUIRED for a Printer to support
- O - OPTIONAL for a Printer to support; the Printer ignores the
-attribute if not supported
-
-Operation Pau Resu Pur Get- Set- Enab Disa Res Rest Non Shu
-Attribute se- me- ge- Print Print le- ble- et- art- - t
- Pri Prin Job er- er- Prin Prin Pri Prin Pro dow
- nte ter s Attri Attri t ter nte ter ces n-
- r butes butes r s- Pri
- Run nte
- - r
- Out
-
-document- R R
-format
-
-factory- O
-settings
-
-printer- O O O O O O O O
-message-
-from-
-operator
-
-job-type O O
-
-when O O O
-
-reset- R
-function
-
-
-synchronize O
-
-shutdown- R
-function
-
-device-name O O O O O O O O O O O
-
-
-3.7 Summary of the operation attributes for the Job operations
-
-The following table shows the operation attributes for the Job
-operations that a client MAY supply in a request. Operation attributes
-that specify the Printer or Job object as the target are shown in the
-first two rows, respectively. Other operation attributes and parameters
-
-
-Kugler, Hastings, Lewis [Page 13]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-that a client MUST supply are not shown. Also "requesting-user-name" is
-not shown, though it is RECOMMENDED that a client supply it in every
-request.
-Legend:
- R - REQUIRED for a Printer to support
- O - OPTIONAL for a Printer to support; the Printer ignores the
-attribute if not supported
-
-Operation Can Canc Ho Re Spa Pau Re Get- Set- Rest Repr Pro
-Attribute cel el- ld le ce- se- su Job- Job- art- oces mot
- - Curr - as Cur Cur me Attr Attr Job s- e-
- Job ent- Jo e- ren ren - ibut ibut Job Job
- Job b Jo t- t- Jo es es
- b Job Job b
-
-printer-uri R R R
-
-printer- R R R R R R R R R
-uri/job-id
-or job-uri
-
-job-id R R R
-
-requested- R
-attributes
-
-back-space O
-
-forward- O
-space
-
-
-synchronize O O
-
-when O O
-
-job- O O O O O O O O O
-message-
-from-
-operator
-
-message O O O O O O O O
-[to-
-operator]
-
-job-hold- O* O* O**
-until
-
-device-name O O O O O O O O O O O O
-
-* The Printer MUST support the "job-hold-until" operation attribute
-if it supports the "job-hold-until" Job Template attribute.
-** The Printer MUST support the "job-hold-until" operation attribute if
-it supports the Set-Job-Attributes operation, so that the client can
-hold the job with the Reprocess-Job operation and the modify the job
-before releasing it to be processed.
-
-
-
-
-Kugler, Hastings, Lewis [Page 14]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-4. New Printer Description Attributes
-
-
-The following new Printer Description attributes are needed to support
-the new operations defined in this document.
-
-
-4.1 printer-settable-attributes (1setOf type2 keyword)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: printer-settable-attributes
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-1setOf type2 keyword
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): Yes
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? printer-settable-attributes (1setOf type2 keyword)
-
-This READ-ONLY Printer attribute identifies the Printer object
-attributes that are settable in this implementation, i.e., that are
-settable using the Set-Printer-Attributes operations. This attribute
-MUST be supported if the Set-Printer-Attributes operations is supported.
-The Printer MUST reject attempts to set any Printer attributes that are
-not in this list, returning the 'client-error-attributes-not-settable'
-status code (see section 6.1). The value of this attribute MAY depend
-on the value of the "document-format" operation attribute supplied in
-the Get-Printer-Attributes operation (see [ipp-mod] section 3.2.5.1).
-
-4.2 interpreter-settable-attributes (1setOf type2 keyword)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: interpreter-settable-
-attributes
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-1setOf type2 keyword
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): Yes
-
-Kugler, Hastings, Lewis [Page 15]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? interpreter-settable-attributes (1setOf type2 keyword)
-
-This READ-ONLY Printer attribute identifies the Interpreter object (see
-section 2.1) attributes that are settable in this implementation, i.e.,
-that are settable using the Set-Printer-Attributes operations. This
-attribute MUST be supported if the Set-Printer-Attributes operations is
-supported. The Printer MUST reject attempts to set any Printer or
-Interpreter attributes that are not in this list, returning the 'client-
-error-attributes-not-settable' status code (see section 6.1). The value
-of this attribute MAY depend on the value of the "document-format"
-operation attribute supplied in the Get-Printer-Attributes operation
-(see [ipp-mod] section 3.2.5.1).
-
-4.3 job-settable-attributes (1setOf type2 keyword)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: job-settable-attributes
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-1setOf type2 keyword
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): Yes
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? job-settable-attributes (1setOf type2 keyword)
-
-This READ-ONLY Printer attribute identifies the Job object attributes
-that are settable in this implementation, i.e., that are settable using
-the Set-Job-Attributes operations. This attribute MUST be supported if
-the Set-Job-Attributes operations is supported. The Printer MUST reject
-attempts to set any Job attributes that are not in this list, returning
-the 'client-error-attributes-not-settable' status code (see section
-6.1).
-
-
-4.4 printer-controls-other-protocols (boolean)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: printer-controls-other-
-protocols
-
-Kugler, Hastings, Lewis [Page 16]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-boolean
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: N/A
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): No
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? printer-controls-other-protocols (boolean)
-
-This Printer attribute indicates whether operations, such as Disable-
-Printer, Pause-Printer, etc., affect non-IPP protocols that may be
-supported. It is RECOMMENDED that IPP control other non-IPP protocols.
-However, this attribute permits an implementation to indicate explicitly
-whether it does affect other protocols or not.
-
-A 'false' value indicates that IPP operations only affect jobs submitted
-by the IPP Protocol. For example, a 'true' value indicates that a
-Disable-Printer operation prevents all protocols from submitting jobs,
-not just the IPP protocol. An another example, a 'true' value indicates
-that the Pause-Printer operation would pause the current job, no matter
-what job submission protocol had submitted it.
-
-ISSUE 6: Ok that the "printer-controls-other-protocols" Printer
-Description attribute is just a boolean, or do we need a list of
-operations that affect non-IPP protocols?
-
- TH> It would be more flexible to allow per-operation control, so
- change from "printer-controls-other-protocols" Printer Description
- attribute to "operations-affecting-other-protocols (1setOf type2
- enum). The values are defined by the "operations-supported (1setOf
- type2 enum)" operation.
-
- HRL> The situation is already complex in that SNMP or IPP (possibly
- others?) may "compete" or "conflict" is managing the printer. Per-
- operation control does nothing to alleviate this and may make the
- situation even more complex. Suggest leave as is.
-
-As with any Printer Description attribute that this specification does
-not list as READ-ONLY, an implementation MAY allow a client to change
-the value of this attribute using Set-Printer-Attributes, thereby
-changing the way that the IPP operations affect other non-IPP protocols.
-An implementation MAY also support other means to change the value of
-this attribute, such as via the console or at installation time.
-
-
-
-Kugler, Hastings, Lewis [Page 17]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-ISSUE 7: Is IPP intended for printer management. The issue is still
-undetermined?
- TH> I think it is natural and so far there is not much overlap with
- any MIB. If and when we do get overlap, we need to make sure that the
- semantics are the same.
-
- HRL> I think it is clear that IPP is moving in this direction. I leave
- this issue open for further discussion, however, because I believe we
- need to be as clear as possible about the possible conflicts of two
- management protocols originating form one organization (SNMP and IPP)
- and provide some guidelines.
-
-4.5 printer-message-time (integer(MIN:MAX))
-
-Type of registration: attribute
-Proposed keyword name of this attribute: printer-message-time
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-integer(MIN:MAX)
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: N/A
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): No
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? printer-message-time (integer(MIN:MAX))
-
-This READ-ONLY Printer Description attribute contains the time that the
-Printer's "printer-message-from-operator" was changed by the operator
-using any operation where the client supplied the "printer-message-from-
-operator" operation attribute (see section 3.1) or was explicitly set
-using the Set-Printer-Attributes operation (see section 7.1.1). This
-attribute allows the users to know when the "printer-message-from-
-operator" attribute was last set.
-
-The Printer sets the value of this attribute by copying the value of the
-Printer's "printer-up-time" attribute (see [ipp-mod] section 4.3.14).
-If the Printer resets its "printer-up-time" attribute to 1 on power-up,
-then it MUST change the value of the "printer-message-time" to 0 or a
-negative number as specified in [ipp-mod] section 4.3.14.
-
-Note: This attribute helps users better understand the context for the
-"printer-message-from-operator" message.
-
-
-
-
-Kugler, Hastings, Lewis [Page 18]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-4.6 printer-message-date-time (dateTime)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: printer-message-date-time
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-dateTime
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: N/A
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): No
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? printer-message-date-time (dateTime)
-
-This READ-ONLY Printer Description attribute contains the date and time
-that the Printer's "printer-message-from-operator" was changed by the
-operator using any operation where the client supplied the "printer-
-message-from-operator" operation attribute (see section 3.1) or was
-explicitly set using the Set-Printer-Attributes operation (see section
-7.1.1). This attribute allows the users to know when the "printer-
-message-from-operator" attribute was last set. This attribute MUST be
-supported if the Printer supports both the "printer-message-from-
-operator" and the "printer-current-date-time" attributes.
-
-Note: This attribute helps users better understand the context for the
-"printer-message-from-operator" message.
-
-
-4.7 printer-message-operation (type2 keyword)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: printer-message-operation
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-type2 enum
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): No
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-
-
-Kugler, Hastings, Lewis [Page 19]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? printer-message-operation (type2 enum)
-
-This READ-ONLY Printer Description attribute contains the operation that
-was used to changed the Printer's "printer-message-from-operator" by the
-operator using any operation where the client supplied the "printer-
-message-from-operator" operation attribute (see section 3.1) or
-explicitly set using the Set-Printer-Attributes operation (see section
-7.1.1). This attribute allows the users to know which operation was
-used to change the "printer-message-from-operator" attribute when it was
-last set.
-
-Note: This attribute helps users better understand the context for the
-"printer-message-from-operator" message.
-
-
-4.8 when-values-supported (1setOf type2 keyword)
-
-Type of registration: attribute
-Proposed keyword name of this attribute: when-values-supported
-Types of attribute (Operation, Job Template, Job Description, Printer
-Description): Printer Description
-Operations to be used with if the attribute is an operation attribute:
-N/A
-Object (Job, Printer, etc. if bound to an object): Printer
-Attribute syntax(es) (include 1setOf and range as in Section 4.2):
-1setOf type2 keyword
-If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
-If this is a Printer attribute, MAY the value returned depend on
-"document-format" (See Section 6.2): No
-If this is a Job Template attribute, how does its specification depend
-on the value of the "multiple-document-handling" attribute: N/A
-Specification of this attribute (follow the style of IPP Model Section
-4.2):
-
-4.4.? when-values-supported (1setOf type2 keyword)
-
-This READ-ONLY Printer Description attribute contains the supported
-values for the "when" operation attribute in any operation. The
-operations include: Pause-Printer, Reset-Printer, Shutdown-Printer, and
-Pause-Current-Job. For Pause-Current-Job, only the 'now' and 'after-
-current-copy' values are defined. So the other values: 'after-current-
-job' and 'after-all', if present in this attribute, don't apply to
-Pause-Current-Job).
-
-
-
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 20]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-4.9 device-names-supported (1setOf name(127))
-
-
-ISSUE 8 - For consistency with [ipp-mod], shouldn't this be singular
-even though it is multi-valued, i.e., device-name-supported (1setOf
-name(127))?
-
-This OPTIONAL Printer attribute contains at least one device name which
-is associated with this Printer object. It OPTIONALLY contains more
-than one device name which is associated with this Printer object, i.e.,
-fan-out, see [ipp-mod] section 2.1. A Printer object which does not
-have an associated named device MUST NOT support this attribute.
-
-An Administrator determines device names and configures this attribute
-to contain those device names via IPP Set-Printer-Attributes operation
-(see section 7.1.1) or by some means outside the scope of this document.
-The precise format of these device names is implementation dependent and
-MAY depend on the protocol stack and the directory namespace.
-
-Note: The new attribute "device-names-supported" will also enhance the
-usefulness of the IPP/1.1 Job object attribute "output-device-assigned"
-(see [ipp-mod] section 4.3.13). The "output-device-assigned" Job
-attribute identifies the output device to which the Printer object has
-assigned a job, for example, when a single Printer object is supporting
-multiple devices.
-
-See also the operation attribute "device-name" in section 3.5 of this
-document.
-
-
-
-5. Additional values for "printer-state-reasons" and "job-state-reasons"
-attributes
-
-The following values are added to the "printer-state-reasons" and "job-
-state-reasons" for use with the operations defined in this document.
-
-5.1 Value for "printer-state-reasons": 'standby'
-
-Type of registration: type2 keyword attribute value
-Name of attribute to which this keyword specification is to be added:
-printer-state-reasons
-Proposed keyword name of this keyword value: standby
-Specification of this keyword value (follow the style of IPP Model
-Section 4.1.2.3):
-
-
-
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 21]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- 'standby': The Printer has been shutdown in standby mode. Only
- Restart-Printer and Get-Printer-Attributes operations are accepted
- in this state; all other operations are rejected with the 'server-
- error-printer-is-in-standby-mode'.
-
-5.2 Value for "job-state-reasons": 'job-paused'
-
-Type of registration: type2 keyword attribute value
-Name of attribute to which this keyword specification is to be added:
-job-state-reasons
-Proposed keyword name of this keyword value: job-paused
-Specification of this keyword value (follow the style of IPP Model
-Section 4.1.2.3):
- 'job-paused': The job has been paused while processing using the
- Pause-Current-Job operations and other jobs can be processed on the
- Printer. The Job can be resumed using the Resume-Job operation
- which removes this value.
-
-
-
-6. New status codes
-
-This section defines new status codes used by the operations defined in
-this document.
-
-6.1 New status code: 'client-error-attributes-not-settable'
-
-Type of registration: status code
-Keyword symbolic name of this status code value: 'client-error-
-attributes-not-settable'
-Numeric value (to be assigned by the IPP Designated Expert in
-consultation with IANA):
-Operations that this status code may be used with: Set-Printer-
-Attributes, Set-Job-Attributes
-Specification of this status code (follow the style of IPP Model Section
-13 APPENDIX B: Status Codes and Suggested Status Code Messages):
-
-13.1.4.20 client-error-attributes-not-settable (0x0413)
-
-In a Set-Printer-Attributes or Set-Job-Attributes request, if the
-Printer object does not support one or more attributes as settable, the
-Printer object MUST return this status code. The Printer object MUST
-also return in the Unsupported Attributes Group all the attributes
-and/or values supplied by the client that are not settable. See [ipp-
-mod] section 3.1.7. For example, if the request indicates 'job-state',
-all implementations MUST reject the request. As another example, if the
-request indicates an attribute that is supported, but not settable by
-this implementation, such as, say, "printer-name", the implementation
-rejects the request.
-
-
-
-Kugler, Hastings, Lewis [Page 22]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-6.2 New status code: 'server-error-printer-is-in-standby-mode'
-
-Type of registration: status code
-Keyword symbolic name of this status code value: 'server-error-printer-
-is-in-standby-mode'
-Numeric value (to be assigned by the IPP Designated Expert in
-consultation with IANA):
-Operations that this status code may be used with: Shutdown-Printer
-Specification of this status code (follow the style of IPP Model Section
-13 APPENDIX B: Status Codes and Suggested Status Code Messages):
-
-13.1.5.8 server-error-printer-is-in-standby-mode
-
-The Printer has been shutdown and is only accepting the Restart-Printer
-(see section 7.1.5) and Get-Printer-Attributes operations. An operator
-can perform the Restart-Printer operation to allow the Printer to accept
-other operations.
-
-
-
-7. Summary of Set 2 operations and Operation-Id Assignments
-
-The Set 2 operations are summarized in the following table:
-
- Operation Name Operati Brief description
- on-Id
-
- Set-Printer- 0x?? Sets attribute values of the target
- Attributes Printer object
-
- Enable-Printer 0x?? Allows the target Printer to accept
- create job operations
-
- Disable-Printer 0x?? Prevents the target Printer from
- accepting create job operations
-
- Reset-Printer 0x?? Resets the target Printer to one of
- several indicated ways
-
- Restart-Printer 0x?? Restarts the target Printer from a
- standby shutdown mode
-
- Non-Process- 0x?? Moves the last printed sheet(s) to the
- Run-Out exit or stacker
-
- Shutdown- 0x?? Shuts down the target Printer in
- Printer several ways
-
- Set-Job- 0x?? Sets attribute values of the target Job
- Attributes object
-
- Reprocess-Job 0x?? Creates a copy of a completed target
- job with a new Job ID and processes it
-
- Cancel-Current- 0x?? Cancels the current job on the target
- Job Printer or the specified job if it is
- the current job
-
- Pause-Current- 0x?? Pauses the current processing job on
- Job the target Printer or the specified job
- if it is the current job, allowing
- other jobs to be processed instead
-
- Resume-Job 0x?? Resume the paused target job
-
-
-Kugler, Hastings, Lewis [Page 23]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-
- Operation Name Operati Brief description
- on-Id
-
- Promote-Job 0x?? Promote the pending target job to be
- next after the current job(s) complete
-
- Space-Current- 0x?? Skips or repeats the specified number
- Job of impressions for the current job on
- the target Printer or the specified job
- if it is the current job
-
-All of the operations in this registration proposal specification are
-OPTIONAL for an IPP object to support. Unless the specification of an
-OPTIONAL operation requires support of another OPTIONAL operation,
-conforming implementations may support any combination of these
-operations.
-
-
-7.1 Printer Operations
-
-
-All Printer operations are directed at Printer objects. A client MUST
-always supply the "printer-uri" operation attribute in order to identify
-the correct target of the operation. These descriptions assume all of
-the common semantics of IPP/1.1 Model and Semantics document [ipp-mod]
-section 3.1.
-
-
-7.1.1 Set-Printer-Attributes Operation
-
-Type of registration: operation
-Proposed name of this operation: Set-Printer-Attributes
-Object Target: Printer
-Specification of this operation:
-
-This OPTIONAL operation allows a client to set the values of the
-attributes of a Printer object. In the request, the client supplies
-the set of Printer attribute names and values that are to be set. In
-the response, the Printer object returns success or rejects the request
-with indications of which attribute or attributes could not be set.
-
-How the Printer object validates the client-supplied attributes in the
-Set-Printer-Attributes request is implementation-dependent, since there
-are no corresponding Printer attributes that specify the allowed values
-that may be set on the Printer object.
-
-The Printer MUST accept this operation in any state, i.e., for any of
-the values of the Printer object's "printer-state" attribute.
-
-
-7.1.1.1 Settable and READ-ONLY Printer Description attributes
-
-If the Printer supports the "printer-message-from-operator" Printer
-Description attribute (see [ipp-mod] section 4.4.25) and the client
-explicitly supplies a new value for the "printer-message-from-operator"
-in the request, then the Printer MUST set the "printer-message-from-
-
-
-Kugler, Hastings, Lewis [Page 24]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-operator" Printer attribute to this new value and MUST also set the
-"printer-message-time", "printer-message-date-time", and "printer-
-message-operation" attributes, if supported (see sections 4.5, 4.6, and
-4.7).
-
-If the Printer supports the Set-Printer-Attributes operation, then it
-SHOULD support setting of:
-
- all Job Template Default ("xxx-default") attributes
- all Job Template Supported ("xxx-supported") attributes
- all Job Template Ready ("xxx-ready") attributes
-
-that the implementation supports (see [ipp-mod] section 4.2 and
-extensions).
-
-The following Printer Description attributes (see [ipp-mod] section 4.4)
-MUST NOT be settable, i.e., they are READ-ONLY:
-
- printer-state
- printer-state-reasons
- printer-state-message
- printer-is-accepting-jobs - see Enable-Printer/Disable-Printer
- queued-job-count
- printer-message-time - see Set-Printer-Attributes when setting
- "printer-message-from-operator"
- printer-message-date-time - see Set-Printer-Attributes when setting
- "printer-message-from-operator"
- printer-message-operation - see Set-Printer-Attributes when setting
- "printer-message-from-operator"
- when-values-supported
- printer-up-time
- settable-attributes
-
-The remaining Printer Description attributes MAY be settable using the
-Set-Printer-Attributes operation, depending on implementation. If "xxx-
-supported" Printer Description attribute are settable, then they MUST
-affect the behavior of the implementation. If they are READ-ONLY then
-they reflect the implementation and cannot be changed using the Set-
-Printer-Attributes operation. Consider the following examples:
-
- For example, if the "operations-supported" Printer Description
- attribute (see [ipp-mod] section 4.4.15) is settable, then changing
- its value MUST affect the operations that the implementation
- accepts or rejects. Such an implementation will need to be able to
- reject values for operations that it contains no code support for.
-
- As another example, if the "ipp-versions-supported" Printer
- Description attribute (see [ipp-mod] section 4.4.14) is settable,
- then changing its value MUST affect the protocol versions that are
- accepted or rejected. Such an implementation will need to be able
- to reject values for operations that it contains no code support
- for.
-
-
-Kugler, Hastings, Lewis [Page 25]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-See the "factory-settings" operation attribute (see section 3.3) for a
-way to query the implementation supported values using the Get-Printer-
-Attributes operation. See the "reset-function" operation attribute of
-the Reset-Printer operation (see section 7.1.4) for a way to restore the
-values to the factory settings.
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-Most Printer attributes will require administrator privileges to set,
-such as "xxx-supported", while some will require operator privileges
-only, such as "media-ready" and "printer-message-from-operator". Which
-attributes require which privileges depends on implementation and MAY
-depend on site policy.
-
-
-7.1.1.2 Set-Printer-Attributes Request
-
-The following sets of attributes are part of the Set-Printer-Attributes
-Request:
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.1.
-
- Target:
- The "printer-uri" (uri) operation attribute which is the target for
- this operation as described in [ipp-mod] section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in [ipp-mod] section 8.3.
-
-
- "document-format" (mimeMediaType):
- The client SHOULD supply this attribute. The Printer object MUST
- support this attribute. This attribute is useful for a client to
- select the Interpreter object to which the attribute modification
- should be applied. Each Printer object is modeled to contain one
- or more Interpreter objects. Those Printer attributes whose values
- vary from Interpreter to Interpreter, are modeled as Interpreter
- objects, while those that do not are Printer object attributes.
- Thus the target of a Get-Printer-Attributes or Set-Printer-
- Attributes operation is either the Printer object or the
- Interpreter object identified by the "document-format" operation
- attribute supplied by the client. Except for Get-Printer-
- Attributes and Set-Printer-Attributes, there are no other
- operations with the Interpreter object as a target. See [ipp-mod]
- section 3.2.5.1 "Get-Printer-Attributes Request".
-
-
-Kugler, Hastings, Lewis [Page 26]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- If a client wants to set an attribute of all of the Interpreter
- objects to the same value, it can query the Printer's "document-
- format-supported" Printer Description attribute and perform
- separate Set-Printer-Attributes for each document format supported.
-
- ISSUE 9: Do we need a way to get and/or set the "xxx" attribute
- for all Interpreter objects in one Get-Printer-Attributes or Set-
- Printer-Attributes operation? Or is it sufficient for a client to
- provide the equivalent functionality by stepping through all the
- values of the "document-formats-supported" with repeating the Get
- or Set operation?
-
- ISSUE 10: Ok to add the Interpreter object, even though it doesn't
- solve all of the attribute constraint problems. At least it gives
- us a more object-based description of the semantics. When we do
- add some sort of Printer Description attribute that enumerates
- combinations of Job attribute values that may not be used in
- combination (like PPD file constraints), it can include the
- "document-format" attribute among them. So introducing the
- Interpreter object in no way precludes a complete constraint
- description mechanism in the future.
-
- If the Printer object does not distinguish between different sets
- of supported values for each different document format when
- validating jobs in the create and Validate-Job operations, it MUST
- NOT distinguish between different document formats in the Set-
- Printer-Attributes operation. If the Printer object does
- distinguish between different sets of supported values for each
- different document format specified by the client, this
- specialization applies only to the same Printer attributes as the
- Get-Printer-Attributes operation (see [ipp-mod] section 3.2.5.1).
-
- If the client omits this "document-format" operation attribute, the
- Printer object MUST respond as if the attribute had been supplied
- with the value of the Printer object's "document-format-default"
- attribute. It is recommended that the client always supply a value
- for "document-format", since the Printer object's "document-format-
- default" may be 'application/octet-stream', in which case the set
- attributes and values are for the union of the document formats
- that the Printer can automatically sense. For more details, see
- the description of the 'mimeMediaType' attribute syntax in [ipp-
- mod] section 4.1.9.
-
- If the client supplies a value for the "document-format" Operation
- attribute that is not supported by the Printer, i.e., is not among
- the values of the Printer object's "document-format-supported"
- attribute, the Printer object MUST reject the operation and return
- the 'client-error-document-format-not-supported' status code.
-
-
-Group 2: Printer Attributes
-
-
-Kugler, Hastings, Lewis [Page 27]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- The client MUST supply a set of Printer attributes as defined in
- [ipp-mod] section 4.2 Job Template Attributes ("xxx-default", "xxx-
- supported", and "xxx-ready" attributes) and section 4.4 Printer
- Description Attributes. Each Printer attribute supplied in Group 2
- replaces the value(s) of the corresponding Printer attribute on the
- target Printer object. If a Printer object attribute had not been
- configured yet and so had the 'no-value' out-of-band value (see
- [ipp-mod] 4.1), the supplied value(s) replace the 'no-value' value.
- For attributes that can have multiple values (1setOf), all values
- supplied by the client replace all values of the corresponding
- Printer object attribute.
-
-
-7.1.1.3 Set-Printer-Attributes Response
-
-The Printer object returns the following sets of attributes as part of
-the Get-Printer-Attributes Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in [ipp-mod] sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See [ipp-mod] section 3.1.7 for details on returning Unsupported
- Attributes.
-
- In the case of attributes that are supported, but are not settable
- by the implementation, i.e., are not among the values of the
- Printer's "settable-attributes" Printer Description attribute (see
- section 4.1), the Printer object returns the client-supplied
- attribute(s) with a substituted value of 'not-supported' (same out-
- of-band value as for attributes that are not supported). This
- value's syntax type is "out-of-band" and its encoding is defined by
- special rules for "out-of-band" values in the "Encoding and
- Transport" document [IPP-PRO]. Its value indicates that the
- attribute is either not settable or is not supported at all.
-
- ISSUE 11: Why not have a separate out-of-band 'not-settable'
- value, so that the client can distinguish between the cases of the
- attribute isn't supported versus the attribute is supported, but is
- not settable? True, the client can query the "settable-attributes"
-
-
-
-Kugler, Hastings, Lewis [Page 28]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- to see which attributes can be set, before or after issuing the
- Set-Printer-Attributes operation.
- TH> I think that providing a separate out-of-band code is useful,
- since a reply could contain both unsupported attributes and ones that
- were supported, but are not settable in this implementation.
-
-
- HRL> What's wrong with what's already described? How is the new
- proposal better?
-
-7.1.2 Disable-Printer Operation
-
-Type of registration: operation
-Proposed name of this operation: Disable-Printer
-Object Target: Printer
-Specification of this operation:
-
-This OPTIONAL operation allows a client to stop the Printer object from
-accepting jobs, i.e., cause the Printer to reject subsequent create job
-operations (Print-Job, Print-URI, and Create-Job operation) and return
-the 'server-error-not-accepting-jobs' status code. The Printer still
-accepts all other operations. All previously submitted Jobs and
-currently processing Jobs continue unaffected. The Printer sets the
-value of its "printer-is-accepting-jobs" READ-ONLY Printer Description
-attribute to 'false' (see [ipp-mod] section 4.4.20), no matter what the
-previous value was. This operation has no immediate effect on the
-Printer's "printer-state" and "printer-state-reasons" attributes.
-
-Note: Use the Enable-Printer operation (section 7.1.3) to enable a
-Printer to accept Jobs again.
-
-If the Disable-Printer operation is supported, then the Enable-Printer
-operation MUST be supported, and vice-versa.
-
-Note: Use the Enable-Printer and Disable-Printer operations to allow or
-prevent input to a Printer. Use the Pause-Printer and Resume-Printer
-operations to prevent or allow output from the Printer.
-
-Whether or not the Disable-Printer operation stops jobs that are
-submitted using job submission protocols other than IPP, depends on
-implementation, i.e., on whether the IPP protocol is being used as a
-universal management protocol or just to manage IPP jobs, respectively.
-See "printer-controls-other-protocols" (section 4.4).
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Disable-Printer Request and Disable-Printer Response have the same
-attribute groups and attributes as the Resume-Printer operation (see
-[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
-message-from-operator" operation attribute (see section 3.1), and with
-
-
-Kugler, Hastings, Lewis [Page 29]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-the addition of the following Group 1 operation attribute in the
-request:
-
- "job-type" (type2 keyword):
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. The value of this attribute
- indicates the type of job to be disabled. If the client omits this
- attribute, the Printer assumes the 'network-jobs' value.
-
- Standard keyword values are:
- 'network-jobs' - disable jobs submitted using the create job
- operations.
- 'walk-up-jobs' - disable jobs submitted locally, such as
- walkup copy jobs
- 'all-jobs' - disable all type of jobs
-
-7.1.3 Enable-Printer Operation
-
-Type of registration: operation
-Proposed name of this operation: Enable-Printer
-Object Target: Printer
-Specification of this operation:
-
-This OPTIONAL operation allows a client to start the Printer object
-accepting jobs, i.e., cause the Printer to accept subsequent create job
-operations (Print-Job, Print-URI, and Create-Job operation). The
-Printer still accepts all other operations. All previously submitted
-Jobs and currently processing Jobs continue unaffected. The Printer
-sets the value of its "printer-is-accepting-jobs" READ-ONLY Printer
-Description attribute to 'true' (see [ipp-mod] section 4.4.20), no
-matter what the previous value was. This operation has no immediate
-effect on the Printer's "printer-state" and "printer-state-reasons"
-attributes.
-
-Note: Use the Disable-Printer operation (section 7.1.2) to stop a
-Printer from accepting Jobs.
-
-If the Enable-Printer operation is supported, then the Disable-Printer
-operation MUST be supported, and vice-versa.
-
-Note: Use the Enable-Printer and Disable-Printer operations to allow or
-prevent input to a Printer. Use the Pause-Printer and Resume-Printer
-operations to prevent or allow output from the Printer.
-
-Whether or not the Enable-Printer operation allows acceptance of jobs
-that are submitted using job submission protocols other than IPP,
-depends on implementation, i.e., on whether the IPP protocol is being
-used as a universal management protocol or just to manage IPP jobs,
-respectively. See "printer-controls-other-protocols" (section 4.4).
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-
-Kugler, Hastings, Lewis [Page 30]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-The Enable-Printer Request and Enable-Printer Response have the same
-attribute groups and attributes as the Resume-Printer operation (see
-[ipp-mod] sections 3.2.8.1 and 3.2.8.2), including the new "printer-
-message-from-operator" operation attribute (see section 3.1), and with
-the addition of the following Group 1 operation attribute in the
-request:
-
- "job-type" (type2 keyword):
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. The value of this attribute
- indicates the type of job to be enabled. If the client omits this
- attribute, the Printer assumes the 'network-jobs' value.
-
- Standard keyword values are:
- 'network-jobs' - enable jobs submitted using the create job
- operations.
- 'walk-up-jobs' - enable jobs submitted locally, such as walkup
- copy jobs
- 'all-jobs' - enable all types of jobs
-
-7.1.4 Reset-Printer operation
-
-Type of registration: operation
-Proposed name of this operation: Reset-Printer
-Object Target: Printer
-Specification of this operation:
-
-This OPTIONAL operation allows a client to reset the Printer in a number
-of ways, depending on the "reset-function" operation attribute. The
-keyword values of this attribute map one-to-one to the enum values that
-the NMS writes into the prtGeneralReset object in the Printer MIB
-[RFC1759] to affect a reset operation. As in the Printer MIB, the
-'reset-to-nvram' (soft reset) value MUST be supported, if this operation
-is supported. The other values are OPTIONAL.
-
-As is says in the Printer MIB specification, if a device does not have
-NVRAM (non-volatile RAM), the device MUST none-the-less respond to this
-operation for the 'reset-to-nvram' value with some sort of warm reset
-that resets the device to some implementation-defined state that is
-preferably under control of the system administrator by some means
-outside the scope of the Printer MIB and this document.
-
-The effect of this operation on the currently processing job(s), if any,
-is not specified by this document. Note: If this operation does affect
-the current job(s), it is expected that the operator would issue this
-operation on a Printer in the 'idle' state after disabling the Printer
-with the Disable operation in order to prevent a job from inadvertently
-being affected by this operation.
-
-The Printer object MUST accept this operation in any state and
-transition the Printer object to the 'idle' state.
-
-
-
-Kugler, Hastings, Lewis [Page 31]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Reset-Printer Request and Reset-Printer Response have the same
-attribute groups and attributes as the Pause-Printer operation (see
-[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
-message-from-operator" operation attribute (see section 3.1), the new
-"when" operation attribute (see section 3.4), and with the addition of
-the following Group 1 operation attributes in the request:
-
- "reset-function" (type3 keyword):
- The client OPTIONALLY supplies this attribute. The Printer object
- MUST support this attribute, if it supports this operation. The
- value of this attribute indicates the reset function to be
- performed. If the client omits this attribute, the Printer assumes
- the 'reset-to-nvram' value.
-
- Standard keyword values are:
- 'power-cycle-reset' - Cold start, i.e., to the state when the
- device is powered up.
- 'reset-to-nvram' - Warm start.
- 'reset-to-factory-defaults' - reset NVRAM to factory defaults,
- i.e. to factory settings and/or values established at
- install time.
-
-
-7.1.5 Restart-Printer operation
-
-Type of registration: operation
-Proposed name of this operation: Restart-Printer
-Object Target: Printer
-Specification of this operation:
-
-This OPTIONAL operation allows a client to restart a Printer that has
-previously been shutdown in standby mode (see section 7.1.7). Standby
-mode is indicated by the Printer's "printer-state" being 'stopped' and
-its "printer-state-reasons" including the 'standby' and 'paused' values.
-If the Printer is not in standby mode, the Printer MUST reject this
-operation and return the 'client-error-not-possible' status code.
-
-ISSUE 12: What state does the Printer comes back up on Restart-Printer
-and how can the client control?
-Possible alternatives:
-
- a. Restart-Printer always brings the Printer up Disabled ("printer-
- is-accepting-jobs" = 'false') and Paused ("printer-state" =
- 'stopped', and "printer-state-reasons" = 'paused') which is the
- state that Shutdown-Printer leaves the Printer in. Then the
- operator issues Enable-Printer and Resume-Printer when want to
- restore normal operation. The client can automatically issues
- these addition 2 operations depending on GUI options. Advantages:
- This is the simplest to implement, allows new states to be added
-
-
-Kugler, Hastings, Lewis [Page 32]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- without changing the Restart-Printer operation, and can have the
- same GUI interface as b:
-
- b. Add a REQUIRED operation attribute to Restart-Printer, something
- like "printer-condition" with values: 'disabled-and-paused',
- 'enabled-and-paused', and 'enabled-and-idle'.
-
- TH 7/26: Remove the Shutdown-Printer 'standby' mode concept.
- Shutdown-Printer always powers off eventually. Also remove
- Restart-Printer operation all together. Instead change the
- Disable-Printer and Enable-Printer operations to Disable-Operations
- and Enable-Operations, so that individual operations are enabled
- and disabled independent of the state of the Printer and don't
- otherwise affect the state of the Printer.
-
- HRL 9/18: How can the state of the printer not be effected when you
- disable or enable it? Don't understand 2nd half of this issue
- resolution.
-
-
-
-If the Restart-Printer operation is supported, then the Shutdown-Printer
-operation MUST be supported, since the Restart-Printer operation is
-meaningful only after a Shutdown-Printer operation has been performed.
-However, if the Shutdown-Printer operation is supported, the Restart-
-Printer NEED NOT be supported.
-
- Issue 13: Why? This is backward, if you ask me (HRL).
-
-
-
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Restart-Printer Request and Restart-Printer Response have the same
-attribute groups and attributes as the Resume-Printer operation (see
-[ipp-mod] sections 3.2.8.1 and 3.2.8.2), including the new "printer-
-message-from-operator" operation attribute (see section 3.1) and the
-following Group 1 operation attribute:
-
-
-
-
-7.1.6 Non-Process-Run-Out Operation
-
-ISSUE 14 - Can we think of a name for Non-Process-Run-Out that follows
-the pattern of other IPP operations on Printers, namely Xxxx-Yxxx-
-Printer? How about Non-Process-Run-Out-Printer or more simply Run-Out-
-Printer?
-
-Type of registration: operation
-Proposed name of this operation: Non-Process-Run-Out
-Object Target: Printer
-
-Kugler, Hastings, Lewis [Page 33]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Specification of this operation:
-
-This OPTIONAL operation effectively moves the last printed sheet to the
-exit or stacker. The terminology is common to long path continuous forms
-devices but may have applicability on shorter devices or in cut-sheet
-applications.
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Non-Process-Run-Out Request and Non-Process-Run-Out Response have
-the same attribute groups and attributes as the Pause-Printer operation
-(see [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new
-"printer-message-from-operator" operation attribute (see section 3.1)
-and the new "when" operation attribute (see section 3.4).
-
-
-7.1.7 Shutdown-Printer Operation
-
-Type of registration: operation
-Proposed name of this operation: Shutdown-Printer
-Object Target: Printer
-Specification of this operation:
-
-This OPTIONAL operation allows a client to shutdown a Printer, i.e.,
-stop processing jobs and power off in some implementation-dependent
-manner. The purpose of Shutdown-Printer is to shutdown the Printer for
-an extended period, not to reset the device(s) or modify a Printer
-attribute. See Reset-Printer (section 7.1.4) for the way to reset the
-device(s). See the Disable-Printer operation (section 7.1.2) for a way
-for the client to stop the Printer from accepting Job Creation requests
-without stopping processing or shutting down.
-
-The Printer is disabled immediately (see the Disable-Printer operation
-in section 7.1.2). The Printer adds the 'shutdown' value (see [ipp-mod]
-section 4.4.11) to its "printer-state-reasons" Printer Description
-attribute. The "when" operation attribute specifies how much processing
-occurs before the Printer is paused (see [ipp-mod] section 3.2.7) and
-the shutdown is complete. All other requests continue to be accepted
-until the printer is powered down.
-
-ISSUE 15 - Need to look at life cycle of the Printer versus
-standby/power-down and the other operations that can be accepted. There
-can be appreciable time between acceptance of this operation and when
-the final state of the printer, either standby or powered down is
-reached. Is it ok for non-submission operations to continue to be
-accepted during this time? May need 'moving-to-shutdown'. What about
-'moving-to-standby'?
-
- TH> Add 'moving-to-shutdown' which the Shutdown-Printer sets
- immediately (analogous to 'moving-to-paused'). Then the 'shutdown'
- values means that the shutdown has completed (and is only meaningful
- to a server implementation that hosts the Printer object). Thus the
-
-
-Kugler, Hastings, Lewis [Page 34]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- server can still respond to a Get-Printer-Attributes operation after
- the Printer is shutdown as stated in IPP/1.1.
-
- HRL> Is this granularity really achievable enough of a wide enough
- variety of environments to be reliable or, in reality, will this be
- implementation dependent?
-
-Whether or not the Shutdown-Printer operation affects jobs that were
-submitted to the device using job submission protocols other than IPP,
-depends on implementation, i.e., on whether the IPP protocol is being
-used as a universal management protocol or just to manage IPP jobs,
-respectively. See "printer-controls-other-protocols" (section 4.4).
-
-The Printer object MUST accept this operation in any state and
-transition the Printer object to the 'idle' state.
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Shutdown-Printer Request and Shutdown-Printer Response have the same
-attribute groups and attributes as the Pause-Printer operation (see
-[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
-message-from-operator" operation attribute (see section 3.1), the new
-"when" operation attribute (see section 3.4), and with the addition of
-the following Group 1 operation attributes in the request:
-
- "shutdown-function" (type2 keyword)
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. This attribute indicates which
- shutdown function is to be performed.
-
- Standard keyword values are:
- 'standby' - shutdown the Printer, but leave it in standby-mode
- (disabled and paused), which means that Get-Printer-
- Attributes and Restart-Printer operations are accepted.
- 'power-off' - shutdown the Printer and power it off. No
- operations are accepted after power off.
-
- "synchronize" (boolean)
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. This attribute indicates
- whether or not the printer is to synchronize the checkpoint data
- for the current job ("when" = 'now') with the pages that have
- actually printed. If the value of the "when" attribute is not
- 'now' or the "when" attribute is not supplied, then the
- "synchronize" attribute has no meaning and the Printer MUST ignore
- it. If this attribute is supported, then a value of 'true' implies
- that the Printer will be able to resume the job at the point of
- synchronization when the Printer is restarted. If the
- implementation does not support resuming a job (either
- automatically or with the Resume-Job operation) after a Shutdown-
- Printer with "when" = 'now', then it does not implement this
-
-Kugler, Hastings, Lewis [Page 35]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- attribute. In this case, check-pointing implies that the job may
- be resumed in the future, exactly from the point and in the state
- and resource context from which it left off.
-
-
- If the Printer supports this attribute but the client does not
- supply it, the Printer is assumed to perform synchronization
- ('true' behavior). If the Printer does not support this attribute,
- the Printer is assumed to not synchronize ('false' behavior).
-
-
- ISSUE 16: Is the current job automatically restarted when the
- Printer is restarted? Or does some client have to issue a Restart-
- Job operation?
- The question is moot, if we remove the Restart-Job operation, as
- suggested:
-
- TH 7/26: Remove the Shutdown-Printer 'standby' mode concept.
- Shutdown-Printer always powers off eventually. Also remove
- Restart-Printer operation all together. Instead change the
- Disable-Printer and Enable-Printer operations to Disable-Operations
- and Enable-Operations, so that individual operations are enabled and
- disabled independent of the state of the Printer and don't otherwise
- affect the state of the Printer.
- HRL> Then, how do we restart the printer?
-
-
-7.2 Job Operations
-
-
-All Job operations are directed at Job objects. A client MUST always
-supply some means of identifying the Job object in order to identify the
-correct target of the operation. That job identification MAY either be
-a single Job URI or a combination of a Printer URI with a Job ID. The
-IPP object implementation MUST support both forms of identification for
-every job.
-
-
-7.2.1 Set-Job-Attributes
-
-Type of registration: operation
-Proposed name of this operation: Set-Job-Attributes
-Object Target: Job
-Specification of this operation:
-
-This OPTIONAL operation allows a client to set the values of the
-attributes of a Job object. In the request, the client supplies the
-set of Job attribute names and values that are to be set. In the
-response, the IPP object returns success or rejects the request with
-indications of which attribute or attributes could not be set.
-
-This operation is almost identical to the Set-Printer-Attributes
-operation (see section 7.1.1). The only differences are that the Set-
-
-Kugler, Hastings, Lewis [Page 36]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Job-Attributes operation is directed at a Job object rather than a
-Printer object, there is no "document-format" operation attribute used
-when setting a Job object, and the validation is the same as the create
-job operations, i.e., depends on the "xxx-supported" Printer Description
-attributes.
-
-The validation of the Set-Job-Attributes request is performed as if the
-job had been submitted originally with the new values and with "ipp-
-attribute-fidelity" set to 'true', i.e., all modified attributes MUST be
-supported along with the attributes not modified. If such a create job
-operation would have been accepted, then the Set-Job-Attributes MUST be
-accepted. If such a create job operation would have been rejected, then
-the Set-Job-Attributes MUST be rejected and the Job MUST be unchanged.
-
-The IPP object MUST accept or reject the request based on the job's
-current state and transition the job to the indicated new state as
-follows:
-
- Current "job- New "job- IPP object's response status
- state" state" code and action:
-
- 'pending' 'pending' 'successful-ok'
- 'pending' 'pending- 'successful-ok' - needed
- held' resources are not ready
- 'pending-held' 'pending- 'successful-ok'
- held'
- 'pending-held' 'pending' 'successful-ok' - needed
- resources are ready
- 'processing' 'processing' 'successful-ok' or 'client-
- error-not-possible' depending on
- the attributes being set,
- whether the job has started
- marking media, and/or
- implementation
- 'processing- 'processing- 'successful-ok' or 'client-
- stopped' stopped' error-not-possible' depending on
- the attributes being set,
- whether the job has started
- marking media, and/or
- implementation
- 'completed' 'completed' 'client-error-not-possible'
- 'canceled' 'canceled' 'client-error-not-possible'
- 'aborted' 'aborted' 'client-error-not-possible'
-
-7.2.1.1 Settable and READ-ONLY Job Description attributes
-
-If the Printer supports the "job-message-from-operator" Job Description
-attribute (see [ipp-mod] section 4.3.16) and the client explicitly
-supplies a new value for the "job-message-from-operator" in the request,
-then the Printer MUST set the "job-message-from-operator" Job attribute
-to this new value.
-
-
-Kugler, Hastings, Lewis [Page 37]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-If the Printer supports the Set-Job-Attributes operation, then it SHOULD
-support setting of:
-
- all Job Template ("xxx") attributes (see [ipp-mod] section 4.2 and
- extensions)
-
-that the implementation supports.
-
-The following Job Description attributes (see [ipp-mod] section 4.3)
-MUST NOT be settable, i.e., they are READ-ONLY:
-
- job-uri
- job-id
- job-printer-uri
- job-more-info
- job-originating-user-name - set in create operation
- job-state
- job-state-reasons
- job-state-message
- number-of-documents
- output-device-assigned
- time-at-creation
- time-at-processing
- time-at-completed
- job-printer-up-time
- date-time-at-creation
- date-time-at-processing
- date-time-at-completed
- number-of-intervening-jobs
- job-k-octets
- job-k-octets-processed
- job-impressions-completed
- job-media-sheets-completed
- attributes-charset - set in create operation
- attributes-natural-language - set in create operation
-
-The remaining Job Description attributes MAY be settable using the Set-
-Job-Attributes operation, depending on implementation.
-
-Whether or not the Set-Job-Attributes operation affects jobs that are
-submitted using job submission protocols other than IPP, depends on
-implementation, i.e., on whether the IPP protocol is being used as a
-universal management protocol or just to manage IPP jobs, respectively.
-See "printer-controls-other-protocols" (section 4.4).
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-
-7.2.1.2 Set-Job-Attributes Request
-
-The following sets of attributes are part of the Set-Job-Attributes
-Request:
-
-
-Kugler, Hastings, Lewis [Page 38]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Group 1: Operation Attributes
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.1.
-
- Target:
- Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))
- or (2) the "job-uri" (uri) operation attribute(s) which define the
- target for this operation as described in [ipp-mod] section 3.1.5.
-
- Requesting User Name:
- The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
- by the client as described in [ipp-mod] section 8.3.
-
-
-
-Group 2: Job Attributes
-
- The client MUST supply a set of Job attributes as defined in [ipp-
- mod] section 4.2 Job Template Attributes ("xxx" attributes) and
- section 4.3 Job Description Attributes. Each Job attribute
- supplied in Group 2 replaces the value(s) of the corresponding Job
- attribute on the target Job object. For attributes that can have
- multiple values (1setOf), all values supplied by the client replace
- all values of the corresponding Job object attribute.
-
-
-7.2.1.3 Set-Job-Attributes Response
-
-The Printer object returns the following sets of attributes as part of
-the Set-Job-Attributes Response:
-
-Group 1: Operation Attributes
-
- Status Message:
- In addition to the REQUIRED status code returned in every response,
- the response OPTIONALLY includes a "status-message" (text(255))
- and/or a "detailed-status-message" (text(MAX)) operation attribute
- as described in [ipp-mod] sections 13 and 3.1.6.
-
- Natural Language and Character Set:
- The "attributes-charset" and "attributes-natural-language"
- attributes as described in [ipp-mod] section 3.1.4.2.
-
-
-Group 2: Unsupported Attributes
-
- See [ipp-mod] section 3.1.7 for details on returning Unsupported
- Attributes.
-
- The attributes returned are the same as for the create operation
- with the same new attribute values. In the case of attributes that
- are supported, but are not settable by the implementation, i.e.,
-
-Kugler, Hastings, Lewis [Page 39]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- are not among the values of the Printer's "settable-attributes"
- Printer Description attribute (see section 4.1), the Printer object
- returns the client-supplied attribute(s) with a substituted value
- of 'not-supported' (same out-of-band value as for attributes that
- are not supported). This value's syntax type is "out-of-band" and
- its encoding is defined by special rules for "out-of-band" values
- in the "Encoding and Transport" document [IPP-PRO]. Its value
- indicates that the attribute is either not settable or is not
- supported at all.
-
-
-7.2.2 Reprocess-Job Operation
-
-This OPTIONAL operation is a create job operation that allows a client
-to re-process a copy of a job that had been retained in the queue after
-processing completed, was canceled, or was aborted (see [ipp-mod]
-section 4.3.7.2). This operation is the same as the Restart-Job
-operation (see [ipp-mod] section 3.3.7), except that the Printer creates
-a new job that is a copy of the target job and the target job is
-unchanged. The new job is assigned new values to the "job-uri" and
-"job-id" attributes and the new job's Job Description attributes that
-accumulate job progress, such as "job-impressions-completed", "job-
-media-sheets-completed", and "job-k-octets-processed", are initialized
-to 0 as with any create job operation. The target job moves to the Job
-History after a suitable period, independent of whether one or more
-Reprocess-Job operations have been performed on it.
-
-If the Set-Job-Attributes operation is supported, then the "job-hold-
-until" operation attribute MUST be supported with at least the
-'indefinite' value, so that a client can modify the new job before it is
-scheduled for processing using the Set-Job-Attributes operation. After
-modifying the job, the client can release the job for processing, by
-using the Release-Job operation specifying the newly assigned "job-uri"
-or "job-id" for the new job.
-
-
-7.2.3 Cancel-Current-Job Operation
-
-This OPTIONAL operation allows a client to cancel the current job on the
-target Printer or the specified job if it is the current job on the
-Printer. See [ipp-mod] section 3.3.3 for the semantics of canceling a
-job. Since a Job might already be marking by the time a Cancel-Current-
-Job is received, some media sheet pages might be printed before the job
-is actually terminated.
-
-If the client does not supply a "job-id" operation attribute, the
-Printer MUST accept the request and cancel the current job if there is a
-current job in the 'processing' or 'processing-stopped' state;
-otherwise, it MUST reject the request and return the 'client-error-not-
-possible' status code. If more than one job is in the 'processing' or
-
-
-
-Kugler, Hastings, Lewis [Page 40]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-'processing-stopped' states, the one that is marking is canceled and the
-others are unaffected.
-
-Warning: On a shared printer, there is a race condition. Between the
-time that a user issues this operation and its acceptance, the current
-job might change to a different job. If the user or operator is
-authenticated to cancel the new job, the wrong job is canceled. To
-prevent this race from canceling the wrong job, the client MAY supply
-the "job-id" operation attribute which is checked against the current
-job's job-id. If the job identified by the "job-id" attribute is not
-the current job on the Printer, i.e., is not in the 'processing' or
-'processing-stopped' states, the Printer MUST reject this operation and
-return the 'client-error-not-possible' status code. Otherwise, the
-Printer cancels the specified job.
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Cancel-Current-Job Request and Cancel-Current-Job Response have the
-same attribute groups and attributes as the Resume-Printer operation
-(see [ipp-mod] section 3.2.8), including the new "job-message-from-
-operator" operation attribute (see section 3.2), with the addition of
-the following Group 1 Operation attributes in the request:
-
- "job-id" (integer(1:MAX)):
-
- The client OPTIONALLY supplies this Operation attribute in order to
- verify that the identified job is still the current job on the
- target Printer object. The IPP object MUST supports this operation
- attribute, if it supports this operation.
-
-
-
-
-7.2.4 Pause-Current-Job operation
-
-This OPTIONAL operation allows a client to stop the current job on the
-target Printer or the specified job if it is the current job on the
-Printer, and allow other jobs to be processed instead. The Printer
-moves the current job or the target job to the 'processing-stopped'
-state and sets the 'job-paused' value in the job's "job-state-reasons"
-attribute and processes other jobs.
-
-If the client does not supply a "job-id" operation attribute, the
-Printer MUST accept the request and pause the current job if there is a
-current job in the 'processing' or 'processing-stopped' state;
-otherwise, it MUST reject the request and return the 'client-error-not-
-possible' status code. If more than one job is in the 'processing' or
-'processing-stopped' states, all of them are paused.
-
-Warning: On a shared printer, there is a race condition. Between the
-time that a user issues this operation and its acceptance, the current
-
-
-Kugler, Hastings, Lewis [Page 41]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-job might change to a different job. If the user or operator is
-authenticated to pause the new job, the wrong job is paused. To prevent
-this race from pausing the wrong job, the client MAY supply the "job-id"
-operation attribute which is checked against the current job's job-id.
-If the job identified by the "job-id" attribute is not the current job
-on the Printer, i.e., is not in the 'processing' or 'processing-stopped'
-states, the Printer MUST reject this operation and return the 'client-
-error-not-possible' status code. Otherwise, the Printer pauses the
-specified job and processed other jobs.
-
-A paused job is resumed using the Resume-Job operation (see section
-7.2.5). If the Pause-Current-Job operation is supported, then the
-Resume-Job operation MUST be supported, and vice-versa.
-
-The Printer MUST reject a Release-Job request (and return the 'client-
-error-not-possible') for a job that has been paused , i.e., for a job in
-the 'processing-stopped' state, with the 'job-paused' value in its "job-
-state-reasons" attribute. The Hold-Job and Release-Job operations are
-for holding and releasing held jobs, not pausing and resuming paused
-jobs.
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Pause-Current-Job Request and Pause-Current-Job Response have the
-same attribute groups and attributes as the Resume-Printer operation
-(see [ipp-mod] section 3.2.8 ), including the new "job-message-from-
-operator" operation attribute (see section 3.2), the new "when"
-operation attribute (see section 3.4), with the addition of the
-following Group 1 Operation attributes in the request:
-
- "job-id" (integer(1:MAX)):
-
- The client OPTIONALLY supplies this Operation attribute in order to
- verify that the identified job is still the current job on the
- target Printer object. The IPP object MUST supports this operation
- attribute, if it supports this operation.
-
-
-
- "synchronize" (boolean)
- The client OPTIONALLY supplies this attribute. The Printer object
- OPTIONALLY supports this attribute. This attribute indicates
- whether or not the printer is to synchronize the checkpoint data
- for the current job being paused with the pages that have actually
- printed. If this attribute is supported, then a value of 'true'
- implies that the Printer will be able to resume the job at the
- point of synchronization when the job is resumed.
-
- If the Printer supports this attribute but the client does not
- supply it, the Printer is assumed to perform synchronization
-
-
-
-Kugler, Hastings, Lewis [Page 42]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- ('true' behavior). If the Printer does not support this attribute,
- the Printer is assumed to not synchronize ('false' behavior).
-
-
-7.2.5 Resume-Job operation
-
-This OPTIONAL operation allows a client to stop the target job and allow
-other jobs to be processed instead. The Printer moves the target job to
-the 'pending' state and removes the 'job-paused' value from the job's
-"job-state-reasons" attribute.
-
-If the target job is not in the 'processing-stopped' state with the
-'job-paused' value in the job's "job-state-reasons" attribute, the
-Printer rejects the request and returns the 'client-error-not-possible'
-status code, since the job was not paused.
-
-If the Resume-Job operation is supported, then the Pause-Current-Job
-operation MUST be supported, and vice-versa.
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Resume-Job Request and Resume-Job Response have the same attribute
-groups and attributes as the Release-Job operation (see [ipp-mod]
-section 3.3.6), including the new "job-message-from-operator" operation
-attribute (see section 3.2).
-
-
-7.2.6 Promote-Job operation
-
-This OPTIONAL operation allows a client to make the pending target job
-be processed next after the current job completes. This operation is
-specially useful in a production printing environment where the operator
-is involved in job scheduling.
-
-If the target job is in the 'pending' state, this operation does not
-change the job's state, but causes the job to be processed after the
-current job(s) complete. If the target job is not in the 'pending'
-state, the Printer rejects the request and returns the 'client-error-
-not-possible' status code. The Printer returns the target job
-immediately after the current job(s) in a Get-Jobs response (see [ipp-
-mod] section 3.2.6) for the 'not-completed' jobs.
-
-When the current job completes, is canceled, paused, or aborted, the
-target of this operation is processed next.
-
-If a client issues this request (again) before the target of the
-operation of the original request started processing, the target of this
-new request is scheduled before the previous job that was to be
-processed next.
-
-
-
-Kugler, Hastings, Lewis [Page 43]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Note: IPP is specified not to require queues for job scheduling, since
-there are other implementations for scheduling multiple jobs. However,
-if an implementation does implement queues for jobs, then the Promote-
-Job puts the specified job at the front of the queue. A subsequent
-Promote-Job before the first job starts processing puts that specified
-job at the front of the queue, so that it is "in front" of the
-previously promoted job.
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Promote-Job Request and Promote-Job Response have the same attribute
-groups and attributes as the Cancel-Job operation (see [ipp-mod] section
-3.3.3), including the new "job-message-from-operator" operation
-attribute (see section 3.2).
-
-
-7.2.7 Space-Current-Job operation
-
-This OPTIONAL operation allows a client to repeat or skip a specified
-number of impressions for the current job on the target Printer or the
-specified job if it is the current job on the Printer. The Printer
-repeats or skips the indicated number of impressions specified by the
-"back-space" or "forward-space" operation attribute, respectively. This
-operation is typically supported in a continuous forms implementation
-for synchronizing the web after forms run out or media change.
-
-If the client does not supply a "job-id" operation attribute, the
-Printer MUST accept this request in any state, whether or not there is a
-current job, and advance or backspace the media the indicated number of
-impressions specified by the "back-space" or "forward-space" operation
-attribute, respectively. If more than one job is in the 'processing' or
-'processing-stopped' states, the one that is marking is spaced and the
-others are unaffected.
-
-It is reasonable, although not MANDATORY), to perform Space-Current-Job
-while the Printer is 'stopped', paused, or 'processing'. Between the
-time that a user issues this operation and its acceptance, the current
-job might change to a different job. To prevent this race from spacing
-the wrong job, the client MAY supply the "job-id" operation attribute
-which is checked against the current job's job-id. If the job
-identified by the "job-id" attribute is not the current job on the
-Printer, i.e., is not in the 'processing' or 'processing-stopped'
-states, or is not the job that has impressions in the media path even if
-the job has completed, the Printer MUST reject this operation and return
-the 'client-error-not-possible' status code. Otherwise, the Printer
-advances or backspaces the media the indicated number of impressions
-specified by the "back-space" or "forward-space" operation attribute,
-respectively.
-
-
-
-
-Kugler, Hastings, Lewis [Page 44]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-Access Rights: Authentication and access control (see [ipp-mod] sections
-1, 8.3, and 8.5) apply to this operation.
-
-The Space-Current-Job Request and Space-Current-Job Response have the
-same attribute groups and attributes as the Resume-Printer operation
-(see [ipp-mod] section 3.2.8), including the new "job-message-from-
-operator" operation attribute (see section 3.2), with the addition of
-the following Group 1 Operation attributes in the request:
-
- "job-id" (integer(1:MAX)):
-
- The client OPTIONALLY supplies this Operation attribute in order to
- verify that the identified job is still the current job on the
- target Printer object. The IPP object MUST supports this operation
- attribute, if it supports this operation.
-
- "back-space" (integer(1:MAX)):
-
- The client OPTIONALLY supplies this Operation attribute. The IPP
- object OPTIONALLY supports this operation attribute, if it is able
- to repeat impressions.
-
- If the client supplies a value that specifies more impressions than
- the job has performed, the job is positioned at the beginning
- without any indication.
-
- "forward-space" (integer(1:MAX)):
-
- The client OPTIONALLY supplies this Operation attribute. The IPP
- object OPTIONALLY supports this operation attribute, if it is able
- to skip impressions.
-
- If the client supplies a value that specifies more impressions than
- remain in the job, the job is positioned at the end without any
- indication.
-
-
-
-
-8. IANA Considerations
-
-The operations and attributes in this registration proposal will be
-published by IANA according to the procedures in RFC 2566 [rfc2566]
-section 6.4 for operations with the following URL:
-
- ftp.isi.edu/iana/assignments/ipp/operations/set2.txt
-
-
-
-9. Internationalization Considerations
-
-This document has the same localization considerations as the [ipp-mod].
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 45]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-10. Security Considerations
-
-The IPP Model and Semantics document [ipp-mod] discusses high level
-security requirements (Client Authentication, Server Authentication and
-Operation Privacy). Client Authentication is the mechanism by which the
-client proves its identity to the server in a secure manner. Server
-Authentication is the mechanism by which the server proves its identity
-to the client in a secure manner. Operation Privacy is defined as a
-mechanism for protecting operations from eavesdropping.
-
-
-11. Author's Addresses
-
- Carl Kugler
- IBM
- Boulder CA
-
- Phone: (303) 924-5060
- FAX:
- e-mail: kugler@us.ibm.com
-
- Tom Hastings
- Xerox Corporation
- 737 Hawaii St. ESAE 231
- El Segundo, CA 90245
-
- Phone: 310-333-6413
- Fax: 310-333-5514
- e-mail: hastings@cp10.es.xerox.com
-
- Harry Lewis
- IBM
- Boulder CA
-
- Phone: (303) 924-5337
- FAX:
- e-mail: harryl@us.ibm.com
-
-
-
-12. References
-
-[ipp-mod]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
- ipp-model-v11-03.txt>, June, 1999.
-
-[RFC2566]
- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April 1999.
-
-Kugler, Hastings, Lewis [Page 46]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-13. Change History
-
-
-This section summarizes the changes. Each sub-section is in reverse
-chronological order.
-
-
-13.1 Changes to the July 19, 1999 version to make the September 19, 1999
-version
-
-
-The following changes to the July 19, 1999 version to make the September
-19, 1999 version as a result of the IPP WG meeting in Alaska, 8/99:
-
-1.Refer to proposal as "Set2" rather than "Administrative" operations.
-
-2.Revise the emphasis on administrator throughout the document,
- although the word administrator remains wherever appropriate.
-
-3.Convert non-process-run-out from an operations attribute to an
- operation.
-
-4.Added Issue 21: For all these "access" caveats, why not just say...
- 'authentication and access control (see ipp-mod sections 1, 8.3 and
- 8.5) applies to this operation".?
-
-5.Added Issue 22: Why? This is backward, if you ask me (HRL).
-
-6.Per resolution of Issue 2, the "settable-attributes" Printer
- Description attribute, was replaced with three Printer Description
- attributes: "printer-settable-attributes", "job-settable-
- attributes", and "interpreter-settable-attributes". The latter for
- those implementations that have different values for Printer
- attributes in the Get-Printer-Attributes and Set-Printer-Attributes
- operations, depending on the value of the "document-format" operation
- attribute supplied by the client. If and when we get a Document
- object, then we can add a "document-settable-attributes" Printer
- Description attribute.
-
-7.Added the Interpreter object.
-
-
-13.2 Changes to the June 30, 1999 version to make the July 19, 1999
-version
-
-
-The following changes to the June 30, 1999 version to make the July 19,
-1999 version as a result of the IPP WG meeting in Copenhagen, 7/7/99-
-7/8/99, and the IPP telecon, 7/14/1999:
-
-1.Sections 2.1 and 2.2: Clarified that the way to remove a message
- from the operator was for the client to supply a zero-length or all
-
-
-
-Kugler, Hastings, Lewis [Page 47]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
- white space text string which is copied as usual to the "xxx-message-
- from-operator" attribute.
-
-2.Section 2.3: Added "factory-settings" (boolean) operation attribute
- to the Get-Printer-Attributes operation.
-
-3.Section 2.4: Added the "when" operation attribute to the Pause-
- Current-Job operation.
-
-4.Section 2.4: Made the "when" operation attribute OPTIONAL for use
- in operations (Pause-Printer, Reset-Printer, Shutdown-Printer, and
- Pause-Current-Job operations).
-
-5.Sections 2.5: Added table of operation attributes for the Printer
- operations to make it easy to compare.
-
-6.Sections 2.6: Added table of operation attributes for the Job
- operations to make it easy to compare.
-
-7.Section 3.1: Added "settable-attributes" (1setOf type2 keyword)
- READ-ONLY Printer Description attribute.
-
-8.Section 3.2: Added "printer-controls-other-protocols" (boolean)
- Printer Description attribute
-
-9.Section 3.3: Added the READ-ONLY "printer-message-time"
- (integer(MIN:MAX)) Printer Description attribute to keep time message
- updated in time ticks.
-
-10. Section 4.2: Deleted the 'process-next' "job-state-reasons" value,
- so that repeated Promote-Job operations promote each job "to the
- front of the queue".
-
-11. Sections 6.1.1.1 and 6.2.1.1: Replaced the table that listed all
- attributes with one that lists only the attributes that MUST be READ-
- ONLY.
-
-12. Section 6.1.1.1: Indicated that attributes that are not specified
- as READ-ONLY in this document MAY be settable. If they control
- behavior, that changing their values MUST change the behavior.
-
-13. Section 6.1.1.2 and 6.2.1.2: Deleted the "ipp-attribute-fidelity"
- operation attribute from the Set-Printer-Attributes and Set-Job-
- Attributes operations. All set operations are atomic.
-
-14. Section 6.1.1.2: Add the concept of the Interpreter object to
- handle attributes whose values vary in the Set-Printer-Attributes and
- Get-Printer-Attributes, depending on the value of the "document-
- format" operation attribute.
-
-
-
-Kugler, Hastings, Lewis [Page 48]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-15. Sections 6.1.1.3 and 6.2.1.2: Changed the "out-of-band" 'not-
- settable' value back to the existing 'not-supported' value.
-
-16. Section 6.1.2 and 6.1.3: Added "job-type" operation attribute to
- Disable-Printer and Enable-Printer operations with values: 'network-
- jobs', 'walk-up-jobs', and 'all-jobs'.
-
-17. Section 6.1.5: Clarified that Restart-Printer brings up the
- Printer disabled and paused, since that is the eventual state that
- Shutdown-Printer leaves the printer in.
-
-18. Section 6.1.5: Indicated that if Restart-Printer is supported,
- then Shutdown-Printer MUST be supported.
-
-19. Section 6.1.6: Deleted Space-Printer operation. Keep Space-
- Current-Job operation only which has a "job-id" operation attribute
- that a client MAY supply.
-
-20. Section 6.1.6: Clarified that Shutdown-Printer is for a long
- period of time, not just to reset the device or change attribute
- values. Also that Shutdown performs an immediate Disable-Printer and
- an eventual Pause-Printer.
-
-21. Sections 6.2.3, 6.2.4, and 6.2.7 : Added a "job-id" operation
- attribute to Cancel-Current-Job, Pause-Current-Job, and Space-
- Current-Job that a client MAY supply to check for race condition
- where current job changes
-
-22. Section 6.2.4: Combined Pause-Job into Pause-Current-Job
- operation.
-
-23. Sections 6.2.4 and 6.2.5: Pause-Current-Job puts job in
- 'processing-stopped' state, not 'pending-held' state.
-
-24. Section 6.2.6: Simplified Promote-Job, so that it behaves as if
- the job were put at the front of the queue.
-
-
-
-14. Appendix A: Full Copyright Statement
-
-
-Copyright (C) The Internet Society (1998,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,
-
-Kugler, Hastings, Lewis [Page 49]
- Expires: March 19, 2000
-
-
-
-PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kugler, Hastings, Lewis [Page 50]
- Expires: March 19, 2000
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML><HEAD>
+<TITLE>404 Not Found</TITLE>
+</HEAD><BODY>
+<H1>Not Found</H1>
+The requested URL /internet-drafts/draft-ietf-ipp-ops-set2-02.txt was not found on this server.<P>
+<HR>
+<ADDRESS>Apache/1.3.11 Server at www2.ietf.org Port 80</ADDRESS>
+</BODY></HTML>
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Robert Herriot (editor)
-<draft-ietf-ipp-protocol-v11-06.txt> Xerox Corporation
- Sylvan Butler
- Hewlett-Packard
- Paul Moore
- Peerless Systems Networking
- Randy Turner
- 2wire.com
- John Wenn
- Xerox Corporation
- May 30, 2000
-
-
- Internet Printing Protocol/1.1: Encoding and Transport
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of [RFC2026]. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress".
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed as
-http://www.ietf.org/shadow.html.
-
-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 defines the rules for encoding IPP
-operations and IPP attributes into a new Internet mime media type called
-"application/ipp". This document also defines the rules for
-transporting over HTTP a message body whose Content-Type is
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 1]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-"application/ipp". This document defines a new scheme named 'ipp' for
-identifying IPP printers and jobs.
-
-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.1: Model and Semantics [ipp-mod]
- Internet Printing Protocol/1.1: Encoding and Transport (this
- document)
- Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
- 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. It calls out a subset of end user requirements that are
-satisfied in IPP/1.1. A few OPTIONAL operator operations have been added
-to IPP/1.1.
-
-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
-specification documents, and gives background and rationale for the IETF
-working group's major decisions.
-
-The document, "Internet Printing Protocol/1.1: Model and Semantics",
-describes a simplified model with abstract objects, their attributes,
-and their operations that are independent of encoding and transport. It
-introduces a Printer and a Job object. The Job object optionally
-supports multiple documents per Job. It also addresses security,
-internationalization, and directory issues.
-
-The document "Internet Printing Protocol/1.1: Implementer's Guide",
-gives advice to implementers of IPP clients and IPP objects.
-
-The document "Mapping between LPD and IPP Protocols" gives some advice
-to implementers of gateways between IPP and LPD (Line Printer Daemon)
-implementations.
-
-
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 2]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- Table of Contents
-
-1. Introduction .......................................................5
-2. Conformance Terminology ............................................5
-3. Encoding of the Operation Layer ...................................5
- 3.1 Picture of the Encoding .......................................6
- 3.1.1 Request and Response.......................................6
- 3.1.2 Attribute Group............................................7
- 3.1.3 Attribute..................................................8
- 3.1.4 Picture of the Encoding of an Attribute-with-one-value.....8
- 3.1.5 Additional-value...........................................9
- 3.1.6 Alternative Picture of the Encoding of a Request Or a
- Response.........................................................9
- 3.2 Syntax of Encoding ...........................................10
- 3.3 Attribute-group ..............................................12
- 3.4 Required Parameters ..........................................13
- 3.4.1 Version-number............................................13
- 3.4.2 Operation-id..............................................13
- 3.4.3 Status-code...............................................13
- 3.4.4 Request-id................................................14
- 3.5 Tags .........................................................14
- 3.5.1 Delimiter Tags............................................14
- 3.5.2 Value Tags................................................15
- 3.6 Name-Length ..................................................17
- 3.7 (Attribute) Name .............................................18
- 3.8 Value Length .................................................18
- 3.9 (Attribute) Value ............................................18
- 3.10 Data .........................................................20
-4. Encoding of Transport Layer .......................................20
- 4.1 Printer-uri and job-uri ......................................21
-5. IPP URL Scheme ....................................................22
-6. IANA Considerations ...............................................24
-7. Internationalization Considerations ...............................24
-8. Security Considerations ...........................................24
- 8.1 Security Conformance Requirements ............................25
- 8.1.1 Digest Authentication.....................................25
- 8.1.2 Transport Layer Security (TLS)............................26
- 8.2 Using IPP with TLS ...........................................26
-9. Interoperability with IPP/1.0 Implementations .....................26
- 9.1 The "version-number" Parameter ...............................27
- 9.2 Security and URL Schemes .....................................27
-10. References .......................................................28
-11. Author's Address .................................................31
-12. Other Participants: ..............................................31
-13. Appendix A: Protocol Examples ....................................33
- 13.1 Print-Job Request ............................................33
- 13.2 Print-Job Response (successful) ..............................34
- 13.3 Print-Job Response (failure) .................................35
-
-
-Herriot, et al. Expires November 30, 2000 [Page 3]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- 13.4 Print-Job Response (success with attributes ignored) .........36
- 13.5 Print-URI Request ............................................38
- 13.6 Create-Job Request ...........................................39
- 13.7 Get-Jobs Request .............................................40
- 13.8 Get-Jobs Response ............................................41
-14. Appendix B: Registration of MIME Media Type Information for
-"application/ipp".....................................................42
-15. Appendix C: Changes from IPP/1.0 .................................44
-16. Full Copyright Statement .........................................45
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 4]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-1. Introduction
-
-This document contains the rules for encoding IPP operations and
-describes two layers: the transport layer and the operation layer.
-
-The transport layer consists of an HTTP/1.1 request or response. RFC
-2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP
-headers that an IPP implementation supports.
-
-The operation layer consists of a message body in an HTTP request or
-response. The document "Internet Printing Protocol/1.1: Model and
-Semantics" [ipp-mod] defines the semantics of such a message body and
-the supported values. This document specifies the encoding of an IPP
-operation. The aforementioned document [ipp-mod] is henceforth referred
-to as the "IPP model document" or simply "model document."
-
-Note: the version number of IPP (1.1) and HTTP (1.1) are not linked.
-They both just happen to be 1.1.
-
-
-2. Conformance Terminology
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
-interpreted as described in RFC 2119 [RFC2119].
-
-
-3. Encoding of the Operation Layer
-
-The operation layer is the message body part of the HTTP request or
-response and it MUST contain a single IPP operation request or IPP
-operation response. Each request or response consists of a sequence of
-values and attribute groups. Attribute groups consist of a sequence of
-attributes each of which is a name and value. Names and values are
-ultimately sequences of octets.
-
-The encoding consists of octets as the most primitive type. There are
-several types built from octets, but three important types are integers,
-character strings and octet strings, on which most other data types are
-built. Every character string in this encoding MUST be a sequence of
-characters where the characters are associated with some charset and
-some natural language. A character string MUST be in "reading order"
-with the first character in the value (according to reading order) being
-the first character in the encoding. A character string whose associated
-charset is US-ASCII whose associated natural language is US English is
-henceforth called a US-ASCII-STRING. A character string whose associated
-charset and natural language are specified in a request or response as
-
-
-Herriot, et al. Expires November 30, 2000 [Page 5]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-described in the model document is henceforth called a LOCALIZED-STRING.
-An octet string MUST be in "IPP model document order" with the first
-octet in the value (according to the IPP model document order) being the
-first octet in the encoding. Every integer in this encoding MUST be
-encoded as a signed integer using two's-complement binary encoding with
-big-endian format (also known as "network order" and "most significant
-byte first"). The number of octets for an integer MUST be 1, 2 or 4,
-depending on usage in the protocol. Such one-octet integers, henceforth
-called SIGNED-BYTE, are used for the version-number and tag fields. Such
-two-byte integers, henceforth called SIGNED-SHORT are used for the
-operation-id, status-code and length fields. Four byte integers,
-henceforth called SIGNED-INTEGER, are used for value fields and the
-request-id.
-
-The following two sections present the encoding of the operation layer
-in two ways:
-
- - informally through pictures and description
- - formally through Augmented Backus-Naur Form (ABNF), as specified by
- RFC 2234 [RFC2234]
-
-
-An operation request or response MUST use the encoding described in
-these two sections.
-
-
-3.1 Picture of the Encoding
-
-
-3.1.1 Request and Response
-
-An operation request or response is encoded as follows:
-
- -----------------------------------------------
- | version-number | 2 bytes - required
- -----------------------------------------------
- | operation-id (request) |
- | or | 2 bytes - required
- | status-code (response) |
- -----------------------------------------------
- | request-id | 4 bytes - required
- -----------------------------------------------
- | attribute-group | n bytes - 0 or more
- -----------------------------------------------
- | end-of-attributes-tag | 1 byte - required
- -----------------------------------------------
- | data | q bytes - optional
- -----------------------------------------------
-
-
-Herriot, et al. Expires November 30, 2000 [Page 6]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-The first three fields in the above diagram contain the value of
-attributes described in section 3.1.1 of the Model document.
-
-The fourth field is the "attribute-group" field, and it occurs 0 or more
-times. Each "attribute-group" field represents a single group of
-attributes, such as an Operation Attributes group or a Job Attributes
-group (see the Model document). The IPP model document specifies the
-required attribute groups and their order for each operation request and
-response.
-
-The "end-of-attributes-tag" field is always present, even when the
-"data" is not present. The Model document specifies for each operation
-request and response whether the "data" field is present or absent.
-
-
-3.1.2 Attribute Group
-
-Each "attribute-group" field is encoded as follows:
-
- -----------------------------------------------
- | begin-attribute-group-tag | 1 byte
- ----------------------------------------------------------
- | attribute | p bytes |- 0 or more
- ----------------------------------------------------------
-
-
-The "begin-attribute-group-tag" field marks the beginning of an
-"attribute-group" field and its value identifies the type of attribute
-group, e.g. Operations Attributes group versus a Job Attributes group.
-The "begin-attribute-group-tag" field also marks the end of the previous
-attribute group except for the "begin-attribute-group-tag" field in the
-first "attribute-group" field of a request or response. The "begin-
-attribute-group-tag" field acts as an "attribute-group" terminator
-because an "attribute-group" field cannot nest inside another
-"attribute-group" field.
-
-An "attribute-group" field contains zero or more "attribute" fields.
-
-Note, the values of the "begin-attribute-group-tag" field and the "end-
-of-attributes-tag" field are called "delimiter-tags".
-
-
-
-
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 7]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-3.1.3 Attribute
-
-An "attribute" field is encoded as follows:
-
- -----------------------------------------------
- | attribute-with-one-value | q bytes
- ----------------------------------------------------------
- | additional-value | r bytes |- 0 or more
- ----------------------------------------------------------
-
-
-When an attribute is single valued (e.g. "copies" with value of 10) or
-multi-valued with one value (e.g. "sides-supported" with just the value
-'one-sided') it is encoded with just an "attribute-with-one-value"
-field. When an attribute is multi-valued with n values (e.g. "sides-
-supported" with the values 'one-sided' and 'two-sided-long-edge'), it is
-encoded with an "attribute-with-one-value" field followed by n-1
-"additional-value" fields.
-
-
-3.1.4 Picture of the Encoding of an Attribute-with-one-value
-
-Each "attribute-with-one-value" field is encoded as follows:
-
- -----------------------------------------------
- | value-tag | 1 byte
- -----------------------------------------------
- | name-length (value is u) | 2 bytes
- -----------------------------------------------
- | name | u bytes
- -----------------------------------------------
- | value-length (value is v) | 2 bytes
- -----------------------------------------------
- | value | v bytes
- -----------------------------------------------
-
-An "attribute-with-one-value" field is encoded with five subfields:
-
- The "value-tag" field specifies the attribute syntax, e.g. 0x44 for
- the attribute syntax 'keyword'.
-
- The "name-length" field specifies the length of the "name" field in
- bytes, e.g. u in the above diagram or 15 for the name "sides-
- supported ".
-
- The "name" field contains the textual name of the attribute, e.g.
- "sides-supported".
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 8]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- The "value-length" field specifies the length of the "value" field in
- bytes, e.g. v in the above diagram or 9 for the (keyword) value 'one-
- sided'.
-
- The "value" field contains the value of the attribute, e.g. the
- textual value 'one-sided'.
-
-
-3.1.5 Additional-value
-
-Each "additional-value" field is encoded as follows:
-
- -----------------------------------------------
- | value-tag | 1 byte
- -----------------------------------------------
- | name-length (value is 0x0000) | 2 bytes
- -----------------------------------------------
- | value-length (value is w) | 2 bytes
- -----------------------------------------------
- | value | w bytes
- -----------------------------------------------
-
-An "additional-value" is encoded with four subfields:
-
- The "value-tag" field specifies the attribute syntax, e.g. 0x44 for
- the attribute syntax 'keyword'.
-
- The "name-length" field has the value of 0 in order to signify that
- it is an "additional-value". The value of the "name-length" field
- distinguishes an "additional-value" field ("name-length" is 0) from
- an "attribute-with-one-value" field ("name-length" is not 0).
-
- The "value-length" field specifies the length of the "value" field in
- bytes, e.g. w in the above diagram or 19 for the (keyword) value
- 'two-sided-long-edge'.
-
- The "value" field contains the value of the attribute, e.g. the
- textual value 'two-sided-long-edge'.
-
-
-3.1.6 Alternative Picture of the Encoding of a Request Or a Response
-
->From the standpoint of a parser that performs an action based on a "tag"
-value, the encoding consists of:
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 9]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- -----------------------------------------------
- | version-number | 2 bytes - required
- -----------------------------------------------
- | operation-id (request) |
- | or | 2 bytes - required
- | status-code (response) |
- -----------------------------------------------
- | request-id | 4 bytes - required
- -----------------------------------------------------------
- | tag (delimiter-tag or value-tag) | 1 byte |
- ----------------------------------------------- |-0 or more
- | empty or rest of attribute | x bytes |
- -----------------------------------------------------------
- | end-of-attributes-tag | 1 byte - required
- -----------------------------------------------
- | data | y bytes - optional
- -----------------------------------------------
-
-
-The following show what fields the parser would expect after each type
-of "tag":
-
- - "begin-attribute-group-tag": expect zero or more "attribute"s
- - "value-tag": expect the remainder of an "attribute-with-one-value"
- or an "additional-value".
- - "end-of-attributes-tag": expect that "attribute"s are complete and
- there is optional "data"
-
-3.2 Syntax of Encoding
-
-The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be
-case sensitive. For example 'a' means lower case 'a' and not upper case
-'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented
-as '%x' values which show their range of values.
-
- ipp-message = ipp-request / ipp-response
- ipp-request = version-number operation-id request-id
- *attribute-group end-of-attributes-tag data
- ipp-response = version-number status-code request-id
- *attribute-group end-of-attributes-tag data
- attribute-group = begin-attribute-group-tag attribute
-
-
-
- version-number = major-version-number minor-version-number
- major-version-number = SIGNED-BYTE
- minor-version-number = SIGNED-BYTE
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 10]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- operation-id = SIGNED-SHORT ; mapping from model defined below
- status-code = SIGNED-SHORT ; mapping from model defined below
- request-id = SIGNED-INTEGER ; whose value is > 0
-
- attribute = attribute-with-one-value *additional-value
-
- attribute-with-one-value = value-tag name-length name
- value-length value
- additional-value = value-tag zero-name-length value-length value
-
- name-length = SIGNED-SHORT ; number of octets of 'name'
- name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
- value-length = SIGNED-SHORT ; number of octets of 'value'
- value = OCTET-STRING
-
- data = OCTET-STRING
-
- zero-name-length = %x00.00 ; name-length of 0
- value-tag = %x10-FF ;see section 3.7.2
- begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1
- end-of-attributes-tag = %x03 ; tag of 3
- ; see section 3.7.1
- SIGNED-BYTE = BYTE
- SIGNED-SHORT = 2BYTE
- SIGNED-INTEGER = 4BYTE
- DIGIT = %x30-39 ; "0" to "9"
- LALPHA = %x61-7A ; "a" to "z"
- BYTE = %x00-FF
- OCTET-STRING = *BYTE
-
-The syntax below defines additional terms that are referenced in this
-document. This syntax provides an alternate grouping of the delimiter
-tags.
-
- delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1
- end-of-attributes-tag
- delimiter-tag = %x00-0F ; see section 3.7.1
-
- begin-attribute-group-tag = %x00 / operation-attributes-tag /
- job-attributes-tag / printer-attributes-tag /
- unsupported-attributes-tag / %x06-0F
- operation-attributes-tag = %x01 ; tag of 1
- job-attributes-tag = %x02 ; tag of 2
- printer-attributes-tag = %x04 ; tag of 4
- unsupported-attributes-tag = %x05 ; tag of 5
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 11]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-3.3 Attribute-group
-
-Each "attribute-group" field MUST be encoded with the "begin-attribute-
-group-tag" field followed by zero or more "attribute" sub-fields.
-
-The table below maps the model document group name to value of the
-"begin-attribute-group-tag" field:
-
-
- Model Document Group "begin-attribute-group-tag" field
- values
-
- Operation Attributes "operations-attributes-tag"
- Job Template Attributes "job-attributes-tag"
- Job Object Attributes "job-attributes-tag"
- Unsupported Attributes "unsupported-attributes-tag"
- Requested Attributes "job-attributes-tag"
- (Get-Job-Attributes)
- Requested Attributes "printer-attributes-tag"
- (Get-Printer-Attributes)
- Document Content in a special position as described
- above
-
-
-For each operation request and response, the model document prescribes
-the required and optional attribute groups, along with their order.
-Within each attribute group, the model document prescribes the required
-and optional attributes, along with their order.
-
-When the Model document requires an attribute group in a request or
-response and the attribute group contains zero attributes, a request or
-response SHOULD encode the attribute group with the "begin-attribute-
-group-tag" field followed by zero "attribute" fields. For example, if
-the client requests a single unsupported attribute with the Get-Printer-
-Attributes operation, the Printer MUST return no "attribute" fields, and
-it SHOULD return a "begin-attribute-group-tag" field for the Printer
-Attributes Group. The Unsupported Attributes group is not such an
-example. According to the model document, the Unsupported Attributes
-Group SHOULD be present only if the unsupported attributes group
-contains at least one attribute.
-
-A receiver of a request MUST be able to process the following as
-equivalent empty attribute groups:
-
- a) A "begin-attribute-group-tag" field with zero following
- "attribute" fields.
-
- b) An expected but missing "begin-attribute-group-tag" field.
-
-
-Herriot, et al. Expires November 30, 2000 [Page 12]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-When the Model document requires a sequence of an unknown number of
-attribute groups, each of the same type, the encoding MUST contain one
-"begin-attribute-group-tag" field for each attribute group even when an
-"attribute-group" field contains zero "attribute" sub-fields. For
-example, for the Get-Jobs operation may return zero attributes for some
-jobs and not others. The "begin-attribute-group-tag" field followed by
-zero "attribute" fields tells the recipient that there is a job in queue
-for which no information is available except that it is in the queue.
-
-
-3.4 Required Parameters
-
-Some operation elements are called parameters in the model document
-[ipp-mod]. They MUST be encoded in a special position and they MUST NOT
-appear as operation attributes. These parameters are described in the
-subsections below.
-
-
-3.4.1 Version-number
-
-The "version-number" field MUST consist of a major and minor version-
-number, each of which MUST be represented by a SIGNED-BYTE. The major
-version-number MUST be the first byte of the encoding and the minor
-version-number MUST be the second byte of the encoding. The protocol
-described in this document MUST have a major version-number of 1 (0x01)
-and a minor version-number of 1 (0x01). The ABNF for these two bytes
-MUST be %x01.01.
-
-
-3.4.2 Operation-id
-
-The "operation-id" field MUST contain an operation-id value defined in
-the model document. The value MUST be encoded as a SIGNED-SHORT and it
-MUST be in the third and fourth bytes of the encoding of an operation
-request.
-
-
-3.4.3 Status-code
-
-The "status-code" field MUST contain a status-code value defined in the
-model document. The value MUST be encoded as a SIGNED-SHORT and it MUST
-be in the third and fourth bytes of the encoding of an operation
-response.
-
-The status-code is an operation attribute in the model document. In the
-protocol, the status-code is in a special position, outside of the
-operation attributes.
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 13]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-If an IPP status-code is returned, then the HTTP Status-Code MUST be 200
-(successful-ok). With any other HTTP Status-Code value, the HTTP
-response MUST NOT contain an IPP message-body, and thus no IPP status-
-code is returned.
-
-
-3.4.4 Request-id
-
-The "request-id" field MUST contain a request-id value as defined in the
-model document. The value MUST be encoded as a SIGNED- INTEGER and it
-MUST be in the fifth through eighth bytes of the encoding.
-
-
-3.5 Tags
-
-There are two kinds of tags:
-
- - delimiter tags: delimit major sections of the protocol, namely
- attributes and data
- - value tags: specify the type of each attribute value
-
-3.5.1 Delimiter Tags
-
-
-The following table specifies the values for the delimiter tags:
-
-
- Tag Value (Hex) Meaning
-
- 0x00 reserved for definition in a future IETF
- standards track document
- 0x01 "operation-attributes-tag"
- 0x02 "job-attribute-tag"
- 0x03 "end-of-attributes-tag"
- 0x04 "printer-attribute-tag"
- 0x05 "unsupported-attribute-tag"
- 0x06-0x0f reserved for future delimiters in IETF
- standards track documents
-
-
-When a "begin-attribute-group-tag" field occurs in the protocol, it
-means that zero or more following attributes up to the next delimiter
-tag MUST be attributes belonging to the attribute group specified by the
-value of the "begin-attribute-group-tag". For example, if the value of
-"begin-attribute-group-tag" is 0x01, the following attributes MUST be
-members of the Operations Attributes group.
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 14]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in an
-operation. It MUST be the last "delimiter-tag". If the operation has a
-document-content group, the document data in that group MUST follow the
-"end-of-attributes-tag".
-
-The order and presence of "attribute-group" fields (whose beginning is
-marked by the "begin-attribute-group-tag" subfield) for each operation
-request and each operation response MUST be that defined in the model
-document. For further details, see section 3.7 "(Attribute) Name" and 13
-"Appendix A: Protocol Examples".
-
-A Printer MUST treat a "delimiter-tag" (values from 0x00 through 0x0F)
-differently from a "value-tag" (values from 0x10 through 0xFF) so that
-the Printer knows that there is an entire attribute group that it
-doesn't understand as opposed to a single value that it doesn't
-understand.
-
-
-3.5.2 Value Tags
-
-The remaining tables show values for the "value-tag" field, which is the
-first octet of an attribute. The "value-tag" field specifies the type of
-the value of the attribute.
-
-The following table specifies the "out-of-band" values for the "value-
-tag" field.
-
-
- Tag Value (Hex) Meaning
-
- 0x10 unsupported
- 0x11 reserved for 'default' for definition in a future
- IETF standards track document
- 0x12 unknown
- 0x13 no-value
- 0x14-0x1F reserved for "out-of-band" values in future IETF
- standards track documents.
-
-
-The following table specifies the integer values for the "value-tag"
-field:
-
-
-
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 15]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
- Tag Value (Hex) Meaning
-
- 0x20 reserved for definition in a future IETF
- standards track document
- 0x21 integer
- 0x22 boolean
- 0x23 enum
- 0x24-0x2F reserved for integer types for definition in
- future IETF standards track documents
-
-NOTE: 0x20 is reserved for "generic integer" if it should ever be
-needed.
-
-The following table specifies the octetString values for the "value-tag"
-field:
-
-
- Tag Value (Hex) Meaning
-
- 0x30 octetString with an unspecified format
- 0x31 dateTime
- 0x32 resolution
- 0x33 rangeOfInteger
- 0x34 reserved for definition in a future IETF
- standards track document
- 0x35 textWithLanguage
- 0x36 nameWithLanguage
- 0x37-0x3F reserved for octetString type definitions in
- future IETF standards track documents
-
-The following table specifies the character-string values for the
-"value-tag" field:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 16]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
- Tag Value (Hex) Meaning
-
- 0x40 reserved for definition in a future IETF
- standards track document
- 0x41 textWithoutLanguage
- 0x42 nameWithoutLanguage
- 0x43 reserved for definition in a future IETF
- standards track document
- 0x44 keyword
- 0x45 uri
- 0x46 uriScheme
- 0x47 charset
- 0x48 naturalLanguage
- 0x49 mimeMediaType
- 0x4A-0x5F reserved for character string type definitions
- in future IETF standards track documents
-
-NOTE: 0x40 is reserved for "generic character-string" if it should ever
-be needed.
-
-NOTE: an attribute value always has a type, which is explicitly
-specified by its tag; one such tag value is "nameWithoutLanguage". An
-attribute's name has an implicit type, which is keyword.
-
-The values 0x60-0xFF are reserved for future type definitions in IETF
-standards track documents.
-
-The tag 0x7F is reserved for extending types beyond the 255 values
-available with a single byte. A tag value of 0x7F MUST signify that the
-first 4 bytes of the value field are interpreted as the tag value. Note
-this future extension doesn't affect parsers that are unaware of this
-special tag. The tag is like any other unknown tag, and the value length
-specifies the length of a value, which contains a value that the parser
-treats atomically. Values from 0x00 to 0x37777777 are reserved for
-definition in future IETF standard track documents. The values
-0x40000000 to 0x7FFFFFFF are reserved for vendor extensions.
-
-
-3.6 Name-Length
-
-The "name-length" field MUST consist of a SIGNED-SHORT. This field MUST
-specify the number of octets in the immediately following "name" field.
-The value of this field excludes the two bytes of the "name-length"
-field. For example, if the "name" field contains "sides", the value of
-this field is 5.
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 17]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-If a "name-length" field has a value of zero, the following "name" field
-MUST be empty, and the following value MUST be treated as an additional
-value for the attribute encoded in the nearest preceding "attribute-
-with-one-value" field. Within an attribute group, if two or more
-attributes have the same name, the attribute group is mal-formed (see
-[ipp-mod] section 3.1.3). The zero-length name is the only mechanism for
-multi-valued attributes.
-
-
-3.7 (Attribute) Name
-
-The "name " field MUST contain the name of an attribute. The model
-document [ipp-mod] specifies such names.
-
-
-3.8 Value Length
-
-The "value-length" field MUST consist of a SIGNED-SHORT. This field MUST
-specify the number of octets in the immediately following "value" field.
-The value of this field excludes the two bytes of the "value-length"
-field. For example, if the "value" field contains the keyword (text)
-value 'one-sided', the value of this field is 9.
-
-For any of the types represented by binary signed integers, the sender
-MUST encode the value in exactly four octets.
-
-For any of the types represented by character-strings, the sender MUST
-encode the value with all the characters of the string and without any
-padding characters.
-
-For "out-of-band" "value-tag"s defined in this document, such as
-"unsupported", the "value-length" MUST be 0 and the "value" empty; the
-"value" has no meaning when the "value-tag" has one of these "out-of-
-band" values. For future "out-of-band" "value-tag"s, the same rule holds
-unless the definition explicitly states that the "value-length" MAY be
-non-zero and the "value" non-empty
-
-
-3.9 (Attribute) Value
-
-The syntax types (specified by the "value-tag" field) and most of the
-details of the representation of attribute values are defined in the IPP
-model document. The table below augments the information in the model
-document, and defines the syntax types from the model document in terms
-of the 5 basic types defined in section 3 "Encoding of the Operation
-Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED-
-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 18]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Syntax of Attribute Encoding
-Value
-
-textWithoutLanguage, LOCALIZED-STRING.
-nameWithoutLanguage
-
-textWithLanguage OCTET_STRING consisting of 4 fields:
- a. a SIGNED-SHORT which is the number of
- octets in the following field
- b. a value of type natural-language,
- c. a SIGNED-SHORT which is the number of
- octets in the following field,
- d. a value of type textWithoutLanguage.
- The length of a textWithLanguage value MUST be 4
- + the value of field a + the value of field c.
-
-nameWithLanguage OCTET_STRING consisting of 4 fields:
- a. a SIGNED-SHORT which is the number of
- octets in the following field
- b. a value of type natural-language,
- c. a SIGNED-SHORT which is the number of
- octets in the following field
- d. a value of type nameWithoutLanguage.
- The length of a nameWithLanguage value MUST be 4
- + the value of field a + the value of field c.
-
-charset, US-ASCII-STRING.
-naturalLanguage,
-mimeMediaType,
-keyword, uri, and
-uriScheme
-
-boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is
- 'true'.
-
-integer and enum a SIGNED-INTEGER.
-
-dateTime OCTET-STRING consisting of eleven octets whose
- contents are defined by "DateAndTime" in RFC
- 1903 [RFC1903].
-
-resolution OCTET_STRING consisting of nine octets of 2
- SIGNED-INTEGERs followed by a SIGNED-BYTE. The
- first SIGNED-INTEGER contains the value of cross
- feed direction resolution. The second SIGNED-
- INTEGER contains the value of feed direction
- resolution. The SIGNED-BYTE contains the units
-
-
-Herriot, et al. Expires November 30, 2000 [Page 19]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Syntax of Attribute Encoding
-Value
-
- value.
-
-rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs.
- The first SIGNED-INTEGER contains the lower
- bound and the second SIGNED-INTEGER contains the
- upper bound.
-
-1setOf X Encoding according to the rules for an attribute
- with more than 1 value. Each value X is encoded
- according to the rules for encoding its type.
-
-octetString OCTET-STRING
-
-
-The attribute syntax type of the value determines its encoding and the
-value of its "value-tag".
-
-
-3.10 Data
-
-The "data" field MUST include any data required by the operation
-
-
-4. Encoding of Transport Layer
-
-HTTP/1.1 [RFC2616] is the transport layer for this protocol.
-
-The operation layer has been designed with the assumption that the
-transport layer contains the following information:
-
- - the URI of the target job or printer operation
- - the total length of the data in the operation layer, either as a
- single length or as a sequence of chunks each with a length.
-
-
-It is REQUIRED that a printer implementation support HTTP over the IANA
-assigned Well Known Port 631 (the IPP default port), though a printer
-implementation may support HTTP over some other port as well.
-
-Each HTTP operation MUST use the POST method where the request-URI is
-the object target of the operation, and where the "Content-Type" of the
-message-body in each request and response MUST be "application/ipp". The
-message-body MUST contain the operation layer and MUST have the syntax
-described in section 3.2 "Syntax of Encoding". A client implementation
-
-
-Herriot, et al. Expires November 30, 2000 [Page 20]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-MUST adhere to the rules for a client described for HTTP1.1 [RFC2616] .
-A printer (server) implementation MUST adhere the rules for an origin
-server described for HTTP1.1 [RFC2616].
-
-An IPP server sends a response for each request that it receives. If an
-IPP server detects an error, it MAY send a response before it has read
-the entire request. If the HTTP layer of the IPP server completes
-processing the HTTP headers successfully, it MAY send an intermediate
-response, such as "100 Continue", with no IPP data before sending the
-IPP response. A client MUST expect such a variety of responses from an
-IPP server. For further information on HTTP/1.1, consult the HTTP
-documents [RFC2616].
-
-An HTTP server MUST support chunking for IPP requests, and an IPP client
-MUST support chunking for IPP responses according to HTTP/1.1[RFC2616].
-Note: this rule causes a conflict with non-compliant implementations of
-HTTP/1.1 that don't support chunking for POST methods, and this rule may
-cause a conflict with non-compliant implementations of HTTP/1.1 that
-don't support chunking for CGI scripts
-
-
-4.1 Printer-uri and job-uri
-
-All Printer and Job objects are identified by a Uniform Resource
-Identifier (URI) [RFC2396] so that they can be persistently and
-unambiguously referenced. The notion of a URI is a useful concept,
-however, until the notion of URI is more stable (i.e., defined more
-completely and deployed more widely), it is expected that the URIs used
-for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every
-URL is a specialized form of a URI, even though the more generic term
-URI is used throughout the rest of this document, its usage is intended
-to cover the more specific notion of URL as well.
-
-Some operation elements are encoded twice, once as the request-URI on
-the HTTP Request-Line and a second time as a REQUIRED operation
-attribute in the application/ipp entity. These attributes are the
-target URI for the operation and are called printer-uri and job-uri.
-Note: The target URI is included twice in an operation referencing the
-same IPP object, but the two URIs NEED NOT be literally identical. One
-can be a relative URI and the other can be an absolute URI. HTTP/1.1
-allows clients to generate and send a relative URI rather than an
-absolute URI. A relative URI identifies a resource with the scope of
-the HTTP server, but does not include scheme, host or port. The
-following statements characterize how URLs should be used in the mapping
-of IPP onto HTTP/1.1:
-
- 1. Although potentially redundant, a client MUST supply the target of
- the operation both as an operation attribute and as a URI at the
-
-
-Herriot, et al. Expires November 30, 2000 [Page 21]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- HTTP layer. The rationale for this decision is to maintain a
- consistent set of rules for mapping application/ipp to possibly
- many communication layers, even where URLs are not used as the
- addressing mechanism in the transport layer.
- 2. Even though these two URLs might not be literally identical (one
- being relative and the other being absolute), they MUST both
- reference the same IPP object. However, a Printer NEED NOT verify
- that the two URLs reference the same IPP object, and NEED NOT take
- any action if it determines the two URLs to be different.
- 3. The URI in the HTTP layer is either relative or absolute and is
- used by the HTTP server to route the HTTP request to the correct
- resource relative to that HTTP server. The HTTP server need not
- be aware of the URI within the operation request.
- 4. Once the HTTP server resource begins to process the HTTP request,
- it might get the reference to the appropriate IPP Printer object
- from either the HTTP URI (using to the context of the HTTP server
- for relative URLs) or from the URI within the operation request;
- the choice is up to the implementation.
- 5. HTTP URIs can be relative or absolute, but the target URI in the
- operation MUST be an absolute URI.
-
-5. IPP URL Scheme
-
-The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL
-that identifies either an IPP printer object or an IPP job object. The
-IPP attributes using the 'ipp' scheme are specified below. Because the
-HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp'
-URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules
-for constructing a Request-Line and HTTP headers. The mapping is simple
-because the 'ipp' scheme implies all of the same protocol semantics as
-that of the 'http' scheme [RFC2616], except that it represents a print
-service and the implicit (default) port number that clients use to
-connect to a server is port 631.
-
-In the remainder of this section the term 'ipp-URL' means a URL whose
-scheme is 'ipp' and whose implicit (default) port is 631. The term
-'http-URL' means a URL whose scheme is 'http', and the term 'https-URL'
-means a URL whose scheme is 'https',
-
-A client and an IPP object (i.e. the server) MUST support the ipp-URL
-value in the following IPP attributes.
- job attributes:
- job-uri
- job-printer-uri
- printer attributes:
- printer-uri-supported
- operation attributes:
- job-uri
-
-
-Herriot, et al. Expires November 30, 2000 [Page 22]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- printer-uri
-Each of the above attributes identifies a printer or job object. The
-ipp-URL is intended as the value of the attributes in this list, and for
-no other attributes. All of these attributes have a syntax type of
-'uri', but there are attributes with a syntax type of 'uri' that do not
-use the 'ipp' scheme, e.g. 'job-more-info'.
-
-If a printer registers its URL with a directory service, the printer
-MUST register an ipp-URL.
-
-User interfaces are beyond the scope of this document. But if software
-exposes the ipp-URL values of any of the above five attributes to a
-human user, it is REQUIRED that the human see the ipp-URL as is.
-
-When a client sends a request, it MUST convert a target ipp-URL to a
-target http-URL for the HTTP layer according to the following rules:
- 1. change the 'ipp' scheme to 'http'
- 2. add an explicit port 631 if the URL does not contain an explicit
- port. Note: port 631 is the IANA assigned Well Known Port for the
- 'ipp' scheme.
-
-The client MUST use the target http-URL in both the HTTP Request-Line
-and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the
-client MUST use the target ipp-URL for the value of the "printer-uri" or
-"job-uri" operation attribute within the application/ipp body of the
-request. The server MUST use the ipp-URL for the value of the "printer-
-uri", "job-uri" or "printer-uri-supported" attributes within the
-application/ipp body of the response.
-
-For example, when an IPP client sends a request directly (i.e. no proxy)
-to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP
-connection to port 631 (the ipp implicit port) on the host "myhost.com"
-and sends the following data:
-
-POST /myprinter/myqueue HTTP/1.1
-Host: myhost.com:631
-Content-type: application/ipp
-Transfer-Encoding: chunked
-...
-"printer-uri" "ipp://myhost.com/myprinter/myqueue"
- (encoded in application/ipp message body)
-...
-
-As another example, when an IPP client sends the same request as above
-via a proxy "myproxy.com", it opens a TCP connection to the proxy port
-8080 on the proxy host "myproxy.com" and sends the following data:
-
-POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
-
-
-Herriot, et al. Expires November 30, 2000 [Page 23]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-Host: myhost.com:631
-Content-type: application/ipp
-Transfer-Encoding: chunked
-...
-"printer-uri" "ipp://myhost.com/myprinter/myqueue"
- (encoded in application/ipp message body)
-...
-
-The proxy then connects to the IPP origin server with headers that are
-the same as the "no-proxy" example above.
-
-6. IANA Considerations
-
-This section describes the procedures for allocating encoding for the
-following IETF standards track extensions and vendor extensions to the
-IPP/1.1 Encoding and Transport document:
-
- 1. attribute syntaxes - see [ipp-mod] section 6.3
- 2. attribute groups - see [ipp-mod] section 6.5
- 3. out-of-band attribute values - see [ipp-mod] section 6.7
-
-
-These extensions follow the "type2" registration procedures defined in
-[ipp-mod] section 6. Extensions registered for use with IPP/1.1 are
-OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding
-and Transport document.
-
-These extension procedures are aligned with the guidelines as set forth
-by the IESG [IANA-CON]. The [ipp-mod] Section 11 describes how to
-propose new registrations for consideration. IANA will reject
-registration proposals that leave out required information or do not
-follow the appropriate format described in [ipp-mod] Section 11. The
-IPP/1.1 Encoding and Transport document may also be extended by an
-appropriate RFC that specifies any of the above extensions.
-
-
-7. Internationalization Considerations
-
-See the section on "Internationalization Considerations" in the document
-"Internet Printing Protocol/1.1: Model and Semantics" [ipp-mod] for
-information on internationalization. This document adds no additional
-issues.
-
-
-8. Security Considerations
-
-The IPP Model and Semantics document [ipp-mod] discusses high level
-security requirements (Client Authentication, Server Authentication and
-
-
-Herriot, et al. Expires November 30, 2000 [Page 24]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-Operation Privacy). Client Authentication is the mechanism by which the
-client proves its identity to the server in a secure manner. Server
-Authentication is the mechanism by which the server proves its identity
-to the client in a secure manner. Operation Privacy is defined as a
-mechanism for protecting operations from eavesdropping.
-
-
-8.1 Security Conformance Requirements
-
-This section defines the security requirements for IPP clients and IPP
-objects.
-
-
-8.1.1 Digest Authentication
-
-IPP clients MUST support:
-
- Digest Authentication [RFC2617].
-
- MD5 and MD5-sess MUST be implemented and supported.
-
- The Message Integrity feature NEED NOT be used.
-
-
-
-IPP Printers SHOULD support:
-
- Digest Authentication [RFC2617].
-
- MD5 and MD5-sess MUST be implemented and supported.
-
- The Message Integrity feature NEED NOT be used.
-
-The reasons that IPP Printers SHOULD (rather than MUST) support Digest
-Authentication are:
-
-1.While Client Authentication is important, there is a certain class of
- printer devices where it does not make sense. Specifically, a low-
- end device with limited ROM space and low paper throughput may not
- need Client Authentication. This class of device typically requires
- firmware designers to make trade-offs between protocols and
- functionality to arrive at the lowest-cost solution possible.
- Factored into the designer's decisions is not just the size of the
- code, but also the testing, maintenance, usefulness, and time-to-
- market impact for each feature delivered to the customer. Forcing
- such low-end devices to provide security in order to claim IPP/1.1
- conformance would not make business sense and could potentially stall
- the adoption of the standard.
-
-
-Herriot, et al. Expires November 30, 2000 [Page 25]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-2.Print devices that have high-volume throughput and have available ROM
- space have a compelling argument to provide support for Client
- Authentication that safeguards the device from unauthorized access.
- These devices are prone to a high loss of consumables and paper if
- unauthorized access should occur.
-
-
-8.1.2 Transport Layer Security (TLS)
-
-IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for
-Server Authentication and Operation Privacy. IPP Printers MAY also
-support TLS for Client Authentication. If an IPP Printer supports TLS,
-it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as
-mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL.
-An IPP Printer MAY support Basic Authentication (described in HTTP/1.1
-[RFC2617]) for Client Authentication if the channel is secure. TLS with
-the above mandated cipher suite can provide such a secure channel.
-
-If a IPP client supports TLS, it MUST support the
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
-[RFC2246]. All other cipher suites are OPTIONAL.
-
-The IPP Model and Semantics document defines two printer attributes
-("uri-authentication-supported" and "uri-security-supported") that the
-client can use to discover the security policy of a printer. That
-document also outlines IPP-specific security considerations and should
-be the primary reference for security implications with regard to the
-IPP protocol itself. For backward compatibility with IPP version 1.0,
-IPP clients and printers may also support SSL3 [ssl]. This is in
-addition to the security required in this document.
-
-
-8.2 Using IPP with TLS
-
-IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817].
-An initial IPP request never uses TLS. The client requests a secure TLS
-connection by using the HTTP "Upgrade" header, while the server agrees
-in the HTTP response. The switch to TLS occurs either because the
-server grants the client's request to upgrade to TLS, or a server asks
-to switch to TLS in its response. Secure communication begins with a
-server's response to switch to TLS.
-
-
-9. Interoperability with IPP/1.0 Implementations
-
-It is beyond the scope of this specification to mandate conformance with
-previous versions. IPP/1.1 was deliberately designed, however, to make
-
-
-Herriot, et al. Expires November 30, 2000 [Page 26]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-supporting previous versions easy. It is worth noting that, at the time
-of composing this specification (1999), we would expect IPP/1.1 Printer
-implementations to:
-
- understand any valid request in the format of IPP/1.0, or 1.1;
-
- respond appropriately with a response containing the same "version-
- number" parameter value used by the client in the request.
-
-And we would expect IPP/1.1 clients to:
-
- understand any valid response in the format of IPP/1.0, or 1.1.
-
-
-9.1 The "version-number" Parameter
-
-The following are rules regarding the "version-number" parameter (see
-section 3.3):
-
- 1. Clients MUST send requests containing a "version-number" parameter
- with a '1.1' value and SHOULD try supplying alternate version
- numbers if they receive a 'server-error-version-not-supported'
- error return in a response.
-
- 2. IPP objects MUST accept requests containing a "version-number"
- parameter with a '1.1' value (or reject the request for reasons
- other than 'server-error-version-not-supported').
-
- 3. It is recommended that IPP objects accept any request with the
- major version '1' (or reject the request for reasons other than
- 'server-error-version-not-supported'). See [ipp-mod] "versions"
- sub-section.
-
- 4. In any case, security MUST NOT be compromised when a client
- supplies a lower "version-number" parameter in a request. For
- example, if an IPP/1.1 conforming Printer object accepts version
- '1.0' requests and is configured to enforce Digest Authentication,
- it MUST do the same for a version '1.0' request.
-
-
-9.2 Security and URL Schemes
-
-The following are rules regarding security, the "version-number"
-parameter, and the URL scheme supplied in target attributes and
-responses:
-
- 1. When a client supplies a request, the "printer-uri" or "job-uri"
- target operation attribute MUST have the same scheme as that
-
-
-Herriot, et al. Expires November 30, 2000 [Page 27]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
- indicated in one of the values of the "printer-uri-supported"
- Printer attribute.
-
- 2. When the server returns the "job-printer-uri" or "job-uri" Job
- Description attributes, it SHOULD return the same scheme ('ipp',
- 'https', 'http', etc.) that the client supplied in the "printer-
- uri" or "job-uri" target operation attributes in the Get-Job-
- Attributes or Get-Jobs request, rather than the scheme used when
- the job was created. However, when a client requests job
- attributes using the Get-Job-Attributes or Get-Jobs operations,
- the jobs and job attributes that the server returns depends on:
- (1) the security in effect when the job was created, (2) the
- security in effect in the query request, and (3) the security
- policy in force.
-
- 3. It is recommended that if a server registers a non-secure ipp-URL
- with a directory service (see [IPP-MOD] "Generic Directory Schema"
- Appendix), then it also register an http-URL for interoperability
- with IPP/1.0 clients (see section 9).
-
- 4. In any case, security MUST NOT be compromised when a client
- supplies an 'http' or other non-secure URL scheme in the target
- "printer-uri" and "job-uri" operation attributes in a request.
-
-
-10. References
-
-[dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
-
-[iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-
- notes/iana/assignments/character-sets.
-
-[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1:
- Implementer's Guide", draft-ietf-ipp-implementers-guide-v11-
- 00.txt, work in progress, September 27, 1999.
-
-[ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.1: Model and Semantics", <draft-
- ietf-ipp-model-v11-07.txt>, May 22, 2000.
-
-[ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
- Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp-
- protocol-v11-06.txt, May 30, 2000.
-
-[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", RFC 822, August 1982.
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 28]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-[RFC1123] Braden, S., "Requirements for Internet Hosts - Application
- and Support", RFC 1123, October, 1989.
-
-[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol"
- RFC 1179, August 1990.
-
-[RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October
- 1993.
-
-[RFC1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform
- Resource Locators (URL)", RFC 1738, December, 1994.
-
-[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and
- Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
-
-[RFC1766] H. Alvestrand, " Tags for the Identification of Languages",
- RFC 1766, March 1995.
-
-[RFC1808] R. Fielding, "Relative Uniform Resource Locators", RFC1808,
- June 1995.
-
-[RFC1903] J. Case, et al. "Textual Conventions for Version 2 of the
- Simple Network Management Protocol (SNMPv2)", RFC 1903, January
- 1996.
-
-[RFC2046] N. Freed & N. Borenstein, Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046.
-
-[RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail
- Extension (MIME) Part Four: Registration Procedures. November
- 1996 (Also BCP0013), RFC 2048.
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119 , March 1997.
-
-[RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word
- Extensions: Character Sets, Languages, and Continuations", RFC
- 2184, August 1997.
-
-[RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications:
- ABNF", RFC 2234. November 1997.
-
-[RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999.
-
-[RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396, August
- 1998.
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 29]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-[RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
- Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
- 1999.
-
-[RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
- "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
- April, 1999.
-
-[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol",
- RFC2567, April 1999.
-
-[RFC2568] Zilles, S., "Rationale for the Structure and Model and
- Protocol for the Internet Printing Protocol", RC 2568, April
- 1999.
-
-[RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping
- between LPD and IPP Protocols RFC 2569, April 1999.
-
-[RFC2616]
- R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
- Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
- RFC 2616, June 1999.
-
-[RFC2617]
- J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,
- A. Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest
- Access Authentication", RFC 2617, June 1999.
-
-[RFC2817] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
- RFC 2817, May 2000.
-
-[SSL]
- Netscape, The SSL Protocol, Version 3, (Text version 3.02),
- November 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 30]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-11. Author's Address
-
-Robert Herriot (editor) Paul Moore
-Xerox Corporation Peerless Systems Networking
-3400 Hillview Ave., Bldg #1 10900 NE 8th St #900
-Palo Alto, CA 94304 Bellevue, WA 98004
-
-Phone: 650-813-7696 Phone: 425-462-5852
-Fax: 650-813-6860
-Email: Email: pmoore@peerless.com
-robert.herriot@pahv.xerox.com
-
-Sylvan Butler Randy Turner
-Hewlett-Packard 2Wire, Inc.
-11311 Chinden Blvd. 694 Tasman Dr.
-Boise, ID 83714 Milpitas, CA 95035
-
-Phone: 208-396-6000 Phone: 408-546-1273
-Fax: 208-396-3457
-Email: sbutler@boi.hp.com
-
- John Wenn
- Xerox Corporation
- 737 Hawaii St
- El Segundo, CA 90245
-
-IPP Mailing List: ipp@pwg.org Phone: 310-333-5764
-IPP Mailing List Subscription: Fax: 310-333-5514
-ipp-request@pwg.org
-IPP Web Page: Email: jwenn@cp10.es.xerox.com
-http://www.pwg.org/ipp/
-
-
-12. Other Participants:
-
-Chuck Adams - Tektronix Shivaun Albright - HP
-Stefan Andersson - Axis Jeff Barnett - IBM
-Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
-Systems
-Keith Carter - IBM Angelo Caruso - Xerox
-Rajesh Chawla - TR Computing Nancy Chen - Okidata
-Solutions
-Josh Cohen - Microsoft Jeff Copeland - QMS
-Andy Davidson - Tektronix Roger deBry - IBM
-Maulik Desai - Auco Mabry Dozier - QMS
-Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
-Systems
-Steve Gebert - IBM Sue Gleeson - Digital
-
-
-Herriot, et al. Expires November 30, 2000 [Page 31]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-Charles Gordon - Osicom Brian Grimshaw - Apple
-Jerry Hadsell - IBM Richard Hart - Digital
-Tom Hastings - Xerox Henrik Holst - I-data
-Stephen Holmstead Zhi-Hong Huang - Zenographics
-Scott Isaacson - Novell Babek Jahromi - Microsoft
-Swen Johnson - Xerox David Kellerman - Northlake
- Software
-Robert Kline - TrueSpectra Charles Kong - Panasonic
-Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
-Takami Kurono - Brother Rick Landau - Digital
-Scott Lawrence - Agranot Systems Greg LeClair - Epson
-Dwight Lewis - Lexmark Harry Lewis - IBM
-Tony Liao - Vivid Image Roy Lomicka - Digital
-Pete Loya - HP Ray Lutz - Cognisys
-Mike MacKay - Novell, Inc. David Manchala - Xerox
-Carl-Uno Manros - Xerox Jay Martin - Underscore
-Stan McConnell - Xerox Larry Masinter - Xerox
-Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
-Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
-Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
-Pat Nogay - IBM Ron Norton - Printronics
-Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
-Patrick Powell - Astart Jeff Rackowitz - Intermec
-Technologies
-Eric Random - Peerless Rob Rhoads - Intel
-Xavier Riley - Xerox Gary Roberts - Ricoh
-David Roach - Unisys Stuart Rowley - Kyocera
-Yuji Sasaki - Japan Computer Richard Schneider - Epson
-Industry
-Kris Schoff - HP Katsuaki Sekiguchi - Canon
- Information Systems
-Bob Setterbo - Adobe Gail Songer - Peerless
-Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
-Systems
-Mike Timperman - Lexmark Atsushi Uchino - Epson
-Shigeru Ueda - Canon Bob Von Andel - Allegro Software
-William Wagner - NetSilicon/DPI Jim Walker - DAZEL
-Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
-Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
-Jasper Wong - Xionics Don Wright - Lexmark
-Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
-Michael Yeung - Canon Information Lloyd Young - Lexmark
-Systems
-Atsushi Yuki - Kyocera Peter Zehler - Xerox
-William Zhang- Canon Information Frank Zhao - Panasonic
-Systems
-Steve Zilles - Adobe Rob Zirnstein - Canon Information
- Systems
-
-
-Herriot, et al. Expires November 30, 2000 [Page 32]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-13. Appendix A: Protocol Examples
-
-
-13.1 Print-Job Request
-
-The following is an example of a Print-Job request with job-name,
-copies, and sides specified. The "ipp-attribute-fidelity" attribute is
-set to 'true' so that the print request will fail if the "copies" or the
-"sides" attribute are not supported or their values are not supported.
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x0002 Print-Job operation-id
-0x00000001 1 request-id
-0x01 start operation-attributes operation-attributes-tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x0008 value-length
-us-ascii US-ASCII value
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- name
-natural- attributes-natural-language
-language
-0x0005 value-length
-en-us en-US value
-0x45 uri type value-tag
-0x000B name-length
-printer-uri printer-uri name
-0x0015 value-length
-ipp://forest/p printer pinetree value
-inetree
-0x42 nameWithoutLanguage type value-tag
-0x0008 name-length
-job-name job-name name
-0x0006 value-length
-foobar foobar value
-0x22 boolean type value-tag
-0x0016 name-length
-ipp-attribute- ipp-attribute-fidelity name
-fidelity
-0x0001 value-length
-0x01 true value
-
-
-Herriot, et al. Expires November 30, 2000 [Page 33]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
-0x02 start job-attributes job-attributes-tag
-0x21 integer type value-tag
-0x0006 name-length
-copies copies name
-0x0004 value-length
-0x00000014 20 value
-0x44 keyword type value-tag
-0x0005 name-length
-sides sides name
-0x0013 value-length
-two-sided- two-sided-long-edge value
-long-edge
-0x03 end-of-attributes end-of-attributes-tag
-%!PS... <PostScript> data
-
-13.2 Print-Job Response (successful)
-
-Here is an example of a successful Print-Job response to the previous
-Print-Job request. The printer supported the "copies" and "sides"
-attributes and their supplied values. The status code returned is
-'successful-ok'.
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x0000 successful-ok status-code
-0x00000001 1 request-id
-0x01 start operation-attributes operation-attributes-tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x0008 value-length
-us-ascii US-ASCII value
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- attributes-natural- name
-natural-language language
-0x0005 value-length
-en-us en-US value
-0x41 textWithoutLanguage type value-tag
-0x000E name-length
-status-message status-message name
-0x000D value-length
-
-
-Herriot, et al. Expires November 30, 2000 [Page 34]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
-successful-ok successful-ok value
-0x02 start job-attributes job-attributes-tag
-0x21 integer value-tag
-0x0006 name-length
-job-id job-id name
-0x0004 value-length
-147 147 value
-0x45 uri type value-tag
-0x0007 name-length
-job-uri job-uri name
-0x0019 value-length
-ipp://forest/pin job 123 on pinetree value
-etree/123
-0x23 enum type value-tag
-0x0009 name-length
-job-state job-state name
-0x0004 value-length
-0x0003 pending value
-0x03 end-of-attributes end-of-attributes-tag
-
-
-13.3 Print-Job Response (failure)
-
-Here is an example of an unsuccessful Print-Job response to the previous
-Print-Job request. It fails because, in this case, the printer does not
-support the "sides" attribute and because the value '20' for the
-"copies" attribute is not supported. Therefore, no job is created, and
-neither a "job-id" nor a "job-uri" operation attribute is returned. The
-error code returned is 'client-error-attributes-or-values-not-supported'
-(0x040B).
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x040B client-error-attributes-or- status-code
- values-not-supported
-0x00000001 1 request-id
-0x01 start operation-attributes operation-attribute tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x0008 value-length
-us-ascii US-ASCII value
-
-
-Herriot, et al. Expires November 30, 2000 [Page 35]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- attributes-natural-language name
-natural-
-language
-0x0005 value-length
-en-us en-US value
-0x41 textWithoutLanguage type value-tag
-0x000E name-length
-status- status-message name
-message
-0x002F value-length
-client-error- value
-attributes- values-not-supported
-or-values- client-error-attributes-or-
-not-supported
-0x05 start unsupported-attributes unsupported-attributes tag
-0x21 integer type value-tag
-0x0006 name-length
-copies copies name
-0x0004 value-length
-0x00000014 20 value
-0x10 unsupported (type) value-tag
-0x0005 name-length
-sides sides name
-0x0000 value-length
-0x03 end-of-attributes end-of-attributes-tag
-
-13.4 Print-Job Response (success with attributes ignored)
-
-Here is an example of a successful Print-Job response to a Print-Job
-request like the previous Print-Job request, except that the value of
-'ipp-attribute-fidelity' is false. The print request succeeds, even
-though, in this case, the printer supports neither the "sides" attribute
-nor the value '20' for the "copies" attribute. Therefore, a job is
-created, and both a "job-id" and a "job-uri" operation attribute are
-returned. The unsupported attributes are also returned in an Unsupported
-Attributes Group. The error code returned is 'successful-ok-ignored-or-
-substituted-attributes' (0x0001).
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x0001 successful-ok-ignored-or- status-code
-
-
-Herriot, et al. Expires November 30, 2000 [Page 36]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
- substituted-attributes
-0x00000001 1 request-id
-0x01 start operation-attributes operation-attributes-tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x0008 value-length
-us-ascii US-ASCII value
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- attributes-natural- name
-natural-language language
-0x0005 value-length
-en-us en-US value
-0x41 textWithoutLanguage type value-tag
-0x000E name-length
-status-message status-message name
-0x002F value-length
-successful-ok- successful-ok-ignored-or- value
-ignored-or- substituted-attributes
-substituted-
-attributes
-0x05 start unsupported- unsupported-attributes
- attributes tag
-0x21 integer type value-tag
-0x0006 name-length
-copies copies name
-0x0004 value-length
-0x00000014 20 value
-0x10 unsupported (type) value-tag
-0x0005 name-length
-sides sides name
-0x0000 value-length
-0x02 start job-attributes job-attributes-tag
-0x21 integer value-tag
-0x0006 name-length
-job-id job-id name
-0x0004 value-length
-147 147 value
-0x45 uri type value-tag
-0x0007 name-length
-job-uri job-uri name
-0x0019 value-length
-ipp://forest/pin job 123 on pinetree value
-
-
-Herriot, et al. Expires November 30, 2000 [Page 37]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
-etree/123
-0x23 enum type value-tag
-0x0009 name-length
-job-state job-state name
-0x0004 value-length
-0x0003 pending value
-0x03 end-of-attributes end-of-attributes-tag
-
-
-13.5 Print-URI Request
-
-The following is an example of Print-URI request with copies and job-
-name parameters:
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x0003 Print-URI operation-id
-0x00000001 1 request-id
-0x01 start operation-attributes operation-attributes-tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x0008 value-length
-us-ascii US-ASCII value
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- attributes-natural-language name
-natural-
-language
-0x0005 value-length
-en-us en-US value
-0x45 uri type value-tag
-0x000B name-length
-printer-uri printer-uri name
-0x0015 value-length
-ipp://forest/ printer pinetree value
-pinetree
-0x45 uri type value-tag
-0x000C name-length
-document-uri document-uri name
-0x0011 value-length
-ftp://foo.com ftp://foo.com/foo value
-
-
-Herriot, et al. Expires November 30, 2000 [Page 38]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
-/foo
-0x42 nameWithoutLanguage type value-tag
-0x0008 name-length
-job-name job-name name
-0x0006 value-length
-foobar foobar value
-0x02 start job-attributes job-attributes-tag
-0x21 integer type value-tag
-0x0006 name-length
-copies copies name
-0x0004 value-length
-0x00000001 1 value
-0x03 end-of-attributes end-of-attributes-tag
-
-
-13.6 Create-Job Request
-
-The following is an example of Create-Job request with no parameters and
-no attributes:
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x0005 Create-Job operation-id
-0x00000001 1 request-id
-0x01 start operation-attributes operation-attributes-tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x0008 value-length
-us-ascii US-ASCII value
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- attributes-natural-language name
-natural-
-language
-0x0005 value-length
-en-us en-US value
-0x45 uri type value-tag
-0x000B name-length
-printer-uri printer-uri name
-0x0015 value-length
-ipp://forest/p printer pinetree value
-
-
-Herriot, et al. Expires November 30, 2000 [Page 39]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
-inetree
-0x03 end-of-attributes end-of-attributes-tag
-
-
-13.7 Get-Jobs Request
-
-The following is an example of Get-Jobs request with parameters but no
-attributes:
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x000A Get-Jobs operation-id
-0x00000123 0x123 request-id
-0x01 start operation-attributes operation-attributes-tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x0008 value-length
-us-ascii US-ASCII value
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- attributes-natural-language name
-natural-
-language
-0x0005 value-length
-en-us en-US value
-0x45 uri type value-tag
-0x000B name-length
-printer-uri printer-uri name
-0x0015 value-length
-ipp://forest/pi printer pinetree value
-netree
-0x21 integer type value-tag
-0x0005 name-length
-limit limit name
-0x0004 value-length
-0x00000032 50 value
-0x44 keyword type value-tag
-0x0014 name-length
-requested- requested-attributes name
-attributes
-0x0006 value-length
-
-
-Herriot, et al. Expires November 30, 2000 [Page 40]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
-job-id job-id value
-0x44 keyword type value-tag
-0x0000 additional value name-length
-0x0008 value-length
-job-name job-name value
-0x44 keyword type value-tag
-0x0000 additional value name-length
-0x000F value-length
-document-format document-format value
-0x03 end-of-attributes end-of-attributes-tag
-
-
-13.8 Get-Jobs Response
-
-The following is an of Get-Jobs response from previous request with 3
-jobs. The Printer returns no information about the second job (because
-of security reasons):
-
-
-Octets Symbolic Value Protocol field
-
-0x0101 1.1 version-number
-0x0000 successful-ok status-code
-0x00000123 0x123 request-id (echoed
- back)
-0x01 start operation-attributes operation-attribute-tag
-0x47 charset type value-tag
-0x0012 name-length
-attributes- attributes-charset name
-charset
-0x000A value-length
-ISO-8859-1 ISO-8859-1 value
-0x48 natural-language type value-tag
-0x001B name-length
-attributes- attributes-natural-language name
-natural-
-language
-0x0005 value-length
-en-us en-US value
-0x41 textWithoutLanguage type value-tag
-0x000E name-length
-status-message status-message name
-0x000D value-length
-successful-ok successful-ok value
-0x02 start job-attributes (1st job-attributes-tag
-
-
-Herriot, et al. Expires November 30, 2000 [Page 41]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-
-Octets Symbolic Value Protocol field
-
- object)
-0x21 integer type value-tag
-0x0006 name-length
-job-id job-id name
-0x0004 value-length
-147 147 value
-0x36 nameWithLanguage value-tag
-0x0008 name-length
-job-name job-name name
-0x000C value-length
-0x0005 sub-value-length
-fr-ca fr-CA value
-0x0003 sub-value-length
-fou fou name
-0x02 start job-attributes (2nd job-attributes-tag
- object)
-0x02 start job-attributes (3rd job-attributes-tag
- object)
-0x21 integer type value-tag
-0x0006 name-length
-job-id job-id name
-0x0004 value-length
-148 149 value
-0x36 nameWithLanguage value-tag
-0x0008 name-length
-job-name job-name name
-0x0012 value-length
-0x0005 sub-value-length
-de-CH de-CH value
-0x0009 sub-value-length
-isch guet isch guet name
-0x03 end-of-attributes end-of-attributes-tag
-
-14. Appendix B: Registration of MIME Media Type Information for
-"application/ipp"
-
-This appendix contains the information that IANA requires for
-registering a MIME media type. The information following this paragraph
-will be forwarded to IANA to register application/ipp whose contents are
-defined in Section 3 "Encoding of the Operation Layer" in this
-document:
-
-MIME type name: application
-
-MIME subtype name: ipp
-
-
-Herriot, et al. Expires November 30, 2000 [Page 42]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-A Content-Type of "application/ipp" indicates an Internet Printing
-Protocol message body (request or response). Currently there is one
-version: IPP/1.1, whose syntax is described in Section 3 "Encoding of
-the Operation Layer" of [ipp-pro], and whose semantics are described in
-[ipp-mod].
-
-Required parameters: none
-
-Optional parameters: none
-
-Encoding considerations:
-
-IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS
-contain binary data (for example attribute value lengths).
-
-Security considerations:
-
-IPP/1.1 protocol requests/responses do not introduce any security risks
-not already inherent in the underlying transport protocols. Protocol
-mixed-version interworking rules in [ipp-mod] as well as protocol
-encoding rules in [ipp-pro] are complete and unambiguous.
-
-Interoperability considerations:
-
-IPP/1.1 requests (generated by clients) and responses (generated by
-servers) MUST comply with all conformance requirements imposed by the
-normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding
-rules specified in [ipp-pro] are comprehensive, so that interoperability
-between conforming implementations is guaranteed (although support for
-specific optional features is not ensured). Both the "charset" and
-"natural-language" of all IPP/1.1 attribute values which are a
-LOCALIZED-STRING are explicit within IPP protocol requests/responses
-(without recourse to any external information in HTTP, SMTP, or other
-message transport headers).
-
-Published specifications:
-
-[ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R.,
- Powell, P., "Internet Printing Protocol/1.1: Model and
- Semantics" draft-ietf-ipp-model-v11-07.txt, May 22, 2000.
-
-[ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R.,
- "Internet Printing Protocol/1.1: Encoding and Transport", draft-
- ietf-ipp-protocol-v11-06.txt, May 30, 2000.
-
-Applications which use this media type:
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 43]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-Internet Printing Protocol (IPP) print clients and print servers,
-communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other
-transport protocol. Messages of type "application/ipp" are self-
-contained and transport-independent, including "charset" and "natural-
-language" context for any LOCALIZED-STRING value.
-
-Person & email address to contact for further information:
-
-Tom Hastings
-Xerox Corporation
- 737 Hawaii St. ESAE-231
-El Segundo, CA
-
-Phone: 310-333-6413
-Fax: 310-333-5514
-Email: hastings@cp10.es.xerox.com
-
-or
-
-Robert Herriot
-Xerox Corporation
-3400 Hillview Ave., Bldg #1
-Palo Alto, CA 94304
-
-Phone: 650-813-7696
-Fax: 650-813-6860
-Email: robert.herriot@pahv.xerox.com
-
-Intended usage:
-
-COMMON
-
-
-15. Appendix C: Changes from IPP/1.0
-
-IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
-
-1.Attributes values that identify a printer or job object use a new
- 'ipp' scheme. The 'http' and 'https' schemes are supported only for
- backward compatibility. See section 5.
-
-2.Clients MUST support of Digest Authentication, IPP Printers SHOULD
- support Digest Authentication. See Section 8.1.1
-
-3.TLS is recommended for channel security. In addition, SSL3 may be
- supported for backward compatibility. See Section 8.1.2
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 44]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-4.It is recommended that IPP/1.1 objects accept any request with major
- version number '1'. See section 9.1.
-
-5.IPP objects SHOULD return the URL scheme requested for "job-printer-
- uri" and "job-uri" Job Attributes, rather than the URL scheme used to
- create the job. See section 9.2.
-
-6.The IANA and Internationalization sections have been added. The
- terms "private use" and "experimental" have been changed to "vendor
- extension". The reserved allocations for attribute group tags,
- attribute syntax tags, and out-of-band attribute values have been
- clarified as to which are reserved to future IETF standards track
- documents and which are reserved to vendor extension. Both kinds of
- extensions use the type2 registration procedures as defined in [ipp-
- mod].
-
-7.Clarified that future "out-of-band" value definitions may use the
- value field if additional information is needed.
-
-
-16. Full Copyright Statement
-
-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.
-
-Copyright (C) The Internet Society (2000). 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,
-
-
-Herriot, et al. Expires November 30, 2000 [Page 45]
-\f
-
-INTERNET-DRAFT IPP/1.1: Encoding and Transport May 30, 2000
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herriot, et al. Expires November 30, 2000 [Page 46]
--- /dev/null
+
+
+Internet Printing Protocol Working Group Bob Herriot
+INTERNET DRAFT Xerox Corporation
+Expires 13 August 2001 Ira McDonald
+ High North Inc
+[Target Category: Standards Track] 13 February 2001
+
+ Internet Printing Protocol (IPP):
+ IPP URL Scheme
+ <draft-ietf-ipp-url-scheme-02.txt>
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+ This document is a product of the Internet Printing Protocol Working
+ Group of the Internet Engineering Task Force (IETF). Comments should
+ be submitted to the ipp@pwg.org mailing list.
+
+ This document is intended for use in registering the "ipp" URL scheme
+ with IANA and fully conforms to the requirements in [RFC-2717]. This
+ document defines the "ipp" URL (Uniform Resource Locator) scheme for
+ specifying the location of an IPP Printer, IPP Job, or other IPP
+ object (defined in some future version of IPP) which implements the
+ IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP
+ [RFC-2910] or any later version of IPP. The intended usage of the
+ "ipp" URL scheme is COMMON.
+
+ The IPP URL scheme defined in this document is based on the ABNF for
+ the HTTP URL scheme defined in HTTP/1.1 [RFC-2616], which is derived
+ from the URI Generic Syntax [RFC-2396] and further updated by
+ [RFC-2732] and [RFC-2373] (for IPv6 addresses in URLs). An IPP URL
+ is transformed into an HTTP URL according to the rules specified in
+ section 5 of the IPP/1.1 Protocol [RFC-2910].
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 1]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+ Table of Contents
+
+1. Introduction ............................................... 3
+2. Terminology ................................................ 4
+ 2.1. Conformance Terminology ................................ 4
+ 2.2. Model Terminology ...................................... 4
+3. IPP Model for Printers and Jobs ............................ 4
+4. IPP URL Scheme ............................................. 6
+ 4.1. IPP URL Scheme Applicability and Intended Usage ........ 6
+ 4.2. IPP URL Scheme Associated IPP Port ..................... 6
+ 4.3. IPP URL Scheme Associated MIME Type .................... 6
+ 4.4. IPP URL Scheme Character Encoding ...................... 6
+ 4.5. IPP URL Scheme Syntax in ABNF .......................... 7
+ 4.5.1. IPP URL Examples ................................... 8
+ 4.5.2. IPP URL Comparisons ................................ 9
+5. Conformance Requirements ................................... 10
+ 5.1. Conformance Requirements for IPP Clients ............... 10
+ 5.2. Conformance Requirements for IPP Printers .............. 10
+6. IANA Considerations ........................................ 11
+7. Internationalization Considerations ........................ 11
+8. Security Considerations .................................... 11
+9. References ................................................. 12
+10. Acknowledgments ........................................... 13
+11. Authors' Addresses ........................................ 14
+12. Appendix X - Change History ............................... 14
+13. Full Copyright Statement .................................. 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 2]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+
+1. Introduction
+
+ See section 1 'Introduction' in [RFC-2911] for a full description of
+ the IPP document set and overview information about IPP.
+
+ The open issues in this document each begin 'ISSUE_n:'.
+
+ This document is a product of the Internet Printing Protocol Working
+ Group of the Internet Engineering Task Force (IETF). Comments should
+ be submitted to the ipp@pwg.org mailing list.
+
+ This document is intended for use in registering the "ipp" URL scheme
+ with IANA and fully conforms to the requirements in [RFC-2717]. This
+ document defines the "ipp" URL (Uniform Resource Locator) scheme for
+ specifying the location of an IPP Printer, IPP Job, or other IPP
+ object (defined in some future version of IPP) which implements the
+ IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP
+ [RFC-2910] or any later version of IPP. The intended usage of the
+ "ipp" URL scheme is COMMON.
+
+ This document defines:
+ - IPP URL scheme applicability and intended usage;
+ - IPP URL scheme associated port (i.e., well-known port 631);
+ - IPP URL scheme associated MIME type (i.e., "application/ipp");
+ - IPP URL scheme syntax in ABNF [RFC-2234];
+ - IPP URL scheme character encoding;
+ - IPP URL scheme IANA, internationalization, and security
+ considerations.
+
+ This document is laid out as follows:
+ - Section 2 is the terminology used throughout the document.
+
+ - Section 3 provides references to the IPP Printer and IPP Job object
+ model.
+
+ - Section 4 specifies IPP URL scheme.
+
+ - Section 5 specifies the conformance requirements for IPP Clients
+ and IPP Printers that claim conformance to this document.
+
+ - Section 6, 7, and 8 specify IANA, internationalization, and
+ security considerations.
+
+ - Sections 9, 10, 11, 12, and 13 list references, acknowledgements,
+ authors' addresses, change history, and full IETF copyright
+ statement.
+
+
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 3]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+
+2. Terminology
+
+ This specification document uses the terminology defined in this
+ section.
+
+
+ 2.1. Conformance Terminology
+
+ The uppercase terms "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+ this document are to be interpreted as described in [RFC-2119].
+ These terms are used to specify conformance requirements for all
+ implementations of this specification.
+
+
+ 2.2. Model Terminology
+
+ See section 12.2 'Model Terminology' in [RFC-2911].
+
+
+
+3. IPP Model for Printers and Jobs
+
+ See section 2 'IPP Objects', section 2.1 'Printer Object', and
+ section 2.2 'Job Object' in [RFC-2911] for a full description of the
+ IPP object model and terminology.
+
+ In this document, "IPP Client" means the software (on some hardware
+ platform) that submits, monitors, and/or manages print jobs via
+ IPP/1.1 [RFC-2910] [RFC-2911], or any later version of IPP to a
+ spooler, gateway, or actual printing device.
+
+ In this document, "IPP Printer object" means the software (on some
+ hardware platform) that receives print jobs and/or printer/job
+ operations via IPP/1.1 [RFC-2910] [RFC-2911], or any later version of
+ IPP from an "IPP Client".
+
+ In this document, "IPP Printer" is a synonym for "IPP Printer
+ object".
+
+ In this document, "IPP Job object" means the set of attributes and
+ documents for one print job on an "IPP Printer".
+
+ In this document, "IPP Job" is a synonym for "IPP Job object".
+
+ In this document, "IPP URL" means a URL with the "ipp" scheme.
+
+ Note: In this document, "IPP URL" is a synonym for "ipp_URL" (in
+ section 4 'IPP URL Scheme' of this document) and "ipp-URL" (in
+
+Herriot, McDonald Expires 13 August 2001 [Page 4]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+ section 5 'IPP URL Scheme' of [RFC-2910]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 5]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+
+4. IPP URL Scheme
+
+
+
+ 4.1. IPP URL Scheme Applicability and Intended Usage
+
+ This document is intended for use in registering the "ipp" URL scheme
+ with IANA and fully conforms to the requirements in [RFC-2717]. This
+ document defines the "ipp" URL (Uniform Resource Locator) scheme for
+ specifying the location of an IPP Printer, IPP Job, or other IPP
+ object (defined in some future version of IPP) which implements the
+ IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP
+ [RFC-2910] or any later version of IPP. The intended usage of the
+ "ipp" URL scheme is COMMON.
+
+
+
+ 4.2. IPP URL Scheme Associated IPP Port
+
+ All IPP URLs which do NOT explicitly specify a port MUST be used over
+ IANA-assigned well-known port 631 for the IPP protocol described in
+ [RFC-2910].
+
+ See: IANA Port Numbers Registry [IANA-PORTREG]. registration with
+ IANA.
+
+
+
+ 4.3. IPP URL Scheme Associated MIME Type
+
+ All IPP protocol operations (requests and responses) MUST be conveyed
+ in an "application/ipp" MIME media type as registered in
+ [IANA-MIMEREG]. IPP URLs MUST refer to IPP Printers which support
+ this "application/ipp" MIME media type.
+
+ See: IANA MIME Media Types Registry [IANA-MIMEREG].
+
+
+
+ 4.4. IPP URL Scheme Character Encoding
+
+ The IPP URL scheme defined in this document is based on the ABNF for
+ the HTTP URL scheme defined in HTTP/1.1 [RFC-2616], which is derived
+ from the URI Generic Syntax [RFC-2396] and further updated by
+ [RFC-2732] and [RFC-2373] (for IPv6 addresses in URLs). The IPP URL
+ scheme is case-insensitive in the host name or host address part;
+ however the path part is case-sensitive, as in [RFC-2396].
+ Codepoints outside [US-ASCII] MUST be hex escaped by the mechanism
+ specified in [RFC-2396].
+
+Herriot, McDonald Expires 13 August 2001 [Page 6]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+
+
+ 4.5. IPP URL Scheme Syntax in ABNF
+
+ Note: In this document, "IPP URL" is a synonym for "ipp_URL" (in
+ section 4 'IPP URL Scheme' of this document) and "ipp-URL" (in
+ section 5 'IPP URL Scheme' of [RFC-2910]).
+
+ This document is intended for use in registering the "ipp" URL scheme
+ with IANA and fully conforms to the requirements in [RFC-2717]. This
+ document defines the "ipp" URL (Uniform Resource Locator) scheme for
+ specifying the location of an IPP Printer, IPP Job, or other IPP
+ object (defined in some future version of IPP) which implements the
+ IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP
+ [RFC-2910] or any later version of IPP. The intended usage of the
+ "ipp" URL scheme is COMMON.
+
+ The IPP protocol places a limit of 1023 octets (NOT characters) on
+ the length of a URI (see section 4.1.5 'uri' in [RFC-2911]). An IPP
+ Printer MUST return 'client-error-request-value-too-long' (see
+ section 13.1.4.10 in [RFC-2911]) when a URI received in a request
+ (e.g., in the "printer-uri" attribute) is too long.
+
+ Note: IPP Printers ought to be cautious about depending on URI
+ lengths above 255 bytes, because some older client or proxy
+ implementations might not properly support these lengths.
+
+ IPP URLs MUST be represented in absolute form. Absolute URLs always
+ begin with a scheme name followed by a colon. For definitive
+ information on URL syntax and semantics, see "Uniform Resource
+ Identifiers (URI): Generic Syntax and Semantics" [RFC-2396]. This
+ specification adopts the definitions of "URI-reference",
+ "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path",
+ and "authority" from [RFC-2396], as updated by [RFC-2732] and
+ [RFC-2373] (for IPv6 addresses in URLs).
+
+ The IPP URL scheme syntax in ABNF is as follows:
+
+ ipp_URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+
+ If the port is empty or not given, port 631 is assumed. The
+ semantics are that the identified resource (see section 5.1.2 of
+ [RFC-2616]) is located at the IPP Printer or IPP Job listening for
+ HTTP connections on that port of that host, and the Request-URI for
+ the identified resource is 'abs_path'.
+
+ Note: The use of IP addresses in URLs SHOULD be avoided whenever
+ possible (see [RFC-1900]).
+
+ If the 'abs_path' is not present in the URL, it MUST be given as "/"
+
+Herriot, McDonald Expires 13 August 2001 [Page 7]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+ when used as a Request-URI for a resource (see section 5.1.2 of
+ [RFC-2616]). If a proxy receives a host name which is not a fully
+ qualified domain name, it MAY add its domain to the host name it
+ received. If a proxy receives a fully qualified domain name, the
+ proxy MUST NOT change the host name.
+
+
+
+ 4.5.1. IPP URL Examples
+
+ The following are examples of valid IPP URLs for IPP Printers:
+
+ ipp://abc.com
+ ipp://abc.com/printer
+ ipp://abc.com/tiger
+ ipp://abc.com/printers/tiger
+ ipp://abc.com/printers/fox
+ ipp://abc.com/printers/tiger/bob
+ ipp://abc.com/printers/tiger/ira
+ ipp://printer.abc.com
+ ipp://printers.abc.com/tiger
+ ipp://printers.abc.com/tiger/bob
+ ipp://printers.abc.com/tiger/ira
+
+ Each of the above URLs are legitimate URLs for IPP Printers and each
+ references a logically different IPP Printer, even though some of the
+ IPP Printers may share the same hardware. The last part of the path
+ 'bob' or 'ira' may represent two different hardware devices where
+ 'tiger' represents some grouping of IPP Printers (e.g., a
+ load-balancing spooler) or the two names may represent separate human
+ recipients ('bob' and 'ira') on the same hardware device (e.g., a
+ printer supporting two job queues). In either case both 'bob' and
+ 'ira' behave as different IPP Printers.
+
+ The following are examples of IPP URLs with (optional) ports and
+ paths:
+
+ ipp://abc.com
+ ipp://abc.com/~smith/printer
+ ipp://abc.com:631/~smith/printer
+
+ The first and second IPP URLs above MUST be resolved to port 631
+ (IANA assigned well-known port for IPP). The second and third IPP
+ URLs above are equivalent (see section 4.5.2 below).
+
+ Note: The use of IP addresses in URLs SHOULD be avoided whenever
+ possible (see [RFC-1900]).
+
+ The following literal IPv4 addresses:
+
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 8]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+ 192.9.5.5 ; IPv4 address in IPv4 style
+ 186.7.8.9 ; IPv4 address in IPv4 style
+
+ are represented in the following example IPP URLs:
+
+ ipp://192.9.5.5/prt1
+ ipp://186.7.8.9/printers/tiger/bob
+
+ The following literal IPv6 addresses (conformant to [RFC-2373]):
+
+ ::192.9.5.5 ; IPv4 address in IPv6 style
+ ::FFFF:129.144.52.38 ; IPv4 address in IPv6 style
+ 2010:836B:4179::836B:4179 ; IPv6 address per RFC 2373
+
+ are represented in the following example IPP URLs:
+
+ ipp://[::192.9.5.5]/prt1
+ ipp://[::FFFF:129.144.52.38]:631/printers/tiger
+ ipp://[2010:836B:4179::836B:4179]/printers/tiger/bob
+
+
+
+ 4.5.2. IPP URL Comparisons
+
+ When comparing two IPP URLs to decide if they match or not, an IPP
+ Client SHOULD use a case-sensitive octet-by-octet comparison of the
+ entire URLs, with these exceptions:
+
+ - A port that is empty or not given is equivalent to the well-known
+ port for that IPP URL (port 631);
+
+ - Comparisons of host names MUST be case-insensitive;
+
+ - Comparisons of scheme names MUST be case-insensitive;
+
+ - An empty 'abs_path' is equivalent to an 'abs_path' of "/".
+
+ Characters other than those in the "reserved" and "unsafe" sets (see
+ [RFC-2396] and [RFC-2732]) are equivalent to their ""%" HEX HEX"
+ encoding.
+
+ For example, the following three URIs are equivalent:
+
+ ipp://abc.com:631/~smith/printer
+ ipp://ABC.com/%7Esmith/printer
+ ipp://ABC.com:/%7esmith/printer
+
+
+
+
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 9]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+
+5. Conformance Requirements
+
+
+
+ 5.1. Conformance Requirements for IPP Clients
+
+ IPP Clients that conform to this specification:
+
+ a) MUST send IPP URLs (e.g., in the "printer-uri" operation attribute
+ in 'Print-Job') that conform to the ABNF specified in section 4.5
+ of this document;
+
+ b) MUST send IPP operations via the port specified in the IPP URL (if
+ present) or otherwise via IANA assigned well-known port 631;
+
+ c) MUST convert IPP URLs to their corresponding HTTP URL forms
+ according to the rules in section 5 'IPP URL Scheme' in
+ [RFC-2910];
+
+ d) SHOULD interoperate with IPP/1.0 Printers according to the rules
+ in section 9 'Interoperability with IPP/1.0 Implementations' and
+ section 9.2 'Security and URL Schemes' in [RFC-2910].
+
+
+
+ 5.2. Conformance Requirements for IPP Printers
+
+ IPP Printers that conform to this specification:
+
+ a) SHOULD reject received IPP URLs in "application/ipp" request
+ bodies (e.g., in the "printer-uri" attribute in a 'Print-Job'
+ request) that do not conform to the ABNF for IPP URLs specified in
+ section 4.5 of this document;
+
+ b) SHOULD return IPP URLs in "application/ipp" response bodies (e.g.,
+ in the "job-uri" attribute in a 'Print-Job' response) that do
+ conform to the ABNF for IPP URLs specified in section 4.5 of this
+ document;
+
+ c) MUST listen for IPP operations on IANA-assigned well-known port
+ 631, unless explicitly configured by system administrators or site
+ policies;
+
+ d) SHOULD NOT listen for IPP operations on any other port, unless
+ explicitly configured by system administrators or site policies;
+
+ e) SHOULD interoperate with IPP/1.0 Clients according to the rules in
+ section 9 'Interoperability with IPP/1.0 Implementations' and
+ section 9.2 'Security and URL Schemes' in [RFC-2910].
+
+Herriot, McDonald Expires 13 August 2001 [Page 10]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+
+6. IANA Considerations
+
+ This document is intended for use in registering the "ipp" URL scheme
+ with IANA and fully conforms to the requirements in [RFC-2717]. This
+ document defines the "ipp" URL (Uniform Resource Locator) scheme for
+ specifying the location of an IPP Printer, IPP Job, or other IPP
+ object (defined in some future version of IPP) which implements the
+ IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP
+ [RFC-2910] or any later version of IPP. The intended usage of the
+ "ipp" URL scheme is COMMON.
+
+ This IPP URL Scheme specification does not introduce any additional
+ IANA considerations, beyond those described in [RFC-2910] and
+ [RFC-2911].
+
+ See: Section 6 'IANA Considerations' in [RFC-2910]
+ See: Section 6 'IANA Considerations' in [RFC-2911].
+
+
+
+7. Internationalization Considerations
+
+ This IPP URL Scheme specification does not introduce any additional
+ internationalization considerations, beyond those described in
+ [RFC-2910] and [RFC-2911].
+
+ See: Section 7 'Internationalization Considerations' in [RFC-2910].
+ See: Section 7 'Internationalization Considerations' in [RFC-2911].
+
+
+
+8. Security Considerations
+
+ This IPP URL Scheme specification does not introduce any additional
+ security considerations, beyond those described in [RFC-2910] and
+ [RFC-2911].
+
+ See: Section 8 'Security Considerations' in [RFC-2910].
+ See: Section 8 'Security Considerations' in [RFC-2911].
+
+
+
+
+
+
+
+
+
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 11]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+
+9. References
+
+ See: Section 10 'References' in [RFC-2910].
+ See: Section 9 'References' in [RFC-2911].
+
+ [IANA-CHARREG] IANA Charset Registry.
+ ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets
+
+ [IANA-MIMEREG] IANA MIME Media Types Registry.
+ ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/...
+
+ [IANA-PORTREG] IANA Port Numbers Registry.
+ ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
+
+ [NET-SSL3] Netscape. The SSL Protocol, Version 3 (text version
+ 3.02), November 1996.
+
+ [RFC-1759] R. Smith, F. Wright, T. Hastings, S. Zilles,
+ J. Gyllenskog. Printer MIB, RFC 1759, March 1995.
+
+ [RFC-1900] B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC
+ 1900, February 1996.
+
+ [RFC-2046] N. Freed, N. Borenstein. MIME Part Two: Media Types, RFC
+ 2046, November 1996.
+
+ [RFC-2048] N. Freed, J. Klensin, J. Postel. MIME Part
+ Four: Registration Procedures, RFC 2048, November 1996.
+
+ [RFC-2234] D. Crocker, P. Overell. Augmented BNF for Syntax
+ Specifications: ABNF, RFC 2234, November 1997.
+
+ [RFC-2373] R. Hinden, S. Deering. IP Version 6 Addressing
+ Architecture, RFC 2373, July 1998.
+
+ [RFC-2396] T. Berners-Lee, R. Fielding, L. Masinter. Uniform
+ Resource Identifiers (URI): Generic Syntax, RFC 2396, August 1998.
+
+ [RFC-2246] T. Dierks, C. Allen. The TLS Protocol Version, RFC 2246,
+ January 1999.
+
+ [RFC-2277] H. Alvestrand. IETF Policy on Character Sets and
+ Languages, RFC 2277, January 1998.
+
+ [RFC-2279] F. Yergeau. UTF-8, a Transformation Format of ISO 10646,
+ RFC 2279, January 1998.
+
+ [RFC-2565] R. Herriot, S. Butler, P. Moore, R. Turner. IPP/1.0
+ Encoding and Transport, RFC 2565, April 1999 (Experimental).
+
+Herriot, McDonald Expires 13 August 2001 [Page 12]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+
+ [RFC-2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell.
+ IPP/1.0 Model and Semantics, RFC 2566, April 1999 (Experimental).
+
+ [RFC-2579] K. McCloghrie, D. Perkins, J. Schoenwaelder. Textual
+ Conventions for SMIv2, RFC 2579, April 1999.
+
+ [RFC-2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
+ P. Leach, T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1,
+ RFC 2616, June 1999.
+
+ [RFC-2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence,
+ P. Leach, A. Luotonen, L. Stewart. HTTP Authentication: Basic and
+ Digest Access Authentication, RFC 2617, June 1999.
+
+ [RFC-2717] R. Petke, I. King. Registration Procedures for URL Scheme
+ Names, RFC 2717, November 1999.
+
+ [RFC-2718] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke.
+ Guidelines for new URL Scheme Names, RFC 2718, November 1999.
+
+ [RFC-2732] R. Hinden,B. Carpenter, L. Masinter. Format for Literal
+ IPv6 Addresses in URL's, RFC 2732, December 1999.
+
+ [RFC-2910] R. Herriot, S. Butler, P. Moore, R. Turner, J. Wenn.
+ IPP/1.1 Encoding and Transport, RFC 2910, September 2000.
+
+ [RFC-2911] T. Hastings, R. Herriot, R. deBry, S. Isaacson, P. Powell.
+ IPP/1.1 Model and Semantics, RFC 2911, September 2000.
+
+ [RFC-2978] N. Freed, J. Postel. IANA Charset Registration
+ Procedures, RFC 2978, October 2000.
+
+ [RFC-3066] H. Alvestrand. Tags for the Identification of Languages,
+ RFC 3066, January 2001.
+
+ [US-ASCII] Coded Character Set -- 7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+
+
+10. Acknowledgments
+
+ This document is a product of the Internet Printing Protocol Working
+ Group of the Internet Engineering Task Force (IETF). Comments should
+ be submitted to the ipp@pwg.org mailing list.
+
+ Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM),
+ and Hugo Parra (Novell).
+
+ Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport
+
+Herriot, McDonald Expires 13 August 2001 [Page 13]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+ [RFC-2910] was the primary input to this IPP URL Scheme
+ specification.
+
+
+
+11. Authors' Addresses
+
+ Robert Herriot
+ Xerox Corporation
+ 3400 Hill View Ave, Building 1
+ Palo Alto, CA 94304
+
+ Phone: +1 650-813-7696
+ Fax: +1 650-813-6860
+ Email: robert.herriot@pahv.xerox.com
+
+
+ Ira McDonald
+ High North Inc
+ 221 Ridge Ave
+ Grand Marais, MI 49839
+
+ Phone: +1 906-494-2434
+ Email: imcdonald@crt.xerox.com
+ Email: imcdonald@sharplabs.com
+
+
+
+12. Appendix X - Change History
+
+ [To be deleted before RFC publication]
+
+ 13 February 2001 - draft-ietf-ipp-url-scheme-02.txt
+ - revised section 3 'IPP Model for Printers and Jobs' and section 4.5
+ 'IPP URL Scheme Syntax in ABNF' to add notes stating that "IPP URL"
+ (in this document) is a synonym for "ipp-URL" in [RFC-2910], per
+ request of Bob Herriot;
+ - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to correct typo
+ that showed "http:" rather than "ipp:" in the one-line ABNF, per
+ request of Tom Hastings;
+ - revised section 4.5.1 'IPP URL Examples' to add a note discouraging
+ the use of literal IP addresses in URLs, per [RFC-2616] and
+ [RFC-1900];
+
+ 5 February 2001 - draft-ietf-ipp-url-scheme-01.txt
+ - revised section 4.1 'IPP URL Applicability and Intended Usage' to
+ clarify that a given IPP URL MAY identify an IPP Printer object or
+ an IPP Job object, per request of Tom Hastings;
+ - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to define IPP
+ URLs consistently with section 3.2.2 'http URL' of HTTP/1.1
+ [RFC-2616], per request of Tom Hastings;
+
+Herriot, McDonald Expires 13 August 2001 [Page 14]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+ - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to clarify that
+ IPP URLs may reference IPP Printer objects, IPP Job objects, or
+ (possibly other future) IPP objects, per request of Bob Herriot;
+ - added section 4.5.1 'IPP URL Examples' to supply meaningful
+ examples of IPP URLs with host names, IPv4 addresses, and IPv6
+ addresses, per request of Tom Hastings;
+ - added section 4.5.2 'IPP URL Comparisons' to define IPP URL
+ comparisons consistently with section 3.3 'URI Comparison' of
+ HTTP/1.1 [RFC-2616], per request of Tom Hastings;
+ - revised section 5.1 'Conformance Requirements for IPP Clients' to
+ clarify that an IPP Client MUST convert IPP URLs to their
+ corresponding HTTP URL forms according to section 5 'IPP URL
+ Scheme' in [RFC-2910], per request of Tom Hastings and Bob Herriot;
+ - revised section 5.1 'Conformance Requirements for IPP Clients' and
+ section 5.2 'Conformance Requirements for IPP Printers' to clarify
+ that IPP Clients and IPP Printers SHOULD interoperate with IPP/1.0
+ systems according to section 9 'Interoperability with IPP/1.0
+ Implementations' in [RFC-2910], per request of Carl Kugler;
+ - revised section 5.2 'Conformance Requirements for IPP Printers' to
+ clarify that an IPP Printer MUST listen on (IANA assigned
+ well-known) port 631, unless explicitly configured, per request of
+ Michael Sweet;
+ - revised section 5.2 'Conformance Requirements for IPP Printers' to
+ clarify that an IPP Printer SHOULD NOT listen on ports other than
+ (IANA assigned well-known) port 631, unless explicitly configured,
+ per request of Don Wright;
+ - revised section 6 'IANA Considerations' to clarify that the sole
+ purpose of the entire document is IANA registration of the "ipp"
+ URL scheme;
+ - deleted Appendix A 'Registration of IPP Port' as unnecessary (port
+ is already registered);
+ - deleted Appendix B 'Registration of MIME "application/ipp" as
+ unnecessary (MIME registry has recently caught up to RFC 2910);
+
+ 11 January 2001 - draft-ietf-ipp-url-scheme-00.txt
+ - initial version - simple "ipp" URL scheme without parameters or
+ query part (consistent with existing and IPP/1.1 implementations);
+ - added Appendix A 'Registration of IPP Port' (placeholder) for
+ updated IANA registration of port 631 with references to IPP/1.1;
+ - added Appendix B 'Registration of MIME "application/ipp"' with
+ updated IANA registration for IPP MIME type with references to both
+ IPP/1.0 and IPP/1.1;
+
+
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+
+Herriot, McDonald Expires 13 August 2001 [Page 15]
+\f
+Internet Draft IPP URL Scheme 13 February 2001
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, McDonald Expires 13 August 2001 [Page 16]
--- /dev/null
+\r
+\r
+\r
+\r
+\r
+\r
+Network Working Group R. Herriot, Editor\r
+Request for Comments: 2910 Xerox Corporation\r
+Obsoletes: 2565 S. Butler\r
+Category: Standards Track Hewlett-Packard\r
+ P. Moore\r
+ Peerless Systems Networking\r
+ R. Turner\r
+ 2wire.com\r
+ J. Wenn\r
+ Xerox Corporation\r
+ September 2000\r
+\r
+\r
+ Internet Printing Protocol/1.1: Encoding and Transport\r
+\r
+Status of this Memo\r
+\r
+ This document specifies an Internet standards track protocol for the\r
+ Internet community, and requests discussion and suggestions for\r
+ improvements. Please refer to the current edition of the "Internet\r
+ Official Protocol Standards" (STD 1) for the standardization state\r
+ and status of this protocol. Distribution of this memo is unlimited.\r
+\r
+Copyright Notice\r
+\r
+ Copyright (C) The Internet Society (2000). All Rights Reserved.\r
+\r
+Abstract\r
+\r
+ This document is one of a set of documents, which together describe\r
+ all aspects of a new Internet Printing Protocol (IPP). IPP is an\r
+ application level protocol that can be used for distributed printing\r
+ using Internet tools and technologies. This document defines the\r
+ rules for encoding IPP operations and IPP attributes into a new\r
+ Internet mime media type called "application/ipp". This document\r
+ also defines the rules for transporting over Hypertext Transfer\r
+ Protocol (HTTP) a message body whose Content-Type is\r
+ "application/ipp". This document defines a new scheme named 'ipp' for\r
+ identifying IPP printers and jobs.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 1]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ The full set of IPP documents includes:\r
+\r
+ Design Goals for an Internet Printing Protocol [RFC2567]\r
+ Rationale for the Structure and Model and Protocol for the Internet\r
+ Printing Protocol [RFC2568]\r
+ Internet Printing Protocol/1.1: Model and Semantics [RFC2911]\r
+ Internet Printing Protocol/1.1: Encoding and Transport (this\r
+ document)\r
+ Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]\r
+ Mapping between LPD and IPP Protocols [RFC2569]\r
+\r
+ The document, "Design Goals for an Internet Printing Protocol", takes\r
+ a broad look at distributed printing functionality, and it enumerates\r
+ real-life scenarios that help to clarify the features that need to be\r
+ included in a printing protocol for the Internet. It identifies\r
+ requirements for three types of users: end users, operators, and\r
+ administrators. It calls out a subset of end user requirements that\r
+ are satisfied in IPP/1.1. A few OPTIONAL operator operations have\r
+ been added to IPP/1.1.\r
+\r
+ The document, "Rationale for the Structure and Model and Protocol for\r
+ the Internet Printing Protocol", describes IPP from a high level\r
+ view, defines a roadmap for the various documents that form the suite\r
+ of IPP specification documents, and gives background and rationale\r
+ for the IETF working group's major decisions.\r
+\r
+ The document, "Internet Printing Protocol/1.1: Model and Semantics",\r
+ describes a simplified model with abstract objects, their attributes,\r
+ and their operations that are independent of encoding and transport.\r
+ It introduces a Printer and a Job object. The Job object optionally\r
+ supports multiple documents per Job. It also addresses security,\r
+ internationalization, and directory issues.\r
+\r
+ The document "Internet Printing Protocol/1.1: Implementer's Guide",\r
+ gives advice to implementers of IPP clients and IPP objects.\r
+\r
+ The document "Mapping between LPD and IPP Protocols", gives some\r
+ advice to implementers of gateways between IPP and LPD (Line Printer\r
+ Daemon) implementations.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 2]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+Table of Contents\r
+\r
+ 1. Introduction ...................................................4\r
+ 2. Conformance Terminology ........................................4\r
+ 3. Encoding of the Operation Layer ...............................4\r
+ 3.1 Picture of the Encoding ...................................6\r
+ 3.1.1 Request and Response...................................6\r
+ 3.1.2 Attribute Group........................................6\r
+ 3.1.3 Attribute..............................................7\r
+ 3.1.4 Picture of the Encoding of an Attribute-with-one-value.7\r
+ 3.1.5 Additional-value.......................................8\r
+ 3.1.6 Alternative Picture of the Encoding of a Request Or a\r
+ Response...............................................9\r
+ 3.2 Syntax of Encoding ........................................9\r
+ 3.3 Attribute-group ..........................................11\r
+ 3.4 Required Parameters ......................................12\r
+ 3.4.1 Version-number........................................12\r
+ 3.4.2 Operation-id..........................................12\r
+ 3.4.3 Status-code...........................................12\r
+ 3.4.4 Request-id............................................13\r
+ 3.5 Tags .....................................................13\r
+ 3.5.1 Delimiter Tags........................................13\r
+ 3.5.2 Value Tags............................................14\r
+ 3.6 Name-Length ..............................................16\r
+ 3.7 (Attribute) Name .........................................16\r
+ 3.8 Value Length .............................................16\r
+ 3.9 (Attribute) Value ........................................17\r
+ 3.10 Data .....................................................18\r
+ 4. Encoding of Transport Layer ...................................18\r
+ 4.1 Printer-uri and job-uri ..................................19\r
+ 5. IPP URL Scheme ................................................20\r
+ 6. IANA Considerations ...........................................22\r
+ 7. Internationalization Considerations ...........................23\r
+ 8. Security Considerations .......................................23\r
+ 8.1 Security Conformance Requirements ........................23\r
+ 8.1.1 Digest Authentication.................................23\r
+ 8.1.2 Transport Layer Security (TLS)........................24\r
+ 8.2 Using IPP with TLS .......................................25\r
+ 9. Interoperability with IPP/1.0 Implementations .................25\r
+ 9.1 The "version-number" Parameter ...........................25\r
+ 9.2 Security and URL Schemes .................................26\r
+ 10. References ...................................................27\r
+ 11. Authors' Addresses ...........................................29\r
+ 12. Other Participants: ..........................................31\r
+ 13. Appendix A: Protocol Examples ................................33\r
+ 13.1 Print-Job Request ........................................33\r
+ 13.2 Print-Job Response (successful) ..........................34\r
+ 13.3 Print-Job Response (failure) .............................35\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 3]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ 13.4 Print-Job Response (success with attributes ignored) .....36\r
+ 13.5 Print-URI Request ........................................38\r
+ 13.6 Create-Job Request .......................................39\r
+ 13.7 Get-Jobs Request .........................................40\r
+ 13.8 Get-Jobs Response ........................................41\r
+ 14. Appendix B: Registration of MIME Media Type Information for\r
+ "application/ipp".............................................42\r
+ 15. Appendix C: Changes from IPP/1.0 .............................44\r
+ 16. Full Copyright Statement .....................................45\r
+\r
+1. Introduction\r
+\r
+ This document contains the rules for encoding IPP operations and\r
+ describes two layers: the transport layer and the operation layer.\r
+\r
+ The transport layer consists of an HTTP/1.1 request or response. RFC\r
+ 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP\r
+ headers that an IPP implementation supports.\r
+\r
+ The operation layer consists of a message body in an HTTP request or\r
+ response. The document "Internet Printing Protocol/1.1: Model and\r
+ Semantics" [RFC2911] defines the semantics of such a message body and\r
+ the supported values. This document specifies the encoding of an IPP\r
+ operation. The aforementioned document [RFC2911] is henceforth\r
+ referred to as the "IPP model document" or simply "model document".\r
+\r
+ Note: the version number of IPP (1.1) and HTTP (1.1) are not linked.\r
+ They both just happen to be 1.1.\r
+\r
+2. Conformance Terminology\r
+\r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",\r
+ "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be\r
+ interpreted as described in RFC 2119 [RFC2119].\r
+\r
+3. Encoding of the Operation Layer\r
+\r
+ The operation layer is the message body part of the HTTP request or\r
+ response and it MUST contain a single IPP operation request or IPP\r
+ operation response. Each request or response consists of a sequence\r
+ of values and attribute groups. Attribute groups consist of a\r
+ sequence of attributes each of which is a name and value. Names and\r
+ values are ultimately sequences of octets.\r
+\r
+ The encoding consists of octets as the most primitive type. There are\r
+ several types built from octets, but three important types are\r
+ integers, character strings and octet strings, on which most other\r
+ data types are built. Every character string in this encoding MUST be\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 4]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ a sequence of characters where the characters are associated with\r
+ some charset and some natural language. A character string MUST be in\r
+ "reading order" with the first character in the value (according to\r
+ reading order) being the first character in the encoding. A character\r
+ string whose associated charset is US-ASCII whose associated natural\r
+ language is US English is henceforth called a US-ASCII-STRING. A\r
+ character string whose associated charset and natural language are\r
+ specified in a request or response as described in the model document\r
+ is henceforth called a LOCALIZED-STRING. An octet string MUST be in\r
+ "IPP model document order" with the first octet in the value\r
+ (according to the IPP model document order) being the first octet in\r
+ the encoding. Every integer in this encoding MUST be encoded as a\r
+ signed integer using two's-complement binary encoding with big-endian\r
+ format (also known as "network order" and "most significant byte\r
+ first"). The number of octets for an integer MUST be 1, 2 or 4,\r
+ depending on usage in the protocol. Such one-octet integers,\r
+ henceforth called SIGNED-BYTE, are used for the version-number and\r
+ tag fields. Such two-byte integers, henceforth called SIGNED-SHORT\r
+ are used for the operation-id, status-code and length fields. Four\r
+ byte integers, henceforth called SIGNED-INTEGER, are used for value\r
+ fields and the request-id.\r
+\r
+ The following two sections present the encoding of the operation\r
+ layer in two ways:\r
+\r
+ - informally through pictures and description\r
+ - formally through Augmented Backus-Naur Form (ABNF), as\r
+ specified by RFC 2234 [RFC2234]\r
+\r
+ An operation request or response MUST use the encoding described in\r
+ these two sections.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 5]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+3.1 Picture of the Encoding\r
+\r
+3.1.1 Request and Response\r
+\r
+ An operation request or response is encoded as follows:\r
+\r
+ -----------------------------------------------\r
+ | version-number | 2 bytes - required\r
+ -----------------------------------------------\r
+ | operation-id (request) |\r
+ | or | 2 bytes - required\r
+ | status-code (response) |\r
+ -----------------------------------------------\r
+ | request-id | 4 bytes - required\r
+ -----------------------------------------------\r
+ | attribute-group | n bytes - 0 or more\r
+ -----------------------------------------------\r
+ | end-of-attributes-tag | 1 byte - required\r
+ -----------------------------------------------\r
+ | data | q bytes - optional\r
+ -----------------------------------------------\r
+\r
+ The first three fields in the above diagram contain the value of\r
+ attributes described in section 3.1.1 of the Model document.\r
+\r
+ The fourth field is the "attribute-group" field, and it occurs 0 or\r
+ more times. Each "attribute-group" field represents a single group of\r
+ attributes, such as an Operation Attributes group or a Job Attributes\r
+ group (see the Model document). The IPP model document specifies the\r
+ required attribute groups and their order for each operation request\r
+ and response.\r
+\r
+ The "end-of-attributes-tag" field is always present, even when the\r
+ "data" is not present. The Model document specifies for each\r
+ operation request and response whether the "data" field is present or\r
+ absent.\r
+\r
+3.1.2 Attribute Group\r
+\r
+ Each "attribute-group" field is encoded as follows:\r
+\r
+ -----------------------------------------------\r
+ | begin-attribute-group-tag | 1 byte\r
+ ----------------------------------------------------------\r
+ | attribute | p bytes |- 0 or more\r
+ ----------------------------------------------------------\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 6]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ The "begin-attribute-group-tag" field marks the beginning of an\r
+ "attribute-group" field and its value identifies the type of\r
+ attribute group, e.g. Operations Attributes group versus a Job\r
+ Attributes group. The "begin-attribute-group-tag" field also marks\r
+ the end of the previous attribute group except for the "begin-\r
+ attribute-group-tag" field in the first "attribute-group" field of a\r
+ request or response. The "begin-attribute-group-tag" field acts as\r
+ an "attribute-group" terminator because an "attribute-group" field\r
+ cannot nest inside another "attribute-group" field.\r
+\r
+ An "attribute-group" field contains zero or more "attribute" fields.\r
+\r
+ Note, the values of the "begin-attribute-group-tag" field and the\r
+ "end-of-attributes-tag" field are called "delimiter-tags".\r
+\r
+3.1.3 Attribute\r
+\r
+ An "attribute" field is encoded as follows:\r
+\r
+ -----------------------------------------------\r
+ | attribute-with-one-value | q bytes\r
+ ----------------------------------------------------------\r
+ | additional-value | r bytes |- 0 or more\r
+ ----------------------------------------------------------\r
+\r
+ When an attribute is single valued (e.g. "copies" with value of 10)\r
+ or multi-valued with one value (e.g. "sides-supported" with just the\r
+ value 'one-sided') it is encoded with just an "attribute-with-one-\r
+ value" field. When an attribute is multi-valued with n values (e.g.\r
+ "sides-supported" with the values 'one-sided' and 'two-sided-long-\r
+ edge'), it is encoded with an "attribute-with-one-value" field\r
+ followed by n-1 "additional-value" fields.\r
+\r
+3.1.4 Picture of the Encoding of an Attribute-with-one-value\r
+\r
+ Each "attribute-with-one-value" field is encoded as follows:\r
+\r
+ -----------------------------------------------\r
+ | value-tag | 1 byte\r
+ -----------------------------------------------\r
+ | name-length (value is u) | 2 bytes\r
+ -----------------------------------------------\r
+ | name | u bytes\r
+ -----------------------------------------------\r
+ | value-length (value is v) | 2 bytes\r
+ -----------------------------------------------\r
+ | value | v bytes\r
+ -----------------------------------------------\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 7]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ An "attribute-with-one-value" field is encoded with five subfields:\r
+\r
+ The "value-tag" field specifies the attribute syntax, e.g. 0x44\r
+ for the attribute syntax 'keyword'.\r
+\r
+ The "name-length" field specifies the length of the "name" field\r
+ in bytes, e.g. u in the above diagram or 15 for the name "sides-\r
+ supported".\r
+\r
+ The "name" field contains the textual name of the attribute, e.g.\r
+ "sides-supported".\r
+\r
+ The "value-length" field specifies the length of the "value" field\r
+ in bytes, e.g. v in the above diagram or 9 for the (keyword) value\r
+ 'one-sided'.\r
+\r
+ The "value" field contains the value of the attribute, e.g. the\r
+ textual value 'one-sided'.\r
+\r
+3.1.5 Additional-value\r
+\r
+ Each "additional-value" field is encoded as follows:\r
+\r
+ -----------------------------------------------\r
+ | value-tag | 1 byte\r
+ -----------------------------------------------\r
+ | name-length (value is 0x0000) | 2 bytes\r
+ -----------------------------------------------\r
+ | value-length (value is w) | 2 bytes\r
+ -----------------------------------------------\r
+ | value | w bytes\r
+ -----------------------------------------------\r
+\r
+ An "additional-value" is encoded with four subfields:\r
+\r
+ The "value-tag" field specifies the attribute syntax, e.g. 0x44\r
+ for the attribute syntax 'keyword'.\r
+\r
+ The "name-length" field has the value of 0 in order to signify\r
+ that it is an "additional-value". The value of the "name-length"\r
+ field distinguishes an "additional-value" field ("name-length" is\r
+ 0) from an "attribute-with-one-value" field ("name-length" is not\r
+ 0).\r
+\r
+ The "value-length" field specifies the length of the "value" field\r
+ in bytes, e.g. w in the above diagram or 19 for the (keyword)\r
+ value 'two-sided-long-edge'.\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 8]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ The "value" field contains the value of the attribute, e.g. the\r
+ textual value 'two-sided-long-edge'.\r
+\r
+3.1.6 Alternative Picture of the Encoding of a Request Or a Response\r
+\r
+ From the standpoint of a parser that performs an action based on a\r
+ "tag" value, the encoding consists of:\r
+\r
+ -----------------------------------------------\r
+ | version-number | 2 bytes - required\r
+ -----------------------------------------------\r
+ | operation-id (request) |\r
+ | or | 2 bytes - required\r
+ | status-code (response) |\r
+ -----------------------------------------------\r
+ | request-id | 4 bytes - required\r
+ -----------------------------------------------------------\r
+ | tag (delimiter-tag or value-tag) | 1 byte |\r
+ ----------------------------------------------- |-0 or more\r
+ | empty or rest of attribute | x bytes |\r
+ -----------------------------------------------------------\r
+ | end-of-attributes-tag | 1 byte - required\r
+ -----------------------------------------------\r
+ | data | y bytes - optional\r
+ -----------------------------------------------\r
+\r
+ The following show what fields the parser would expect after each\r
+ type of "tag":\r
+\r
+ - "begin-attribute-group-tag": expect zero or more "attribute"\r
+ fields\r
+ - "value-tag": expect the remainder of an "attribute-with-one-\r
+ value" or an "additional-value".\r
+ - "end-of-attributes-tag": expect that "attribute" fields are\r
+ complete and there is optional "data"\r
+\r
+3.2 Syntax of Encoding\r
+\r
+ The syntax below is ABNF [RFC2234] except 'strings of literals' MUST\r
+ be case sensitive. For example 'a' means lower case 'a' and not\r
+ upper case 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields\r
+ are represented as '%x' values which show their range of values.\r
+\r
+ ipp-message = ipp-request / ipp-response\r
+ ipp-request = version-number operation-id request-id\r
+ *attribute-group end-of-attributes-tag data\r
+ ipp-response = version-number status-code request-id\r
+ *attribute-group end-of-attributes-tag data\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 9]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ attribute-group = begin-attribute-group-tag *attribute\r
+\r
+ version-number = major-version-number minor-version-number\r
+ major-version-number = SIGNED-BYTE\r
+ minor-version-number = SIGNED-BYTE\r
+\r
+ operation-id = SIGNED-SHORT ; mapping from model defined below\r
+ status-code = SIGNED-SHORT ; mapping from model defined below\r
+ request-id = SIGNED-INTEGER ; whose value is > 0\r
+\r
+ attribute = attribute-with-one-value *additional-value\r
+\r
+ attribute-with-one-value = value-tag name-length name\r
+ value-length value\r
+ additional-value = value-tag zero-name-length value-length value\r
+\r
+ name-length = SIGNED-SHORT ; number of octets of 'name'\r
+ name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )\r
+ value-length = SIGNED-SHORT ; number of octets of 'value'\r
+ value = OCTET-STRING\r
+\r
+ data = OCTET-STRING\r
+\r
+ zero-name-length = %x00.00 ; name-length of 0\r
+ value-tag = %x10-FF ;see section 3.7.2\r
+ begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1\r
+ end-of-attributes-tag = %x03 ; tag of 3\r
+ ; see section 3.7.1\r
+ SIGNED-BYTE = BYTE\r
+ SIGNED-SHORT = 2BYTE\r
+ SIGNED-INTEGER = 4BYTE\r
+ DIGIT = %x30-39 ; "0" to "9"\r
+ LALPHA = %x61-7A ; "a" to "z"\r
+ BYTE = %x00-FF\r
+ OCTET-STRING = *BYTE\r
+\r
+ The syntax below defines additional terms that are referenced in this\r
+ document. This syntax provides an alternate grouping of the delimiter\r
+ tags.\r
+\r
+ delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1\r
+ end-of-attributes-tag\r
+ delimiter-tag = %x00-0F ; see section 3.7.1\r
+\r
+ begin-attribute-group-tag = %x00 / operation-attributes-tag /\r
+ job-attributes-tag / printer-attributes-tag /\r
+ unsupported-attributes-tag / %x06-0F\r
+ operation-attributes-tag = %x01 ; tag of 1\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 10]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ job-attributes-tag = %x02 ; tag of 2\r
+ printer-attributes-tag = %x04 ; tag of 4\r
+ unsupported-attributes-tag = %x05 ; tag of 5\r
+\r
+3.3 Attribute-group\r
+\r
+ Each "attribute-group" field MUST be encoded with the "begin-\r
+ attribute-group-tag" field followed by zero or more "attribute" sub-\r
+ fields.\r
+\r
+ The table below maps the model document group name to value of the\r
+ "begin-attribute-group-tag" field:\r
+\r
+ Model Document Group "begin-attribute-group-tag" field\r
+ values\r
+\r
+ Operation Attributes "operations-attributes-tag"\r
+ Job Template Attributes "job-attributes-tag"\r
+ Job Object Attributes "job-attributes-tag"\r
+ Unsupported Attributes "unsupported-attributes-tag"\r
+ Requested Attributes "job-attributes-tag"\r
+ (Get-Job-Attributes)\r
+ Requested Attributes "printer-attributes-tag"\r
+ (Get-Printer-Attributes)\r
+ Document Content in a special position as\r
+ described above\r
+\r
+ For each operation request and response, the model document\r
+ prescribes the required and optional attribute groups, along with\r
+ their order. Within each attribute group, the model document\r
+ prescribes the required and optional attributes, along with their\r
+ order.\r
+\r
+ When the Model document requires an attribute group in a request or\r
+ response and the attribute group contains zero attributes, a request\r
+ or response SHOULD encode the attribute group with the "begin-\r
+ attribute-group-tag" field followed by zero "attribute" fields. For\r
+ example, if the client requests a single unsupported attribute with\r
+ the Get-Printer-Attributes operation, the Printer MUST return no\r
+ "attribute" fields, and it SHOULD return a "begin-attribute-group-\r
+ tag" field for the Printer Attributes Group. The Unsupported\r
+ Attributes group is not such an example. According to the model\r
+ document, the Unsupported Attributes Group SHOULD be present only if\r
+ the unsupported attributes group contains at least one attribute.\r
+\r
+ A receiver of a request MUST be able to process the following as\r
+ equivalent empty attribute groups:\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 11]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ a) A "begin-attribute-group-tag" field with zero following\r
+ "attribute" fields.\r
+\r
+ b) An expected but missing "begin-attribute-group-tag" field.\r
+\r
+ When the Model document requires a sequence of an unknown number of\r
+ attribute groups, each of the same type, the encoding MUST contain\r
+ one "begin-attribute-group-tag" field for each attribute group even\r
+ when an "attribute-group" field contains zero "attribute" sub-fields.\r
+ For example, for the Get-Jobs operation may return zero attributes\r
+ for some jobs and not others. The "begin-attribute-group-tag" field\r
+ followed by zero "attribute" fields tells the recipient that there is\r
+ a job in queue for which no information is available except that it\r
+ is in the queue.\r
+\r
+3.4 Required Parameters\r
+\r
+ Some operation elements are called parameters in the model document\r
+ [RFC2911]. They MUST be encoded in a special position and they MUST\r
+ NOT appear as operation attributes. These parameters are described\r
+ in the subsections below.\r
+\r
+3.4.1 Version-number\r
+\r
+ The "version-number" field MUST consist of a major and minor\r
+ version-number, each of which MUST be represented by a SIGNED-BYTE.\r
+ The major version-number MUST be the first byte of the encoding and\r
+ the minor version-number MUST be the second byte of the encoding. The\r
+ protocol described in this document MUST have a major version-number\r
+ of 1 (0x01) and a minor version-number of 1 (0x01). The ABNF for\r
+ these two bytes MUST be %x01.01.\r
+\r
+3.4.2 Operation-id\r
+\r
+ The "operation-id" field MUST contain an operation-id value defined\r
+ in the model document. The value MUST be encoded as a SIGNED-SHORT\r
+ and it MUST be in the third and fourth bytes of the encoding of an\r
+ operation request.\r
+\r
+3.4.3 Status-code\r
+\r
+ The "status-code" field MUST contain a status-code value defined in\r
+ the model document. The value MUST be encoded as a SIGNED-SHORT and\r
+ it MUST be in the third and fourth bytes of the encoding of an\r
+ operation response.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 12]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ The status-code is an operation attribute in the model document. In\r
+ the protocol, the status-code is in a special position, outside of\r
+ the operation attributes.\r
+\r
+ If an IPP status-code is returned, then the HTTP Status-Code MUST be\r
+ 200 (successful-ok). With any other HTTP Status-Code value, the HTTP\r
+ response MUST NOT contain an IPP message-body, and thus no IPP\r
+ status-code is returned.\r
+\r
+3.4.4 Request-id\r
+\r
+ The "request-id" field MUST contain a request-id value as defined in\r
+ the model document. The value MUST be encoded as a SIGNED-INTEGER and\r
+ it MUST be in the fifth through eighth bytes of the encoding.\r
+\r
+3.5 Tags\r
+\r
+ There are two kinds of tags:\r
+\r
+ - delimiter tags: delimit major sections of the protocol, namely\r
+ attributes and data\r
+ - value tags: specify the type of each attribute value\r
+\r
+3.5.1 Delimiter Tags\r
+\r
+ The following table specifies the values for the delimiter tags:\r
+\r
+ Tag Value (Hex) Meaning\r
+\r
+ 0x00 reserved for definition in a future IETF\r
+ standards track document\r
+ 0x01 "operation-attributes-tag"\r
+ 0x02 "job-attributes-tag"\r
+ 0x03 "end-of-attributes-tag"\r
+ 0x04 "printer-attributes-tag"\r
+ 0x05 "unsupported-attributes-tag"\r
+ 0x06-0x0f reserved for future delimiters in IETF\r
+ standards track documents\r
+\r
+ When a "begin-attribute-group-tag" field occurs in the protocol, it\r
+ means that zero or more following attributes up to the next delimiter\r
+ tag MUST be attributes belonging to the attribute group specified by\r
+ the value of the "begin-attribute-group-tag". For example, if the\r
+ value of "begin-attribute-group-tag" is 0x01, the following\r
+ attributes MUST be members of the Operations Attributes group.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 13]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in\r
+ an operation. It MUST be the last "delimiter-tag". If the operation\r
+ has a document-content group, the document data in that group MUST\r
+ follow the "end-of-attributes-tag".\r
+\r
+ The order and presence of "attribute-group" fields (whose beginning\r
+ is marked by the "begin-attribute-group-tag" subfield) for each\r
+ operation request and each operation response MUST be that defined in\r
+ the model document. For further details, see section 3.7 "(Attribute)\r
+ Name" and 13 "Appendix A: Protocol Examples".\r
+\r
+ A Printer MUST treat a "delimiter-tag" (values from 0x00 through\r
+ 0x0F) differently from a "value-tag" (values from 0x10 through 0xFF)\r
+ so that the Printer knows that there is an entire attribute group\r
+ that it doesn't understand as opposed to a single value that it\r
+ doesn't understand.\r
+\r
+3.5.2 Value Tags\r
+\r
+ The remaining tables show values for the "value-tag" field, which is\r
+ the first octet of an attribute. The "value-tag" field specifies the\r
+ type of the value of the attribute.\r
+\r
+ The following table specifies the "out-of-band" values for the\r
+ "value-tag" field.\r
+\r
+ Tag Value (Hex) Meaning\r
+\r
+ 0x10 unsupported\r
+ 0x11 reserved for 'default' for definition in a future\r
+ IETF standards track document\r
+ 0x12 unknown\r
+ 0x13 no-value\r
+ 0x14-0x1F reserved for "out-of-band" values in future IETF\r
+ standards track documents.\r
+\r
+ The following table specifies the integer values for the "value-tag"\r
+ field:\r
+\r
+ Tag Value (Hex) Meaning\r
+\r
+ 0x20 reserved for definition in a future IETF\r
+ standards track document\r
+ 0x21 integer\r
+ 0x22 boolean\r
+ 0x23 enum\r
+ 0x24-0x2F reserved for integer types for definition in\r
+ future IETF standards track documents\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 14]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ NOTE: 0x20 is reserved for "generic integer" if it should ever be\r
+ needed.\r
+\r
+ The following table specifies the octetString values for the "value-\r
+ tag" field:\r
+\r
+ Tag Value (Hex) Meaning\r
+\r
+ 0x30 octetString with an unspecified format\r
+ 0x31 dateTime\r
+ 0x32 resolution\r
+ 0x33 rangeOfInteger\r
+ 0x34 reserved for definition in a future IETF\r
+ standards track document\r
+ 0x35 textWithLanguage\r
+ 0x36 nameWithLanguage\r
+ 0x37-0x3F reserved for octetString type definitions in\r
+ future IETF standards track documents\r
+\r
+ The following table specifies the character-string values for the\r
+ "value-tag" field:\r
+\r
+ Tag Value (Hex) Meaning\r
+\r
+ 0x40 reserved for definition in a future IETF\r
+ standards track document\r
+ 0x41 textWithoutLanguage\r
+ 0x42 nameWithoutLanguage\r
+ 0x43 reserved for definition in a future IETF\r
+ standards track document\r
+ 0x44 keyword\r
+ 0x45 uri\r
+ 0x46 uriScheme\r
+ 0x47 charset\r
+ 0x48 naturalLanguage\r
+ 0x49 mimeMediaType\r
+ 0x4A-0x5F reserved for character string type definitions\r
+ in future IETF standards track documents\r
+\r
+ NOTE: 0x40 is reserved for "generic character-string" if it should\r
+ ever be needed.\r
+\r
+ NOTE: an attribute value always has a type, which is explicitly\r
+ specified by its tag; one such tag value is "nameWithoutLanguage".\r
+ An attribute's name has an implicit type, which is keyword.\r
+\r
+ The values 0x60-0xFF are reserved for future type definitions in IETF\r
+ standards track documents.\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 15]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ The tag 0x7F is reserved for extending types beyond the 255 values\r
+ available with a single byte. A tag value of 0x7F MUST signify that\r
+ the first 4 bytes of the value field are interpreted as the tag\r
+ value. Note this future extension doesn't affect parsers that are\r
+ unaware of this special tag. The tag is like any other unknown tag,\r
+ and the value length specifies the length of a value, which contains\r
+ a value that the parser treats atomically. Values from 0x00 to\r
+ 0x37777777 are reserved for definition in future IETF standard track\r
+ documents. The values 0x40000000 to 0x7FFFFFFF are reserved for\r
+ vendor extensions.\r
+\r
+3.6 Name-Length\r
+\r
+ The "name-length" field MUST consist of a SIGNED-SHORT. This field\r
+ MUST specify the number of octets in the immediately following "name"\r
+ field. The value of this field excludes the two bytes of the "name-\r
+ length" field. For example, if the "name" field contains "sides", the\r
+ value of this field is 5.\r
+\r
+ If a "name-length" field has a value of zero, the following "name"\r
+ field MUST be empty, and the following value MUST be treated as an\r
+ additional value for the attribute encoded in the nearest preceding\r
+ "attribute-with-one-value" field. Within an attribute group, if two\r
+ or more attributes have the same name, the attribute group is mal-\r
+ formed (see [RFC2911] section 3.1.3). The zero-length name is the\r
+ only mechanism for multi-valued attributes.\r
+\r
+3.7 (Attribute) Name\r
+\r
+ The "name" field MUST contain the name of an attribute. The model\r
+ document [RFC2911] specifies such names.\r
+\r
+3.8 Value Length\r
+\r
+ The "value-length" field MUST consist of a SIGNED-SHORT. This field\r
+ MUST specify the number of octets in the immediately following\r
+ "value" field. The value of this field excludes the two bytes of the\r
+ "value-length" field. For example, if the "value" field contains the\r
+ keyword (text) value 'one-sided', the value of this field is 9.\r
+\r
+ For any of the types represented by binary signed integers, the\r
+ sender MUST encode the value in exactly four octets.\r
+\r
+ For any of the types represented by character-strings, the sender\r
+ MUST encode the value with all the characters of the string and\r
+ without any padding characters.\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 16]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ For "out-of-band" "value-tag" fields defined in this document, such\r
+ as "unsupported", the "value-length" MUST be 0 and the "value" empty;\r
+ the "value" has no meaning when the "value-tag" has one of these\r
+ "out-of-band" values. For future "out-of-band" "value-tag" fields,\r
+ the same rule holds unless the definition explicitly states that the\r
+ "value-length" MAY be non-zero and the "value" non-empty.\r
+\r
+3.9 (Attribute) Value\r
+\r
+ The syntax types (specified by the "value-tag" field) and most of the\r
+ details of the representation of attribute values are defined in the\r
+ IPP model document. The table below augments the information in the\r
+ model document, and defines the syntax types from the model document\r
+ in terms of the 5 basic types defined in section 3, "Encoding of the\r
+ Operation Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING,\r
+ SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING.\r
+\r
+ Syntax of Attribute Encoding\r
+ Value\r
+\r
+ textWithoutLanguage, LOCALIZED-STRING.\r
+ nameWithoutLanguage\r
+\r
+ textWithLanguage OCTET-STRING consisting of 4 fields:\r
+ a. a SIGNED-SHORT which is the number of\r
+ octets in the following field\r
+ b. a value of type natural-language,\r
+ c. a SIGNED-SHORT which is the number of\r
+ octets in the following field,\r
+ d. a value of type textWithoutLanguage.\r
+ The length of a textWithLanguage value MUST be\r
+ 4 + the value of field a + the value of field c.\r
+\r
+ nameWithLanguage OCTET-STRING consisting of 4 fields:\r
+ a. a SIGNED-SHORT which is the number of\r
+ octets in the following field\r
+ b. a value of type natural-language,\r
+ c. a SIGNED-SHORT which is the number of\r
+ octets in the following field\r
+ d. a value of type nameWithoutLanguage.\r
+ The length of a nameWithLanguage value MUST be\r
+ 4 + the value of field a + the value of field c.\r
+\r
+ charset, US-ASCII-STRING.\r
+ naturalLanguage,\r
+ mimeMediaType,\r
+ keyword, uri, and\r
+ uriScheme\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 17]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Syntax of Attribute Encoding\r
+ Value\r
+\r
+ boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is\r
+ 'true'.\r
+\r
+ integer and enum a SIGNED-INTEGER.\r
+\r
+ dateTime OCTET-STRING consisting of eleven octets whose\r
+ contents are defined by "DateAndTime" in RFC\r
+ 1903 [RFC1903].\r
+\r
+ resolution OCTET-STRING consisting of nine octets of 2\r
+ SIGNED-INTEGERs followed by a SIGNED-BYTE. The\r
+ first SIGNED-INTEGER contains the value of\r
+ cross feed direction resolution. The second\r
+ SIGNED-INTEGER contains the value of feed\r
+ direction resolution. The SIGNED-BYTE contains\r
+ the units\r
+\r
+ rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs.\r
+ The first SIGNED-INTEGER contains the lower\r
+ bound and the second SIGNED-INTEGER contains\r
+ the upper bound.\r
+\r
+ 1setOf X Encoding according to the rules for an\r
+ attribute with more than 1 value. Each value\r
+ X is encoded according to the rules for\r
+ encoding its type.\r
+\r
+ octetString OCTET-STRING\r
+\r
+\r
+ The attribute syntax type of the value determines its encoding and\r
+ the value of its "value-tag".\r
+\r
+3.10 Data\r
+\r
+ The "data" field MUST include any data required by the operation\r
+\r
+4. Encoding of Transport Layer\r
+\r
+ HTTP/1.1 [RFC2616] is the transport layer for this protocol.\r
+\r
+ The operation layer has been designed with the assumption that the\r
+ transport layer contains the following information:\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 18]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ - the URI of the target job or printer operation\r
+ - the total length of the data in the operation layer, either as\r
+ a single length or as a sequence of chunks each with a length.\r
+\r
+ It is REQUIRED that a printer implementation support HTTP over the\r
+ IANA assigned Well Known Port 631 (the IPP default port), though a\r
+ printer implementation may support HTTP over some other port as well.\r
+\r
+ Each HTTP operation MUST use the POST method where the request-URI is\r
+ the object target of the operation, and where the "Content-Type" of\r
+ the message-body in each request and response MUST be\r
+ "application/ipp". The message-body MUST contain the operation layer\r
+ and MUST have the syntax described in section 3.2 "Syntax of\r
+ Encoding". A client implementation MUST adhere to the rules for a\r
+ client described for HTTP1.1 [RFC2616]. A printer (server)\r
+ implementation MUST adhere the rules for an origin server described\r
+ for HTTP1.1 [RFC2616].\r
+\r
+ An IPP server sends a response for each request that it receives. If\r
+ an IPP server detects an error, it MAY send a response before it has\r
+ read the entire request. If the HTTP layer of the IPP server\r
+ completes processing the HTTP headers successfully, it MAY send an\r
+ intermediate response, such as "100 Continue", with no IPP data\r
+ before sending the IPP response. A client MUST expect such a variety\r
+ of responses from an IPP server. For further information on HTTP/1.1,\r
+ consult the HTTP documents [RFC2616].\r
+\r
+ An HTTP server MUST support chunking for IPP requests, and an IPP\r
+ client MUST support chunking for IPP responses according to HTTP/1.1\r
+ [RFC2616]. Note: this rule causes a conflict with non-compliant\r
+ implementations of HTTP/1.1 that don't support chunking for POST\r
+ methods, and this rule may cause a conflict with non-compliant\r
+ implementations of HTTP/1.1 that don't support chunking for CGI\r
+ scripts.\r
+\r
+4.1 Printer-uri and job-uri\r
+\r
+ All Printer and Job objects are identified by a Uniform Resource\r
+ Identifier (URI) [RFC2396] so that they can be persistently and\r
+ unambiguously referenced. Since every URL is a specialized form of a\r
+ URI, even though the more generic term URI is used throughout the\r
+ rest of this document, its usage is intended to cover the more\r
+ specific notion of URL as well.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 19]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Some operation elements are encoded twice, once as the request-URI on\r
+ the HTTP Request-Line and a second time as a REQUIRED operation\r
+ attribute in the application/ipp entity. These attributes are the\r
+ target URI for the operation and are called printer-uri and job-uri.\r
+ Note: The target URI is included twice in an operation referencing\r
+ the same IPP object, but the two URIs NEED NOT be literally\r
+ identical. One can be a relative URI and the other can be an absolute\r
+ URI. HTTP/1.1 allows clients to generate and send a relative URI\r
+ rather than an absolute URI. A relative URI identifies a resource\r
+ with the scope of the HTTP server, but does not include scheme, host\r
+ or port. The following statements characterize how URLs should be\r
+ used in the mapping of IPP onto HTTP/1.1:\r
+\r
+ 1. Although potentially redundant, a client MUST supply the target\r
+ of the operation both as an operation attribute and as a URI at\r
+ the HTTP layer. The rationale for this decision is to maintain\r
+ a consistent set of rules for mapping application/ipp to\r
+ possibly many communication layers, even where URLs are not\r
+ used as the addressing mechanism in the transport layer.\r
+ 2. Even though these two URLs might not be literally identical\r
+ (one being relative and the other being absolute), they MUST\r
+ both reference the same IPP object. However, a Printer NEED NOT\r
+ verify that the two URLs reference the same IPP object, and\r
+ NEED NOT take any action if it determines the two URLs to be\r
+ different.\r
+ 3. The URI in the HTTP layer is either relative or absolute and is\r
+ used by the HTTP server to route the HTTP request to the\r
+ correct resource relative to that HTTP server. The HTTP server\r
+ need not be aware of the URI within the operation request.\r
+ 4. Once the HTTP server resource begins to process the HTTP\r
+ request, it might get the reference to the appropriate IPP\r
+ Printer object from either the HTTP URI (using to the context\r
+ of the HTTP server for relative URLs) or from the URI within\r
+ the operation request; the choice is up to the implementation.\r
+ 5. HTTP URIs can be relative or absolute, but the target URI in\r
+ the operation MUST be an absolute URI.\r
+\r
+5. IPP URL Scheme\r
+\r
+ The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL\r
+ that identifies either an IPP printer object or an IPP job object.\r
+ The IPP attributes using the 'ipp' scheme are specified below.\r
+ Because the HTTP layer does not support the 'ipp' scheme, a client\r
+ MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP\r
+ [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP\r
+ headers. The mapping is simple because the 'ipp' scheme implies all\r
+ of the same protocol semantics as that of the 'http' scheme\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 20]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ [RFC2616], except that it represents a print service and the implicit\r
+ (default) port number that clients use to connect to a server is port\r
+ 631.\r
+\r
+ In the remainder of this section the term 'ipp-URL' means a URL whose\r
+ scheme is 'ipp' and whose implicit (default) port is 631. The term\r
+ 'http-URL' means a URL whose scheme is 'http', and the term 'https-\r
+ URL' means a URL whose scheme is 'https',\r
+\r
+ A client and an IPP object (i.e. the server) MUST support the ipp-URL\r
+ value in the following IPP attributes.\r
+ job attributes:\r
+ job-uri\r
+ job-printer-uri\r
+ printer attributes:\r
+ printer-uri-supported\r
+ operation attributes:\r
+ job-uri\r
+ printer-uri\r
+ Each of the above attributes identifies a printer or job object. The\r
+ ipp-URL is intended as the value of the attributes in this list, and\r
+ for no other attributes. All of these attributes have a syntax type\r
+ of 'uri', but there are attributes with a syntax type of 'uri' that\r
+ do not use the 'ipp' scheme, e.g. 'job-more-info'.\r
+\r
+ If a printer registers its URL with a directory service, the printer\r
+ MUST register an ipp-URL.\r
+\r
+ User interfaces are beyond the scope of this document. But if\r
+ software exposes the ipp-URL values of any of the above five\r
+ attributes to a human user, it is REQUIRED that the human see the\r
+ ipp-URL as is.\r
+\r
+ When a client sends a request, it MUST convert a target ipp-URL to a\r
+ target http-URL for the HTTP layer according to the following rules:\r
+\r
+ 1. change the 'ipp' scheme to 'http'\r
+ 2. add an explicit port 631 if the URL does not contain an\r
+ explicit port. Note: port 631 is the IANA assigned Well Known\r
+ Port for the 'ipp' scheme.\r
+\r
+ The client MUST use the target http-URL in both the HTTP Request-\r
+ Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] .\r
+ However, the client MUST use the target ipp-URL for the value of the\r
+ "printer-uri" or "job-uri" operation attribute within the\r
+ application/ipp body of the request. The server MUST use the ipp-URL\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 21]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ for the value of the "printer-uri", "job-uri" or "printer-uri-\r
+ supported" attributes within the application/ipp body of the\r
+ response.\r
+\r
+ For example, when an IPP client sends a request directly (i.e. no\r
+ proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a\r
+ TCP connection to port 631 (the ipp implicit port) on the host\r
+ "myhost.com" and sends the following data:\r
+\r
+ POST /myprinter/myqueue HTTP/1.1\r
+ Host: myhost.com:631\r
+ Content-type: application/ipp\r
+ Transfer-Encoding: chunked\r
+ ...\r
+ "printer-uri" "ipp://myhost.com/myprinter/myqueue"\r
+ (encoded in application/ipp message body)\r
+ ...\r
+\r
+ As another example, when an IPP client sends the same request as\r
+ above via a proxy "myproxy.com", it opens a TCP connection to the\r
+ proxy port 8080 on the proxy host "myproxy.com" and sends the\r
+ following data:\r
+\r
+ POST http://myhost.com:631/myprinter/myqueue HTTP/1.1\r
+ Host: myhost.com:631\r
+ Content-type: application/ipp\r
+ Transfer-Encoding: chunked\r
+ ...\r
+ "printer-uri" "ipp://myhost.com/myprinter/myqueue"\r
+ (encoded in application/ipp message body)\r
+ ...\r
+\r
+ The proxy then connects to the IPP origin server with headers that\r
+ are the same as the "no-proxy" example above.\r
+\r
+6. IANA Considerations\r
+\r
+ This section describes the procedures for allocating encoding for the\r
+ following IETF standards track extensions and vendor extensions to\r
+ the IPP/1.1 Encoding and Transport document:\r
+\r
+ 1. attribute syntaxes - see [RFC2911] section 6.3\r
+ 2. attribute groups - see [RFC2911] section 6.5\r
+ 3. out-of-band attribute values - see [RFC2911] section 6.7\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 22]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ These extensions follow the "type2" registration procedures defined\r
+ in [RFC2911] section 6. Extensions registered for use with IPP/1.1\r
+ are OPTIONAL for client and IPP object conformance to the IPP/1.1\r
+ Encoding and Transport document.\r
+\r
+ These extension procedures are aligned with the guidelines as set\r
+ forth by the IESG [IANA-CON]. The [RFC2911] Section 11 describes how\r
+ to propose new registrations for consideration. IANA will reject\r
+ registration proposals that leave out required information or do not\r
+ follow the appropriate format described in [RFC2911] Section 11. The\r
+ IPP/1.1 Encoding and Transport document may also be extended by an\r
+ appropriate RFC that specifies any of the above extensions.\r
+\r
+7. Internationalization Considerations\r
+\r
+ See the section on "Internationalization Considerations" in the\r
+ document "Internet Printing Protocol/1.1: Model and Semantics"\r
+ [RFC2911] for information on internationalization. This document adds\r
+ no additional issues.\r
+\r
+8. Security Considerations\r
+\r
+ The IPP Model and Semantics document [RFC2911] discusses high level\r
+ security requirements (Client Authentication, Server Authentication\r
+ and Operation Privacy). Client Authentication is the mechanism by\r
+ which the client proves its identity to the server in a secure\r
+ manner. Server Authentication is the mechanism by which the server\r
+ proves its identity to the client in a secure manner. Operation\r
+ Privacy is defined as a mechanism for protecting operations from\r
+ eavesdropping.\r
+\r
+8.1 Security Conformance Requirements\r
+\r
+ This section defines the security requirements for IPP clients and\r
+ IPP objects.\r
+\r
+8.1.1 Digest Authentication\r
+\r
+ IPP clients MUST support:\r
+\r
+ Digest Authentication [RFC2617].\r
+\r
+ MD5 and MD5-sess MUST be implemented and supported.\r
+\r
+ The Message Integrity feature NEED NOT be used.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 23]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ IPP Printers SHOULD support:\r
+\r
+ Digest Authentication [RFC2617].\r
+\r
+ MD5 and MD5-sess MUST be implemented and supported.\r
+\r
+ The Message Integrity feature NEED NOT be used.\r
+\r
+ The reasons that IPP Printers SHOULD (rather than MUST) support\r
+ Digest Authentication are:\r
+\r
+ 1. While Client Authentication is important, there is a certain class\r
+ of printer devices where it does not make sense. Specifically, a\r
+ low-end device with limited ROM space and low paper throughput may\r
+ not need Client Authentication. This class of device typically\r
+ requires firmware designers to make trade-offs between protocols\r
+ and functionality to arrive at the lowest-cost solution possible.\r
+ Factored into the designer's decisions is not just the size of the\r
+ code, but also the testing, maintenance, usefulness, and time-to-\r
+ market impact for each feature delivered to the customer. Forcing\r
+ such low-end devices to provide security in order to claim IPP/1.1\r
+ conformance would not make business sense and could potentially\r
+ stall the adoption of the standard.\r
+\r
+ 2. Print devices that have high-volume throughput and have available\r
+ ROM space have a compelling argument to provide support for Client\r
+ Authentication that safeguards the device from unauthorized\r
+ access. These devices are prone to a high loss of consumables and\r
+ paper if unauthorized access should occur.\r
+\r
+8.1.2 Transport Layer Security (TLS)\r
+\r
+ IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]\r
+ for Server Authentication and Operation Privacy. IPP Printers MAY\r
+ also support TLS for Client Authentication. If an IPP Printer\r
+ supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA\r
+ cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher\r
+ suites are OPTIONAL. An IPP Printer MAY support Basic Authentication\r
+ (described in HTTP/1.1 [RFC2617]) for Client Authentication if the\r
+ channel is secure. TLS with the above mandated cipher suite can\r
+ provide such a secure channel.\r
+\r
+ If a IPP client supports TLS, it MUST support the\r
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC\r
+ 2246 [RFC2246]. All other cipher suites are OPTIONAL.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 24]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ The IPP Model and Semantics document defines two printer attributes\r
+ ("uri-authentication-supported" and "uri-security-supported") that\r
+ the client can use to discover the security policy of a printer. That\r
+ document also outlines IPP-specific security considerations and\r
+ should be the primary reference for security implications with regard\r
+ to the IPP protocol itself. For backward compatibility with IPP\r
+ version 1.0, IPP clients and printers may also support SSL3 [ssl].\r
+ This is in addition to the security required in this document.\r
+\r
+8.2 Using IPP with TLS\r
+\r
+ IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism\r
+ [RFC2817]. An initial IPP request never uses TLS. The client\r
+ requests a secure TLS connection by using the HTTP "Upgrade" header,\r
+ while the server agrees in the HTTP response. The switch to TLS\r
+ occurs either because the server grants the client's request to\r
+ upgrade to TLS, or a server asks to switch to TLS in its response.\r
+ Secure communication begins with a server's response to switch to\r
+ TLS.\r
+\r
+9. Interoperability with IPP/1.0 Implementations\r
+\r
+ It is beyond the scope of this specification to mandate conformance\r
+ with previous versions. IPP/1.1 was deliberately designed, however,\r
+ to make supporting previous versions easy. It is worth noting that,\r
+ at the time of composing this specification (1999), we would expect\r
+ IPP/1.1 Printer implementations to:\r
+\r
+ understand any valid request in the format of IPP/1.0, or 1.1;\r
+\r
+ respond appropriately with a response containing the same\r
+ "version-number" parameter value used by the client in the\r
+ request.\r
+\r
+ And we would expect IPP/1.1 clients to:\r
+\r
+ understand any valid response in the format of IPP/1.0, or 1.1.\r
+\r
+9.1 The "version-number" Parameter\r
+\r
+ The following are rules regarding the "version-number" parameter (see\r
+ section 3.3):\r
+\r
+ 1. Clients MUST send requests containing a "version-number"\r
+ parameter with a '1.1' value and SHOULD try supplying alternate\r
+ version numbers if they receive a 'server-error-version-not-\r
+ supported' error return in a response.\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 25]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ 2. IPP objects MUST accept requests containing a "version-number"\r
+ parameter with a '1.1' value (or reject the request for reasons\r
+ other than 'server-error-version-not-supported').\r
+\r
+ 3. It is recommended that IPP objects accept any request with the\r
+ major version '1' (or reject the request for reasons other than\r
+ 'server-error-version-not-supported'). See [RFC2911]\r
+ "versions" sub-section.\r
+\r
+ 4. In any case, security MUST NOT be compromised when a client\r
+ supplies a lower "version-number" parameter in a request. For\r
+ example, if an IPP/1.1 conforming Printer object accepts\r
+ version '1.0' requests and is configured to enforce Digest\r
+ Authentication, it MUST do the same for a version '1.0'\r
+ request.\r
+\r
+9.2 Security and URL Schemes\r
+\r
+ The following are rules regarding security, the "version-number"\r
+ parameter, and the URL scheme supplied in target attributes and\r
+ responses:\r
+\r
+ 1. When a client supplies a request, the "printer-uri" or "job-\r
+ uri" target operation attribute MUST have the same scheme as\r
+ that indicated in one of the values of the "printer-uri-\r
+ supported" Printer attribute.\r
+\r
+ 2. When the server returns the "job-printer-uri" or "job-uri" Job\r
+ Description attributes, it SHOULD return the same scheme\r
+ ('ipp', 'https', 'http', etc.) that the client supplied in the\r
+ "printer-uri" or "job-uri" target operation attributes in the\r
+ Get-Job-Attributes or Get-Jobs request, rather than the scheme\r
+ used when the job was created. However, when a client requests\r
+ job attributes using the Get-Job-Attributes or Get-Jobs\r
+ operations, the jobs and job attributes that the server returns\r
+ depends on: (1) the security in effect when the job was\r
+ created, (2) the security in effect in the query request, and\r
+ (3) the security policy in force.\r
+\r
+ 3. It is recommended that if a server registers a non-secure ipp-\r
+ URL with a directory service (see [RFC2911] "Generic Directory\r
+ Schema" Appendix), then it also register an http-URL for\r
+ interoperability with IPP/1.0 clients (see section 9).\r
+\r
+ 4. In any case, security MUST NOT be compromised when a client\r
+ supplies an 'http' or other non-secure URL scheme in the target\r
+ "printer-uri" and "job-uri" operation attributes in a request.\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 26]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+10. References\r
+\r
+ [dpa] ISO/IEC 10175 Document Printing Application (DPA), June\r
+ 1996.\r
+\r
+ [iana] IANA Registry of Coded Character Sets:\r
+ ftp://ftp.isi.edu/in-notes/iana/assignments/character-\r
+ sets.\r
+\r
+ [IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an\r
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,\r
+ October 1998.\r
+\r
+ [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1:\r
+ Implementer's Guide", Work in Progress.\r
+\r
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet\r
+ Text Messages", STD 11, RFC 822, August 1982.\r
+\r
+ [RFC1123] Braden, S., "Requirements for Internet Hosts - Application\r
+ and Support", STD 3, RFC 1123, October, 1989.\r
+\r
+ [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon\r
+ Protocol", RFC 1179, August 1990.\r
+\r
+ [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",\r
+ RFC 2223, October 1997.\r
+\r
+ [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform\r
+ Resource Locators (URL)", RFC 1738, December 1994.\r
+\r
+ [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.\r
+ Gyllenskog, "Printer MIB", RFC 1759, March 1995.\r
+\r
+ [RFC1766] Alvestrand, H., "Tags for the Identification of\r
+ Languages", RFC 1766, March 1995.\r
+\r
+ [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC\r
+ 1808, June 1995.\r
+\r
+ [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,\r
+ "Textual Conventions for Version 2 of the Simple Network\r
+ Management Protocol (SNMPv2)", RFC 1903, January 1996.\r
+\r
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail\r
+ Extensions (MIME) Part Two: Media Types", RFC 2046,\r
+ November 1996.\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 27]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose\r
+ Internet Mail Extension (MIME) Part Four: Registration\r
+ Procedures", BCP 13, RFC 2048, November 1996.\r
+\r
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded\r
+ Word Extensions: Character Sets, Languages, and\r
+ Continuations", RFC 2184, August 1997.\r
+\r
+ [RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax\r
+ Specifications: ABNF", RFC 2234, November 1997.\r
+\r
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246.\r
+ January 1999.\r
+\r
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform\r
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,\r
+ August 1998.\r
+\r
+ [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,\r
+ "Internet Printing Protocol/1.0: Encoding and Transport",\r
+ RFC 2565, April 1999.\r
+\r
+ [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.\r
+ Powell, "Internet Printing Protocol/1.0: Model and\r
+ Semantics", RFC 2566, April 1999.\r
+\r
+ [RFC2567] Wright, D., "Design Goals for an Internet Printing\r
+ Protocol", RFC2567, April 1999.\r
+\r
+ [RFC2568] Zilles, S., "Rationale for the Structure and Model and\r
+ Protocol for the Internet Printing Protocol", RFC 2568,\r
+ April 1999.\r
+\r
+ [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,\r
+ "Mapping between LPD and IPP Protocols", RFC 2569, April\r
+ 1999.\r
+\r
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,\r
+ Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext\r
+ Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.\r
+\r
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,\r
+ Leach, P., Luotonen, A. and L. Stewart, "HTTP\r
+ Authentication: Basic and Digest Access Authentication",\r
+ RFC 2617, June 1999.\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 28]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within\r
+ HTTP/1.1", RFC 2817, May 2000.\r
+\r
+ [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.\r
+ Wenn, "Internet Printing Protocol/1.1: Encoding and\r
+ Transport", RFC 2910, September 2000.\r
+\r
+ [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.\r
+ Powell, "Internet Printing Protocol/1.1: Model and\r
+ Semantics", RFC 2911, September 2000.\r
+\r
+ [SSL] Netscape, The SSL Protocol, Version 3, (Text version\r
+ 3.02), November 1996.\r
+\r
+11. Authors' Addresses\r
+\r
+ Robert Herriot, Editor\r
+ Xerox Corporation\r
+ 3400 Hillview Ave., Bldg #1\r
+ Palo Alto, CA 94304\r
+\r
+ Phone: 650-813-7696\r
+ Fax: 650-813-6860\r
+ EMail: robert.herriot@pahv.xerox.com\r
+\r
+\r
+ Sylvan Butler\r
+ Hewlett-Packard\r
+ 11311 Chinden Blvd.\r
+ Boise, ID 83714\r
+\r
+ Phone: 208-396-6000\r
+ Fax: 208-396-3457\r
+ EMail: sbutler@boi.hp.com\r
+\r
+\r
+ Paul Moore\r
+ Peerless Systems Networking\r
+ 10900 NE 8th St #900\r
+ Bellevue, WA 98004\r
+\r
+ Phone: 425-462-5852\r
+ EMail: pmoore@peerless.com\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 29]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Randy Turner\r
+ 2Wire, Inc.\r
+ 694 Tasman Dr.\r
+ Milpitas, CA 95035\r
+\r
+ Phone: 408-546-1273\r
+\r
+\r
+ John Wenn\r
+ Xerox Corporation\r
+ 737 Hawaii St\r
+ El Segundo, CA 90245\r
+\r
+ Phone: 310-333-5764\r
+ Fax: 310-333-5514\r
+ EMail: jwenn@cp10.es.xerox.com\r
+\r
+\r
+ IPP Web Page: http://www.pwg.org/ipp/\r
+ IPP Mailing List: ipp@pwg.org\r
+\r
+ To subscribe to the ipp mailing list, send the following email:\r
+ 1) send it to majordomo@pwg.org\r
+ 2) leave the subject line blank\r
+ 3) put the following two lines in the message body:\r
+ subscribe ipp\r
+ end\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 30]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+12. Other Participants:\r
+\r
+ Chuck Adams - Tektronix Shivaun Albright - HP\r
+ Stefan Andersson - Axis Jeff Barnett - IBM\r
+ Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM\r
+ Systems\r
+ Keith Carter - IBM Angelo Caruso - Xerox\r
+ Rajesh Chawla - TR Computing Nancy Chen - Okidata\r
+ Solutions\r
+ Josh Cohen - Microsoft Jeff Copeland - QMS\r
+ Andy Davidson - Tektronix Roger deBry - IBM\r
+ Maulik Desai - Auco Mabry Dozier - QMS\r
+ Lee Farrell - Canon Information Satoshi Fujitami - Ricoh\r
+ Systems\r
+ Steve Gebert - IBM Sue Gleeson - Digital\r
+ Charles Gordon - Osicom Brian Grimshaw - Apple\r
+ Jerry Hadsell - IBM Richard Hart - Digital\r
+ Tom Hastings - Xerox Henrik Holst - I-data\r
+ Stephen Holmstead Zhi-Hong Huang - Zenographics\r
+ Scott Isaacson - Novell Babek Jahromi - Microsoft\r
+ Swen Johnson - Xerox David Kellerman - Northlake\r
+ Software\r
+ Robert Kline - TrueSpectra Charles Kong - Panasonic\r
+ Carl Kugler - IBM Dave Kuntz - Hewlett-Packard\r
+ Takami Kurono - Brother Rick Landau - Digital\r
+ Scott Lawrence - Agranot Systems Greg LeClair - Epson\r
+ Dwight Lewis - Lexmark Harry Lewis - IBM\r
+ Tony Liao - Vivid Image Roy Lomicka - Digital\r
+ Pete Loya - HP Ray Lutz - Cognisys\r
+ Mike MacKay - Novell, Inc. David Manchala - Xerox\r
+ Carl-Uno Manros - Xerox Jay Martin - Underscore\r
+ Stan McConnell - Xerox Larry Masinter - Xerox\r
+ Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft\r
+ Ira McDonald - High North Inc. Mike Moldovan - G3 Nova\r
+ Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh\r
+ Pat Nogay - IBM Ron Norton - Printronics\r
+ Hugo Parra, Novell Bob Pentecost - Hewlett-Packard\r
+ Patrick Powell - Astart Jeff Rackowitz - Intermec\r
+ Technologies\r
+ Eric Random - Peerless Rob Rhoads - Intel\r
+ Xavier Riley - Xerox Gary Roberts - Ricoh\r
+ David Roach - Unisys Stuart Rowley - Kyocera\r
+ Yuji Sasaki - Japan Computer Richard Schneider - Epson\r
+ Industry\r
+ Kris Schoff - HP Katsuaki Sekiguchi - Canon\r
+ Information Systems\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 31]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Bob Setterbo - Adobe Gail Songer - Peerless\r
+ Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.\r
+ Systems\r
+ Mike Timperman - Lexmark Atsushi Uchino - Epson\r
+ Shigeru Ueda - Canon Bob Von Andel - Allegro Software\r
+ William Wagner - NetSilicon/DPI Jim Walker - DAZEL\r
+ Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard\r
+ Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.\r
+ Jasper Wong - Xionics Don Wright - Lexmark\r
+ Michael Wu - Heidelberg Digital Rick Yardumian - Xerox\r
+ Michael Yeung - Canon Information Lloyd Young - Lexmark\r
+ Systems\r
+ Atsushi Yuki - Kyocera Peter Zehler - Xerox\r
+ William Zhang - Canon Information Frank Zhao - Panasonic\r
+ Systems\r
+ Steve Zilles - Adobe Rob Zirnstein - Canon Information\r
+ Systems\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 32]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+13. Appendix A: Protocol Examples\r
+\r
+13.1 Print-Job Request\r
+\r
+ The following is an example of a Print-Job request with job-name,\r
+ copies, and sides specified. The "ipp-attribute-fidelity" attribute\r
+ is set to 'true' so that the print request will fail if the "copies"\r
+ or the "sides" attribute are not supported or their values are not\r
+ supported.\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x0002 Print-Job operation-id\r
+ 0x00000001 1 request-id\r
+ 0x01 start operation-attributes operation-attributes-tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x0008 value-length\r
+ us-ascii US-ASCII value\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- name\r
+ natural- attributes-natural-language\r
+ language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x45 uri type value-tag\r
+ 0x000B name-length\r
+ printer-uri printer-uri name\r
+ 0x0015 value-length\r
+ ipp://forest/ printer pinetree value\r
+ pinetree\r
+ 0x42 nameWithoutLanguage type value-tag\r
+ 0x0008 name-length\r
+ job-name job-name name\r
+ 0x0006 value-length\r
+ foobar foobar value\r
+ 0x22 boolean type value-tag\r
+ 0x0016 name-length\r
+ ipp-attribute- ipp-attribute-fidelity name\r
+ fidelity\r
+ 0x0001 value-length\r
+ 0x01 true value\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 33]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x02 start job-attributes job-attributes-tag\r
+ 0x21 integer type value-tag\r
+ 0x0006 name-length\r
+ copies copies name\r
+ 0x0004 value-length\r
+ 0x00000014 20 value\r
+ 0x44 keyword type value-tag\r
+ 0x0005 name-length\r
+ sides sides name\r
+ 0x0013 value-length\r
+ two-sided- two-sided-long-edge value\r
+ long-edge\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+ %!PS... <PostScript> data\r
+\r
+13.2 Print-Job Response (successful)\r
+\r
+ Here is an example of a successful Print-Job response to the previous\r
+ Print-Job request. The printer supported the "copies" and "sides"\r
+ attributes and their supplied values. The status code returned is\r
+ 'successful-ok'.\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x0000 successful-ok status-code\r
+ 0x00000001 1 request-id\r
+ 0x01 start operation-attributes operation-attributes-tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x0008 value-length\r
+ us-ascii US-ASCII value\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- attributes-natural- name\r
+ natural-language language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x41 textWithoutLanguage type value-tag\r
+ 0x000E name-length\r
+ status-message status-message name\r
+ 0x000D value-length\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 34]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ successful-ok successful-ok value\r
+ 0x02 start job-attributes job-attributes-tag\r
+ 0x21 integer value-tag\r
+ 0x0006 name-length\r
+ job-id job-id name\r
+ 0x0004 value-length\r
+ 147 147 value\r
+ 0x45 uri type value-tag\r
+ 0x0007 name-length\r
+ job-uri job-uri name\r
+ 0x0019 value-length\r
+ ipp://forest/ job 123 on pinetree value\r
+ pinetree/123\r
+ 0x23 enum type value-tag\r
+ 0x0009 name-length\r
+ job-state job-state name\r
+ 0x0004 value-length\r
+ 0x0003 pending value\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+\r
+13.3 Print-Job Response (failure)\r
+\r
+ Here is an example of an unsuccessful Print-Job response to the\r
+ previous Print-Job request. It fails because, in this case, the\r
+ printer does not support the "sides" attribute and because the value\r
+ '20' for the "copies" attribute is not supported. Therefore, no job\r
+ is created, and neither a "job-id" nor a "job-uri" operation\r
+ attribute is returned. The error code returned is 'client-error-\r
+ attributes-or-values-not-supported' (0x040B).\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x040B client-error-attributes-or- status-code\r
+ values-not-supported\r
+ 0x00000001 1 request-id\r
+ 0x01 start operation-attributes operation-attributes tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x0008 value-length\r
+ us-ascii US-ASCII value\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 35]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- attributes-natural-language name\r
+ natural-\r
+ language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x41 textWithoutLanguage type value-tag\r
+ 0x000E name-length\r
+ status- status-message name\r
+ message\r
+ 0x002F value-length\r
+ client-error- value\r
+ attributes- values-not-supported\r
+ or-values- client-error-attributes-or-\r
+ not-supported\r
+ 0x05 start unsupported-attributes unsupported-attributes tag\r
+ 0x21 integer type value-tag\r
+ 0x0006 name-length\r
+ copies copies name\r
+ 0x0004 value-length\r
+ 0x00000014 20 value\r
+ 0x10 unsupported (type) value-tag\r
+ 0x0005 name-length\r
+ sides sides name\r
+ 0x0000 value-length\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+\r
+13.4 Print-Job Response (success with attributes ignored)\r
+\r
+ Here is an example of a successful Print-Job response to a Print-Job\r
+ request like the previous Print-Job request, except that the value of\r
+ 'ipp-attribute-fidelity' is false. The print request succeeds, even\r
+ though, in this case, the printer supports neither the "sides"\r
+ attribute nor the value '20' for the "copies" attribute. Therefore, a\r
+ job is created, and both a "job-id" and a "job-uri" operation\r
+ attribute are returned. The unsupported attributes are also returned\r
+ in an Unsupported Attributes Group. The error code returned is\r
+ 'successful-ok-ignored-or-substituted-attributes' (0x0001).\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x0001 successful-ok-ignored-or- status-code\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 36]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ substituted-attributes\r
+ 0x00000001 1 request-id\r
+ 0x01 start operation-attributes operation-attributes-tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x0008 value-length\r
+ us-ascii US-ASCII value\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- attributes-natural- name\r
+ natural-language language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x41 textWithoutLanguage type value-tag\r
+ 0x000E name-length\r
+ status-message status-message name\r
+ 0x002F value-length\r
+ successful-ok- successful-ok-ignored-or- value\r
+ ignored-or- substituted-attributes\r
+ substituted-\r
+ attributes\r
+ 0x05 start unsupported- unsupported-attributes\r
+ attributes tag\r
+ 0x21 integer type value-tag\r
+ 0x0006 name-length\r
+ copies copies name\r
+ 0x0004 value-length\r
+ 0x00000014 20 value\r
+ 0x10 unsupported (type) value-tag\r
+ 0x0005 name-length\r
+ sides sides name\r
+ 0x0000 value-length\r
+ 0x02 start job-attributes job-attributes-tag\r
+ 0x21 integer value-tag\r
+ 0x0006 name-length\r
+ job-id job-id name\r
+ 0x0004 value-length\r
+ 147 147 value\r
+ 0x45 uri type value-tag\r
+ 0x0007 name-length\r
+ job-uri job-uri name\r
+ 0x0019 value-length\r
+ ipp://forest/ job 123 on pinetree value\r
+ pinetree/123\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 37]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x23 enum type value-tag\r
+ 0x0009 name-length\r
+ job-state job-state name\r
+ 0x0004 value-length\r
+ 0x0003 pending value\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+\r
+13.5 Print-URI Request\r
+\r
+ The following is an example of Print-URI request with copies and\r
+ job-name parameters:\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x0003 Print-URI operation-id\r
+ 0x00000001 1 request-id\r
+ 0x01 start operation-attributes operation-attributes-tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x0008 value-length\r
+ us-ascii US-ASCII value\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- attributes-natural-language name\r
+ natural-\r
+ language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x45 uri type value-tag\r
+ 0x000B name-length\r
+ printer-uri printer-uri name\r
+ 0x0015 value-length\r
+ ipp://forest/ printer pinetree value\r
+ pinetree\r
+ 0x45 uri type value-tag\r
+ 0x000C name-length\r
+ document-uri document-uri name\r
+ 0x0011 value-length\r
+ ftp://foo.com ftp://foo.com/foo value\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 38]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ /foo\r
+ 0x42 nameWithoutLanguage type value-tag\r
+ 0x0008 name-length\r
+ job-name job-name name\r
+ 0x0006 value-length\r
+ foobar foobar value\r
+ 0x02 start job-attributes job-attributes-tag\r
+ 0x21 integer type value-tag\r
+ 0x0006 name-length\r
+ copies copies name\r
+ 0x0004 value-length\r
+ 0x00000001 1 value\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+\r
+13.6 Create-Job Request\r
+\r
+ The following is an example of Create-Job request with no parameters\r
+ and no attributes:\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x0005 Create-Job operation-id\r
+ 0x00000001 1 request-id\r
+ 0x01 start operation-attributes operation-attributes-tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x0008 value-length\r
+ us-ascii US-ASCII value\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- attributes-natural-language name\r
+ natural-\r
+ language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x45 uri type value-tag\r
+ 0x000B name-length\r
+ printer-uri printer-uri name\r
+ 0x0015 value-length\r
+ ipp://forest/ printer pinetree value\r
+ pinetree\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 39]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ inetree\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+\r
+13.7 Get-Jobs Request\r
+\r
+ The following is an example of Get-Jobs request with parameters but\r
+ no attributes:\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x000A Get-Jobs operation-id\r
+ 0x00000123 0x123 request-id\r
+ 0x01 start operation-attributes operation-attributes-tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x0008 value-length\r
+ us-ascii US-ASCII value\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- attributes-natural-language name\r
+ natural-\r
+ language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x45 uri type value-tag\r
+ 0x000B name-length\r
+ printer-uri printer-uri name\r
+ 0x0015 value-length\r
+ ipp://forest/ printer pinetree value\r
+ pinetree\r
+ 0x21 integer type value-tag\r
+ 0x0005 name-length\r
+ limit limit name\r
+ 0x0004 value-length\r
+ 0x00000032 50 value\r
+ 0x44 keyword type value-tag\r
+ 0x0014 name-length\r
+ requested- requested-attributes name\r
+ attributes\r
+ 0x0006 value-length\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 40]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ job-id job-id value\r
+ 0x44 keyword type value-tag\r
+ 0x0000 additional value name-length\r
+ 0x0008 value-length\r
+ job-name job-name value\r
+ 0x44 keyword type value-tag\r
+ 0x0000 additional value name-length\r
+ 0x000F value-length\r
+ document-format document-format value\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+\r
+13.8 Get-Jobs Response\r
+\r
+ The following is an of Get-Jobs response from previous request with 3\r
+ jobs. The Printer returns no information about the second job\r
+ (because of security reasons):\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ 0x0101 1.1 version-number\r
+ 0x0000 successful-ok status-code\r
+ 0x00000123 0x123 request-id (echoed\r
+ back)\r
+ 0x01 start operation-attributes operation-attributes-tag\r
+ 0x47 charset type value-tag\r
+ 0x0012 name-length\r
+ attributes- attributes-charset name\r
+ charset\r
+ 0x000A value-length\r
+ ISO-8859-1 ISO-8859-1 value\r
+ 0x48 natural-language type value-tag\r
+ 0x001B name-length\r
+ attributes- attributes-natural-language name\r
+ natural-\r
+ language\r
+ 0x0005 value-length\r
+ en-us en-US value\r
+ 0x41 textWithoutLanguage type value-tag\r
+ 0x000E name-length\r
+ status-message status-message name\r
+ 0x000D value-length\r
+ successful-ok successful-ok value\r
+ 0x02 start job-attributes (1st job-attributes-tag\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 41]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Octets Symbolic Value Protocol field\r
+\r
+ object)\r
+ 0x21 integer type value-tag\r
+ 0x0006 name-length\r
+ job-id job-id name\r
+ 0x0004 value-length\r
+ 147 147 value\r
+ 0x36 nameWithLanguage value-tag\r
+ 0x0008 name-length\r
+ job-name job-name name\r
+ 0x000C value-length\r
+ 0x0005 sub-value-length\r
+ fr-ca fr-CA value\r
+ 0x0003 sub-value-length\r
+ fou fou name\r
+ 0x02 start job-attributes (2nd job-attributes-tag\r
+ object)\r
+ 0x02 start job-attributes (3rd job-attributes-tag\r
+ object)\r
+ 0x21 integer type value-tag\r
+ 0x0006 name-length\r
+ job-id job-id name\r
+ 0x0004 value-length\r
+ 148 149 value\r
+ 0x36 nameWithLanguage value-tag\r
+ 0x0008 name-length\r
+ job-name job-name name\r
+ 0x0012 value-length\r
+ 0x0005 sub-value-length\r
+ de-CH de-CH value\r
+ 0x0009 sub-value-length\r
+ isch guet isch guet name\r
+ 0x03 end-of-attributes end-of-attributes-tag\r
+\r
+14. Appendix B: Registration of MIME Media Type Information for\r
+ "application/ipp"\r
+\r
+ This appendix contains the information that IANA requires for\r
+ registering a MIME media type. The information following this\r
+ paragraph will be forwarded to IANA to register application/ipp whose\r
+ contents are defined in Section 3 "Encoding of the Operation Layer"\r
+ in this document:\r
+\r
+ MIME type name: application\r
+\r
+ MIME subtype name: ipp\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 42]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ A Content-Type of "application/ipp" indicates an Internet Printing\r
+ Protocol message body (request or response). Currently there is one\r
+ version: IPP/1.1, whose syntax is described in Section 3 "Encoding of\r
+ the Operation Layer" of [RFC2910], and whose semantics are described\r
+ in [RFC2911].\r
+\r
+ Required parameters: none\r
+\r
+ Optional parameters: none\r
+\r
+ Encoding considerations:\r
+\r
+ IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS\r
+ contain binary data (for example attribute value lengths).\r
+\r
+ Security considerations:\r
+\r
+ IPP/1.1 protocol requests/responses do not introduce any security\r
+ risks not already inherent in the underlying transport protocols.\r
+ Protocol mixed-version interworking rules in [RFC2911] as well as\r
+ protocol encoding rules in [RFC2910] are complete and unambiguous.\r
+\r
+ Interoperability considerations:\r
+\r
+ IPP/1.1 requests (generated by clients) and responses (generated by\r
+ servers) MUST comply with all conformance requirements imposed by the\r
+ normative specifications [RFC2911] and [RFC2910]. Protocol encoding\r
+ rules specified in [RFC2910] are comprehensive, so that\r
+ interoperability between conforming implementations is guaranteed\r
+ (although support for specific optional features is not ensured).\r
+ Both the "charset" and "natural-language" of all IPP/1.1 attribute\r
+ values which are a LOCALIZED-STRING are explicit within IPP protocol\r
+ requests/responses (without recourse to any external information in\r
+ HTTP, SMTP, or other message transport headers).\r
+\r
+ Published specifications:\r
+\r
+ [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.\r
+ Powell, "Internet Printing Protocol/1.1: Model and\r
+ Semantics", RFC 2911, September 2000.\r
+\r
+ [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.\r
+ Wenn, "Internet Printing Protocol/1.1: Encoding and\r
+ Transport", RFC 2910, September 2000.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 43]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ Applications which use this media type:\r
+\r
+ Internet Printing Protocol (IPP) print clients and print servers,\r
+ communicating using HTTP/1.1 (see [RFC2910]), SMTP/ESMTP, FTP, or\r
+ other transport protocol. Messages of type "application/ipp" are\r
+ self-contained and transport-independent, including "charset" and\r
+ "natural-language" context for any LOCALIZED-STRING value.\r
+\r
+ Person & email address to contact for further information:\r
+\r
+ Tom Hastings\r
+ Xerox Corporation\r
+ 737 Hawaii St. ESAE-231\r
+ El Segundo, CA\r
+\r
+ Phone: 310-333-6413\r
+ Fax: 310-333-5514\r
+ EMail: hastings@cp10.es.xerox.com\r
+\r
+ or\r
+\r
+ Robert Herriot\r
+ Xerox Corporation\r
+ 3400 Hillview Ave., Bldg #1\r
+ Palo Alto, CA 94304\r
+\r
+ Phone: 650-813-7696\r
+ Fax: 650-813-6860\r
+ EMail: robert.herriot@pahv.xerox.com\r
+\r
+ Intended usage:\r
+\r
+ COMMON\r
+\r
+15. Appendix C: Changes from IPP/1.0\r
+\r
+ IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:\r
+\r
+ 1. Attributes values that identify a printer or job object use a new\r
+ 'ipp' scheme. The 'http' and 'https' schemes are supported only\r
+ for backward compatibility. See section 5.\r
+\r
+ 2. Clients MUST support of Digest Authentication, IPP Printers SHOULD\r
+ support Digest Authentication. See Section 8.1.1\r
+\r
+ 3. TLS is recommended for channel security. In addition, SSL3 may be\r
+ supported for backward compatibility. See Section 8.1.2\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 44]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+ 4. It is recommended that IPP/1.1 objects accept any request with\r
+ major version number '1'. See section 9.1.\r
+\r
+ 5. IPP objects SHOULD return the URL scheme requested for "job-\r
+ printer-uri" and "job-uri" Job Attributes, rather than the URL\r
+ scheme used to create the job. See section 9.2.\r
+\r
+ 6. The IANA and Internationalization sections have been added. The\r
+ terms "private use" and "experimental" have been changed to\r
+ "vendor extension". The reserved allocations for attribute group\r
+ tags, attribute syntax tags, and out-of-band attribute values have\r
+ been clarified as to which are reserved to future IETF standards\r
+ track documents and which are reserved to vendor extension. Both\r
+ kinds of extensions use the type2 registration procedures as\r
+ defined in [RFC2911].\r
+\r
+ 7. Clarified that future "out-of-band" value definitions may use the\r
+ value field if additional information is needed.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 45]\r
+\f\r
+RFC 2910 IPP/1.1: Encoding and Transport September 2000\r
+\r
+\r
+Full Copyright Statement\r
+\r
+ Copyright (C) The Internet Society (2000). All Rights Reserved.\r
+\r
+ This document and translations of it may be copied and furnished to\r
+ others, and derivative works that comment on or otherwise explain it\r
+ or assist in its implementation may be prepared, copied, published\r
+ and distributed, in whole or in part, without restriction of any\r
+ kind, provided that the above copyright notice and this paragraph are\r
+ included on all such copies and derivative works. However, this\r
+ document itself may not be modified in any way, such as by removing\r
+ the copyright notice or references to the Internet Society or other\r
+ Internet organizations, except as needed for the purpose of\r
+ developing Internet standards in which case the procedures for\r
+ copyrights defined in the Internet Standards process must be\r
+ followed, or as required to translate it into languages other than\r
+ English.\r
+\r
+ The limited permissions granted above are perpetual and will not be\r
+ revoked by the Internet Society or its successors or assigns.\r
+\r
+ This document and the information contained herein is provided on an\r
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+Acknowledgement\r
+\r
+ Funding for the RFC Editor function is currently provided by the\r
+ Internet Society.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Herriot, et al. Standards Track [Page 46]\r
+\f\r
--- /dev/null
+\r
+\r
+\r
+\r
+\r
+\r
+Network Working Group T. Hastings, Editor\r
+Request for Comments: 2911 R. Herriot\r
+Obsoletes: 2566 Xerox Corporation\r
+Category: Standards Track R. deBry\r
+ Utah Valley State College\r
+ S. Isaacson\r
+ Novell, Inc.\r
+ P. Powell\r
+ Astart Technologies\r
+ September 2000\r
+\r
+\r
+ Internet Printing Protocol/1.1: Model and Semantics\r
+\r
+Status of this Memo\r
+\r
+ This document specifies an Internet standards track protocol for the\r
+ Internet community, and requests discussion and suggestions for\r
+ improvements. Please refer to the current edition of the "Internet\r
+ Official Protocol Standards" (STD 1) for the standardization state\r
+ and status of this protocol. Distribution of this memo is unlimited.\r
+\r
+Copyright Notice\r
+\r
+ Copyright (C) The Internet Society (2000). All Rights Reserved.\r
+\r
+Abstract\r
+\r
+ This document is one of a set of documents, which together describe\r
+ all aspects of a new Internet Printing Protocol (IPP). IPP is an\r
+ application level protocol that can be used for distributed printing\r
+ using Internet tools and technologies. This document describes a\r
+ simplified model consisting of abstract objects, their attributes,\r
+ and their operations that is independent of encoding and transport.\r
+ The model consists of a Printer and a Job object. A Job optionally\r
+ supports multiple documents. IPP 1.1 semantics allow end-users and\r
+ operators to query printer capabilities, submit print jobs, inquire\r
+ about the status of print jobs and printers, cancel, hold, release,\r
+ and restart print jobs. IPP 1.1 semantics allow operators to pause,\r
+ resume, and purge (jobs from) Printer objects. This document also\r
+ addresses security, internationalization, and directory issues.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 1]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The full set of IPP documents includes:\r
+\r
+ Design Goals for an Internet Printing Protocol [RFC2567]\r
+ Rationale for the Structure and Model and Protocol for the Internet\r
+ Printing Protocol [RFC2568]\r
+ Internet Printing Protocol/1.1: Model and Semantics (this document)\r
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]\r
+ Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]\r
+ Mapping between LPD and IPP Protocols [RFC2569]\r
+\r
+ The "Design Goals for an Internet Printing Protocol" document takes a\r
+ broad look at distributed printing functionality, and it enumerates\r
+ real-life scenarios that help to clarify the features that need to be\r
+ included in a printing protocol for the Internet. It identifies\r
+ requirements for three types of users: end users, operators, and\r
+ administrators. It calls out a subset of end user requirements that\r
+ are satisfied in IPP/1.0. A few OPTIONAL operator operations have\r
+ been added to IPP/1.1.\r
+\r
+ The "Rationale for the Structure and Model and Protocol for the\r
+ Internet Printing Protocol" document describes IPP from a high level\r
+ view, defines a roadmap for the various documents that form the suite\r
+ of IPP specification documents, and gives background and rationale\r
+ for the IETF working group's major decisions.\r
+\r
+ The "Internet Printing Protocol/1.1: Encoding and Transport" document\r
+ is a formal mapping of the abstract operations and attributes defined\r
+ in the model document onto HTTP/1.1 [RFC2616]. It defines the\r
+ encoding rules for a new Internet MIME media type called\r
+ "application/ipp". This document also defines the rules for\r
+ transporting over HTTP a message body whose Content-Type is\r
+ "application/ipp". This document defines a new scheme named 'ipp'\r
+ for identifying IPP printers and jobs.\r
+\r
+ The "Internet Printing Protocol/1.1: Implementer's Guide" document\r
+ gives insight and advice to implementers of IPP clients and IPP\r
+ objects. It is intended to help them understand IPP/1.1 and some of\r
+ the considerations that may assist them in the design of their client\r
+ and/or IPP object implementations. For example, a typical order of\r
+ processing requests is given, including error checking. Motivation\r
+ for some of the specification decisions is also included.\r
+\r
+ The "Mapping between LPD and IPP Protocols" document gives some\r
+ advice to implementers of gateways between IPP and LPD (Line Printer\r
+ Daemon) implementations.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 2]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+Table of Contents\r
+\r
+ 1. Introduction 9\r
+ 1.1 Simplified Printing Model 10\r
+ 2. IPP Objects 12\r
+ 2.1 Printer Object 13\r
+ 2.2 Job Object 15\r
+ 2.3 Object Relationships 16\r
+ 2.4 Object Identity 17\r
+ 3. IPP Operations 20\r
+ 3.1 Common Semantics 21\r
+ 3.1.1 Required Parameters 21\r
+ 3.1.2 Operation IDs and Request IDs 22\r
+ 3.1.3 Attributes 22\r
+ 3.1.4 Character Set and Natural Language Operation Attribute 24\r
+ 3.1.4.1 Request Operation Attributes 25\r
+ 3.1.4.2 Response Operation Attributes 29\r
+ 3.1.5 Operation Targets 30\r
+ 3.1.6 Operation Response Status Codes and Status Messages 32\r
+ 3.1.6.1 "status-code" (type2 enum) 32\r
+ 3.1.6.2 "status-message" (text(255)) 33\r
+ 3.1.6.3 "detailed-status-message" (text(MAX)) 33\r
+ 3.1.6.4 "document-access-error" (text(MAX)) 34\r
+ 3.1.7 Unsupported Attributes 34\r
+ 3.1.8 Versions 36\r
+ 3.1.9 Job Creation Operations 38\r
+ 3.2 Printer Operations 41\r
+ 3.2.1 Print-Job Operation 41\r
+ 3.2.1.1 Print-Job Request 41\r
+ 3.2.1.2 Print-Job Response 46\r
+ 3.2.2 Print-URI Operation 48\r
+ 3.2.3 Validate-Job Operation 49\r
+ 3.2.4 Create-Job Operation 49\r
+ 3.2.5 Get-Printer-Attributes Operation 50\r
+ 3.2.5.1 Get-Printer-Attributes Request 51\r
+ 3.2.5.2 Get-Printer-Attributes Response 53\r
+ 3.2.6 Get-Jobs Operation 54\r
+ 3.2.6.1 Get-Jobs Request 54\r
+ 3.2.6.2 Get-Jobs Response 56\r
+ 3.2.7 Pause-Printer Operation 57\r
+ 3.2.7.1 Pause-Printer Request 59\r
+ 3.2.7.2 Pause-Printer Response 60\r
+ 3.2.8 Resume-Printer Operation 60\r
+ 3.2.9 Purge-Jobs Operation 61\r
+ 3.3 Job Operations 62\r
+ 3.3.1 Send-Document Operation 62\r
+ 3.3.1.1 Send-Document Request 64\r
+ 3.3.1.2 Send-Document Response 65\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 3]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 3.3.2 Send-URI Operation 66\r
+ 3.3.3 Cancel-Job Operation 66\r
+ 3.3.3.1 Cancel-Job Request 67\r
+ 3.3.3.2 Cancel-Job Response 68\r
+ 3.3.4 Get-Job-Attributes Operation 69\r
+ 3.3.4.1 Get-Job-Attributes Request 69\r
+ 3.3.4.2 Get-Job-Attributes Response 70\r
+ 3.3.5 Hold-Job Operation 71\r
+ 3.3.5.1 Hold-Job Request 72\r
+ 3.3.5.2 Hold-Job Response 73\r
+ 3.3.6 Release-Job Operation 74\r
+ 3.3.7 Restart-Job Operation 75\r
+ 3.3.7.1 Restart-Job Request 76\r
+ 3.3.7.2 Restart-Job Response 78\r
+ 4. Object Attributes 78\r
+ 4.1 Attribute Syntaxes 78\r
+ 4.1.1 'text' 79\r
+ 4.1.1.1 'textWithoutLanguage' 80\r
+ 4.1.1.2 'textWithLanguage' 80\r
+ 4.1.2 'name' 81\r
+ 4.1.2.1 'nameWithoutLanguage' 82\r
+ 4.1.2.2 'nameWithLanguage' 82\r
+ 4.1.2.3 Matching 'name' attribute values 83\r
+ 4.1.3 'keyword' 84\r
+ 4.1.4 'enum' 85\r
+ 4.1.5 'uri' 85\r
+ 4.1.6 'uriScheme' 86\r
+ 4.1.7 'charset' 86\r
+ 4.1.8 'naturalLanguage' 87\r
+ 4.1.9 'mimeMediaType' 87\r
+ 4.1.9.1 Application/octet-stream -- Auto-Sensing 88\r
+ the document format\r
+ 4.1.10 'octetString' 89\r
+ 4.1.11 'boolean' 89\r
+ 4.1.12 'integer' 89\r
+ 4.1.13 'rangeOfInteger' 90\r
+ 4.1.14 'dateTime' 90\r
+ 4.1.15 'resolution' 90\r
+ 4.1.16 '1setOf X' 90\r
+ 4.2 Job Template Attributes 91\r
+ 4.2.1 job-priority (integer(1:100)) 94\r
+ 4.2.2 job-hold-until (type3 keyword | name (MAX)) 95\r
+ 4.2.3 job-sheets (type3 keyword | name(MAX)) 96\r
+ 4.2.4 multiple-document-handling (type2 keyword) 96\r
+ 4.2.5 copies (integer(1:MAX)) 98\r
+ 4.2.6 finishings (1setOf type2 enum) 98\r
+ 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 101\r
+ 4.2.8 sides (type2 keyword) 102\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 4]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 4.2.9 number-up (integer(1:MAX)) 102\r
+ 4.2.10 orientation-requested (type2 enum) 103\r
+ 4.2.11 media (type3 keyword | name(MAX)) 104\r
+ 4.2.12 printer-resolution (resolution) 105\r
+ 4.2.13 print-quality (type2 enum) 105\r
+ 4.3 Job Description Attributes 106\r
+ 4.3.1 job-uri (uri) 107\r
+ 4.3.2 job-id (integer(1:MAX)) 108\r
+ 4.3.3 job-printer-uri (uri) 108\r
+ 4.3.4 job-more-info (uri) 108\r
+ 4.3.5 job-name (name(MAX)) 108\r
+ 4.3.6 job-originating-user-name (name(MAX)) 109\r
+ 4.3.7 job-state (type1 enum) 109\r
+ 4.3.7.1 Forwarding Servers 112\r
+ 4.3.7.2 Partitioning of Job States 112\r
+ 4.3.8 job-state-reasons (1setOf type2 keyword) 113\r
+ 4.3.9 job-state-message (text(MAX)) 118\r
+ 4.3.10 job-detailed-status-messages (1setOf text(MAX)) 118\r
+ 4.3.11 job-document-access-errors (1setOf text(MAX)) 118\r
+ 4.3.12 number-of-documents (integer(0:MAX)) 119\r
+ 4.3.13 output-device-assigned (name(127)) 119\r
+ 4.3.14 Event Time Job Description Attributes 119\r
+ 4.3.14.1 time-at-creation (integer(MIN:MAX)) 120\r
+ 4.3.14.2 time-at-processing (integer(MIN:MAX)) 120\r
+ 4.3.14.3 time-at-completed (integer(MIN:MAX)) 120\r
+ 4.3.14.4 job-printer-up-time (integer(1:MAX)) 120\r
+ 4.3.14.5 date-time-at-creation (dateTime) 121\r
+ 4.3.14.6 date-time-at-processing (dateTime) 121\r
+ 4.3.14.7 date-time-at-completed (dateTime) 121\r
+ 4.3.15 number-of-intervening-jobs (integer(0:MAX)) 121\r
+ 4.3.16 job-message-from-operator (text(127)) 121\r
+ 4.3.17 Job Size Attributes 121\r
+ 4.3.17.1 job-k-octets (integer(0:MAX)) 122\r
+ 4.3.17.2 job-impressions (integer(0:MAX)) 122\r
+ 4.3.17.3 job-media-sheets (integer(0:MAX)) 123\r
+ 4.3.18 Job Progress Attributes 123\r
+ 4.3.18.1 job-k-octets-processed (integer(0:MAX)) 123\r
+ 4.3.18.2 job-impressions-completed (integer(0:MAX)) 123\r
+ 4.3.18.3 job-media-sheets-completed (integer(0:MAX)) 124\r
+ 4.3.19 attributes-charset (charset) 124\r
+ 4.3.20 attributes-natural-language (naturalLanguage) 124\r
+ 4.4 Printer Description Attributes 124\r
+ 4.4.1 printer-uri-supported (1setOf uri) 126\r
+ 4.4.2 uri-authentication-supported (1setOf type2 keyword) 127\r
+ 4.4.3 uri-security-supported (1setOf type2 keyword) 128\r
+ 4.4.4 printer-name (name(127)) 129\r
+ 4.4.5 printer-location (text(127)) 129\r
+ 4.4.6 printer-info (text(127)) 130\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 5]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 4.4.7 printer-more-info (uri) 130\r
+ 4.4.8 printer-driver-installer (uri) 130\r
+ 4.4.9 printer-make-and-model (text(127)) 130\r
+ 4.4.10 printer-more-info-manufacturer (uri) 130\r
+ 4.4.11 printer-state (type1 enum) 131\r
+ 4.4.12 printer-state-reasons (1setOf type2 keyword) 131\r
+ 4.4.13 printer-state-message (text(MAX)) 134\r
+ 4.4.14 ipp-versions-supported (1setOf type2 keyword) 134\r
+ 4.4.15 operations-supported (1setOf type2 enum) 135\r
+ 4.4.16 multiple-document-jobs-supported (boolean) 136\r
+ 4.4.17 charset-configured (charset) 136\r
+ 4.4.18 charset-supported (1setOf charset) 137\r
+ 4.4.19 natural-language-configured (naturalLanguage) 137\r
+ 4.4.20 generated-natural-language-supported\r
+ (1setOf naturalLanguage) 137\r
+ 4.4.21 document-format-default (mimeMediaType) 138\r
+ 4.4.22 document-format-supported (1setOf mimeMediaType) 138\r
+ 4.4.23 printer-is-accepting-jobs (boolean) 138\r
+ 4.4.24 queued-job-count (integer(0:MAX)) 138\r
+ 4.4.25 printer-message-from-operator (text(127)) 139\r
+ 4.4.26 color-supported (boolean) 139\r
+ 4.4.27 reference-uri-schemes-supported (1setOf uriScheme) 139\r
+ 4.4.28 pdl-override-supported (type2 keyword) 139\r
+ 4.4.29 printer-up-time (integer(1:MAX)) 140\r
+ 4.4.30 printer-current-time (dateTime) 140\r
+ 4.4.31 multiple-operation-time-out (integer(1:MAX)) 141\r
+ 4.4.32 compression-supported (1setOf type3 keyword) 141\r
+ 4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX)) 142\r
+ 4.4.34 job-impressions-supported (rangeOfInteger(0:MAX)) 142\r
+ 4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX)) 142\r
+ 4.4.36 pages-per-minute (integer(0:MAX)) 142\r
+ 4.4.37 pages-per-minute-color (integer(0:MAX)) 142\r
+ 5. Conformance 143\r
+ 5.1 Client Conformance Requirements 143\r
+ 5.2 IPP Object Conformance Requirements 145\r
+ 5.2.1 Objects 145\r
+ 5.2.2 Operations 145\r
+ 5.2.3 IPP Object Attributes 146\r
+ 5.2.4 Versions 146\r
+ 5.2.5 Extensions 147\r
+ 5.2.6 Attribute Syntaxes 147\r
+ 5.2.7 Security 148\r
+ 5.3 Charset and Natural Language Requirements 148\r
+ 6. IANA Considerations 148\r
+ 6.1 Typed 'keyword' and 'enum' Extensions 149\r
+ 6.2 Attribute Extensibility 151\r
+ 6.3 Attribute Syntax Extensibility 152\r
+ 6.4 Operation Extensibility 152\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 6]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 6.5 Attribute Group Extensibility 153\r
+ 6.6 Status Code Extensibility 153\r
+ 6.7 Out-of-band Attribute Value Extensibility 154\r
+ 6.8 Registration of MIME types/sub-types for document-formats 154\r
+ 6.9 Registration of charsets for use in 'charset'\r
+ attribute values 154\r
+ 7. Internationalization Considerations 154\r
+ 8. Security Considerations 158\r
+ 8.1 Security Scenarios 159\r
+ 8.1.1 Client and Server in the Same Security Domain 159\r
+ 8.1.2 Client and Server in Different Security Domains 159\r
+ 8.1.3 Print by Reference 160\r
+ 8.2 URIs in Operation, Job, and Printer attributes 160\r
+ 8.3 URIs for each authentication mechanisms 160\r
+ 8.4 Restricted Queries 161\r
+ 8.5 Operations performed by operators and system\r
+ administrators 161\r
+ 8.6 Queries on jobs submitted using non-IPP protocols 162\r
+ 9. References 162\r
+ 10. Authors' Addresses 166\r
+ 11. Formats for IPP Registration Proposals 168\r
+ 11.1 Type2 keyword attribute values registration 169\r
+ 11.2 Type3 keyword attribute values registration 169\r
+ 11.3 Type2 enum attribute values registration 169\r
+ 11.4 Type3 enum attribute values registration 170\r
+ 11.5 Attribute registration 170\r
+ 11.6 Attribute Syntax registration 171\r
+ 11.7 Operation registration 171\r
+ 11.8 Attribute Group registration 171\r
+ 11.9 Status code registration 172\r
+ 11.10 Out-of-band Attribute Value registration 172\r
+ 12. APPENDIX A: Terminology 173\r
+ 12.1 Conformance Terminology 173\r
+ 12.1.1 NEED NOT 173\r
+ 12.2 Model Terminology 173\r
+ 12.2.1 Keyword 173\r
+ 12.2.2 Attributes 173\r
+ 12.2.2.1 Attribute Name 173\r
+ 12.2.2.2 Attribute Group Name 174\r
+ 12.2.2.3 Attribute Value 174\r
+ 12.2.2.4 Attribute Syntax 174\r
+ 12.2.3 Supports 174\r
+ 12.2.4 print-stream page 176\r
+ 12.2.5 impression 177\r
+ 13. APPENDIX B: Status Codes and Suggested Status Code Messages 177\r
+ 13.1 Status Codes 178\r
+ 13.1.1 Informational 178\r
+ 13.1.2 Successful Status Codes 178\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 7]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 13.1.2.1 successful-ok (0x0000) 178\r
+ 13.1.2.2 successful-ok-ignored-or-substituted-attributes\r
+ (0x0001) 179\r
+ 13.1.2.3 successful-ok-conflicting-attributes (0x0002) 179\r
+ 13.1.3 Redirection Status Codes 179\r
+ 13.1.4 Client Error Status Codes 179\r
+ 13.1.4.1 client-error-bad-request (0x0400) 180\r
+ 13.1.4.2 client-error-forbidden (0x0401) 180\r
+ 13.1.4.3 client-error-not-authenticated (0x0402) 180\r
+ 13.1.4.4 client-error-not-authorized (0x0403) 180\r
+ 13.1.4.5 client-error-not-possible (0x0404) 180\r
+ 13.1.4.6 client-error-timeout (0x0405) 181\r
+ 13.1.4.7 client-error-not-found (0x0406) 181\r
+ 13.1.4.8 client-error-gone (0x0407) 181\r
+ 13.1.4.9 client-error-request-entity-too-large (0x0408) 182\r
+ 13.1.4.10 client-error-request-value-too-long (0x0409) 182\r
+ 13.1.4.11 client-error-document-format-not-supported (0x040A) 182\r
+ 13.1.4.12 client-error-attributes-or-values-not-supported\r
+ (0x040B) 183\r
+ 13.1.4.13 client-error-uri-scheme-not-supported (0x040C) 183\r
+ 13.1.4.14 client-error-charset-not-supported (0x040D) 183\r
+ 13.1.4.15 client-error-conflicting-attributes (0x040E) 183\r
+ 13.1.4.16 client-error-compression-not-supported (0x040F) 184\r
+ 13.1.4.17 client-error-compression-error (0x0410) 184\r
+ 13.1.4.18 client-error-document-format-error (0x0411) 184\r
+ 13.1.4.19 client-error-document-access-error (0x0412) 184\r
+ 13.1.5 Server Error Status Codes 185\r
+ 13.1.5.1 server-error-internal-error (0x0500) 185\r
+ 13.1.5.2 server-error-operation-not-supported (0x0501) 185\r
+ 13.1.5.3 server-error-service-unavailable (0x0502) 185\r
+ 13.1.5.4 server-error-version-not-supported (0x0503) 185\r
+ 13.1.5.5 server-error-device-error (0x0504) 186\r
+ 13.1.5.6 server-error-temporary-error (0x0505) 186\r
+ 13.1.5.7 server-error-not-accepting-jobs (0x0506) 187\r
+ 13.1.5.8 server-error-busy (0x0507) 187\r
+ 13.1.5.9 server-error-job-canceled (0x0508) 187\r
+ 13.1.5.10 server-error-multiple-document-jobs-not-supported\r
+ (0x0509) 187\r
+ 13.2 Status Codes for IPP Operations 187\r
+ 14. APPENDIX C: "media" keyword values 190\r
+ 15. APPENDIX D: Processing IPP Attributes 208\r
+ 15.1 Fidelity 209\r
+ 15.2 Page Description Language (PDL) Override 210\r
+ 15.3 Using Job Template Attributes During Document Processing 212\r
+ 16. APPENDIX E: Generic Directory Schema 214\r
+ 17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1\r
+ "Model and Semantics" Documents 215\r
+ 18. Full Copyright Statement 224\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 8]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+1. Introduction\r
+\r
+ The Internet Printing Protocol (IPP) is an application level protocol\r
+ that can be used for distributed printing using Internet tools and\r
+ technologies. IPP version 1.1 (IPP/1.1) focuses primarily on end\r
+ user functionality with a few administrative operations included.\r
+ This document is just one of a suite of documents that fully define\r
+ IPP. The full set of IPP documents includes:\r
+\r
+ Design Goals for an Internet Printing Protocol [RFC2567]\r
+ Rationale for the Structure and Model and Protocol for the Internet\r
+ Printing Protocol [RFC2568]\r
+ Internet Printing Protocol/1.1: Model and Semantics (this document)\r
+ Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]\r
+ Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]\r
+ Mapping between LPD and IPP Protocols [RFC2569]\r
+\r
+ Anyone reading these documents for the first time is strongly\r
+ encouraged to read the IPP documents in the above order.\r
+\r
+ This document is laid out as follows:\r
+\r
+ - The rest of Section 1 is an introduction to the IPP simplified\r
+ model for distributed printing.\r
+ - Section 2 introduces the object types covered in the model with\r
+ their basic behaviors, attributes, and interactions.\r
+ - Section 3 defines the operations included in IPP/1.1. IPP\r
+ operations are synchronous, therefore, for each operation, there is\r
+ a both request and a response.\r
+ - Section 4 defines the attributes (and their syntaxes) that are used\r
+ in the model.\r
+ - Sections 5 - 6 summarizes the implementation conformance\r
+ requirements for objects that support the protocol and IANA\r
+ considerations, respectively.\r
+ - Sections 7 - 11 cover the Internationalization and Security\r
+ considerations as well as References, Author contact information,\r
+ and Formats for Registration Proposals.\r
+ - Sections 12 - 14 are appendices that cover Terminology, Status\r
+ Codes and Messages, and "media" keyword values.\r
+\r
+ Note: This document uses terms such as "attributes", "keywords",\r
+ and "support". These terms have special meaning and are defined\r
+ in the model terminology section 12.2. Capitalized terms, such\r
+ as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT,\r
+ and OPTIONAL, have special meaning relating to conformance.\r
+ These terms are defined in section 12.1 on conformance\r
+ terminology, most of which is taken from RFC 2119 [RFC2119].\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 9]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - Section 15 is an appendix that helps to clarify the effects of\r
+ interactions between related attributes and their values.\r
+ - Section 16 is an appendix that enumerates the subset of Printer\r
+ attributes that form a generic directory schema. These attributes\r
+ are useful when registering a Printer so that a client can find the\r
+ Printer not just by name, but by filtered searches as well.\r
+ - Section 17 is an appendix summarizing the additions and changes\r
+ from the IPP/1.0 "Model and Semantics" document [RFC2566] to make\r
+ this IPP/1.1 document.\r
+ - Section 18 is the full copyright notice.\r
+\r
+1.1 Simplified Printing Model\r
+\r
+ In order to achieve its goal of realizing a workable printing\r
+ protocol for the Internet, the Internet Printing Protocol (IPP) is\r
+ based on a simplified printing model that abstracts the many\r
+ components of real world printing solutions. The Internet is a\r
+ distributed computing environment where requesters of print services\r
+ (clients, applications, printer drivers, etc.) cooperate and interact\r
+ with print service providers. This model and semantics document\r
+ describes a simple, abstract model for IPP even though the underlying\r
+ configurations may be complex "n-tier" client/server systems. An\r
+ important simplifying step in the IPP model is to expose only the key\r
+ objects and interfaces required for printing. The model described in\r
+ this model document does not include features, interfaces, and\r
+ relationships that are beyond the scope of the first version of IPP\r
+ (IPP/1.1). IPP/1.1 incorporates many of the relevant ideas and\r
+ lessons learned from other specification and development efforts\r
+ [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP]. IPP is\r
+ heavily influenced by the printing model introduced in the Document\r
+ Printing Application (DPA) [ISO10175] standard. Although DPA\r
+ specifies both end user and administrative features, IPP version 1.1\r
+ (IPP/1.1) focuses primarily on end user functionality with a few\r
+ additional OPTIONAL operator operations.\r
+\r
+ The IPP/1.1 model encapsulates the important components of\r
+ distributed printing into two object types:\r
+\r
+ - Printer (Section 2.1)\r
+ - Job (Section 2.2)\r
+\r
+ Each object type has an associated set of operations (see section 3)\r
+ and attributes (see section 4).\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 10]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ It is important, however, to understand that in real system\r
+ implementations (which lie underneath the abstracted IPP/1.1 model),\r
+ there are other components of a print service which are not\r
+ explicitly defined in the IPP/1.1 model. The following figure\r
+ illustrates where IPP/1.1 fits with respect to these other\r
+ components.\r
+\r
+ +--------------+\r
+ | Application |\r
+ o +. . . . . . . |\r
+ \|/ | Spooler |\r
+ / \ +. . . . . . . | +---------+\r
+ End-User | Print Driver |---| File |\r
+ +-----------+ +-----+ +------+-------+ +----+----+\r
+ | Browser | | GUI | | |\r
+ +-----+-----+ +--+--+ | |\r
+ | | | |\r
+ | +---+------------+---+ |\r
+ N D S | | IPP Client |------------+\r
+ O I E | +---------+----------+\r
+ T R C | |\r
+ I E U |\r
+ F C R -------------- Transport ------------------\r
+ I T I\r
+ C O T | --+\r
+ A R Y +--------+--------+ |\r
+ T Y | IPP Server | |\r
+ I +--------+--------+ |\r
+ O | |\r
+ N +-----------------+ | IPP Printer\r
+ | Print Service | |\r
+ +-----------------+ |\r
+ | --+\r
+ +-----------------+\r
+ | Output Device(s)|\r
+ +-----------------+\r
+\r
+ An IPP Printer object encapsulates the functions normally associated\r
+ with physical output devices along with the spooling, scheduling and\r
+ multiple device management functions often associated with a print\r
+ server. Printer objects are optionally registered as entries in a\r
+ directory where end users find and select them based on some sort of\r
+ filtered and context based searching mechanism (see section 16). The\r
+ directory is used to store relatively static information about the\r
+ Printer, allowing end users to search for and find Printers that\r
+ match their search criteria, for example: name, context, printer\r
+ capabilities, etc. The more dynamic information, such as state,\r
+ currently loaded and ready media, number of jobs at the Printer,\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 11]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ errors, warnings, and so forth, is directly associated with the\r
+ Printer object itself rather than with the entry in the directory\r
+ which only represents the Printer object.\r
+\r
+ IPP clients implement the IPP protocol on the client side and give\r
+ end users (or programs running on behalf of end users) the ability to\r
+ query Printer objects and submit and manage print jobs. An IPP\r
+ server is just that part of the Printer object that implements the\r
+ server-side protocol. The rest of the Printer object implements (or\r
+ gateways into) the application semantics of the print service itself.\r
+ The Printer objects may be embedded in an output device or may be\r
+ implemented on a host on the network that communicates with an output\r
+ device.\r
+\r
+ When a job is submitted to the Printer object and the Printer object\r
+ validates the attributes in the submission request, the Printer\r
+ object creates a new Job object. The end user then interacts with\r
+ this new Job object to query its status and monitor the progress of\r
+ the job. An end user can also cancel their print jobs by using the\r
+ Job object's Cancel-Job operation. An end-user can also hold,\r
+ release, and restart their print jobs using the Job object's OPTIONAL\r
+ Hold-Job, Release-Job, and Restart-Job operations, if implemented.\r
+\r
+ A privileged operator or administrator of a Printer object can\r
+ cancel, hold, release, and restart any user's job using the REQUIRED\r
+ Cancel-Job and the OPTIONAL Hold-Job, Release-Job, and Restart-Job\r
+ operations. In additional privileged operator or administrator of a\r
+ Printer object can pause, resume, or purge (jobs from) a Printer\r
+ object using the OPTIONAL Pause-Printer, Resume-Printer, and Purge-\r
+ Jobs operations, if implemented.\r
+\r
+ The notification service is out of scope for this IPP/1.1 document,\r
+ but using such a notification service, the end user is able to\r
+ register for and receive Printer specific and Job specific events.\r
+ An end user can query the status of Printer objects and can follow\r
+ the progress of Job objects by polling using the Get-Printer-\r
+ Attributes, Get-Jobs, and Get-Job-Attributes operations.\r
+\r
+2. IPP Objects\r
+\r
+ The IPP/1.1 model introduces objects of type Printer and Job. Each\r
+ type of object models relevant aspects of a real-world entity such as\r
+ a real printer or real print job. Each object type is defined as a\r
+ set of possible attributes that may be supported by instances of that\r
+ object type. For each object (instance), the actual set of supported\r
+ attributes and values describe a specific implementation. The\r
+ object's attributes and values describe its state, capabilities,\r
+ realizable features, job processing functions, and default behaviors\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 12]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ and characteristics. For example, the Printer object type is defined\r
+ as a set of attributes that each Printer object potentially supports.\r
+ In the same manner, the Job object type is defined as a set of\r
+ attributes that are potentially supported by each Job object.\r
+\r
+ Each attribute included in the set of attributes defining an object\r
+ type is labeled as:\r
+\r
+ - "REQUIRED": each object MUST support the attribute.\r
+ - "RECOMMENDED": each object SHOULD support the attribute.\r
+ - "OPTIONAL": each object MAY support the attribute.\r
+\r
+ Some definitions of attribute values indicate that an object MUST or\r
+ SHOULD support the value; otherwise, support of the value is\r
+ OPTIONAL.\r
+\r
+ However, if an implementation supports an attribute, it MUST support\r
+ at least one of the possible values for that attribute.\r
+\r
+2.1 Printer Object\r
+\r
+ The major component of the IPP/1.1 model is the Printer object. A\r
+ Printer object implements the server-side of the IPP/1.1 protocol.\r
+ Using the protocol, end users may query the attributes of the Printer\r
+ object and submit print jobs to the Printer object. The actual\r
+ implementation components behind the Printer abstraction may take on\r
+ different forms and different configurations. However, the model\r
+ abstraction allows the details of the configuration of real\r
+ components to remain opaque to the end user. Section 3 describes\r
+ each of the Printer operations in detail.\r
+\r
+ The capabilities and state of a Printer object are described by its\r
+ attributes. Printer attributes are divided into two groups:\r
+\r
+ - "job-template" attributes: These attributes describe supported job\r
+ processing capabilities and defaults for the Printer object. (See\r
+ section 4.2)\r
+ - "printer-description" attributes: These attributes describe the\r
+ Printer object's identification, state, location, references to\r
+ other sources of information about the Printer object, etc. (see\r
+ section 4.4)\r
+\r
+ Since a Printer object is an abstraction of a generic document output\r
+ device and print service provider, a Printer object could be used to\r
+ represent any real or virtual device with semantics consistent with\r
+ the Printer object, such as a fax device, an imager, or even a CD\r
+ writer.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 13]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Some examples of configurations supporting a Printer object include:\r
+\r
+ 1) An output device with no spooling capabilities\r
+ 2) An output device with a built-in spooler\r
+ 3) A print server supporting IPP with one or more associated\r
+ output devices\r
+ 3a) The associated output devices may or may not be capable of\r
+ spooling jobs\r
+ 3b) The associated output devices may or may not support IPP\r
+\r
+ The following figures show some examples of how Printer objects can\r
+ be realized on top of various distributed printing configurations.\r
+ The embedded case below represents configurations 1 and 2. The hosted\r
+ and fan-out figures below represent configurations 3a and 3b.\r
+\r
+ In this document the term "client" refers to a software entity that\r
+ sends IPP operation requests to an IPP Printer object and accepts IPP\r
+ operation responses. A client MAY be:\r
+\r
+ 1. contained within software controlled by an end user, e.g.\r
+ activated by the "Print" menu item in an application or\r
+\r
+ 2. the print server component that sends IPP requests to either an\r
+ output device or another "downstream" print server.\r
+\r
+ The term "IPP Printer" is a network entity that accepts IPP operation\r
+ requests and returns IPP operation responses. As such, an IPP object\r
+ MAY be:\r
+\r
+ 1. an (embedded) device component that accepts IPP requests and\r
+ controls the device or\r
+\r
+ 2. a component of a print server that accepts IPP requests (where\r
+ the print server controls one or more networked devices using\r
+ IPP or other protocols).\r
+\r
+ Legend:\r
+\r
+ ##### indicates a Printer object which is\r
+ either embedded in an output device or is\r
+ hosted in a server. The Printer object\r
+ might or might not be capable of queuing/spooling.\r
+\r
+ any indicates any network protocol or direct\r
+ connect, including IPP\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 14]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ embedded printer:\r
+ output device\r
+ +---------------+\r
+ O +--------+ | ########### |\r
+ /|\ | client |------------IPP------------># Printer # |\r
+ / \ +--------+ | # Object # |\r
+ | ########### |\r
+ +---------------+\r
+\r
+ hosted printer:\r
+ +---------------+\r
+ O +--------+ ########### | |\r
+ /|\ | client |--IPP--># Printer #-any->| output device |\r
+ / \ +--------+ # Object # | |\r
+ ########### +---------------+\r
+\r
+\r
+ +---------------+\r
+ fan out: | |\r
+ +-->| output device |\r
+ any/ | |\r
+ O +--------+ ########### / +---------------+\r
+ /|\ | client |-IPP-># Printer #--*\r
+ / \ +--------+ # Object # \ +---------------+\r
+ ########### any\ | |\r
+ +-->| output device |\r
+ | |\r
+ +---------------+\r
+\r
+2.2 Job Object\r
+\r
+ A Job object is used to model a print job. A Job object contains\r
+ documents. The information required to create a Job object is sent\r
+ in a create request from the end user via an IPP Client to the\r
+ Printer object. The Printer object validates the create request, and\r
+ if the Printer object accepts the request, the Printer object creates\r
+ the new Job object. Section 3 describes each of the Job operations\r
+ in detail.\r
+\r
+ The characteristics and state of a Job object are described by its\r
+ attributes. Job attributes are grouped into two groups as follows:\r
+\r
+ - "job-template" attributes: These attributes can be supplied by\r
+ the client or end user and include job processing instructions\r
+ which are intended to override any Printer object defaults\r
+ and/or instructions embedded within the document data. (See\r
+ section 4.2)\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 15]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - "job-description" attributes: These attributes describe the Job\r
+ object's identification, state, size, etc. The client supplies\r
+ some of these attributes, and the Printer object generates\r
+ others. (See section 4.3)\r
+\r
+ An implementation MUST support at least one document per Job object.\r
+ An implementation MAY support multiple documents per Job object. A\r
+ document is either:\r
+\r
+ - a stream of document data in a format supported by the Printer\r
+ object (typically a Page Description Language - PDL), or\r
+ - a reference to such a stream of document data\r
+\r
+ In IPP/1.1, a document is not modeled as an IPP object, therefore it\r
+ has no object identifier or associated attributes. All job\r
+ processing instructions are modeled as Job object attributes. These\r
+ attributes are called Job Template attributes and they apply equally\r
+ to all documents within a Job object.\r
+\r
+2.3 Object Relationships\r
+\r
+ IPP objects have relationships that are maintained persistently along\r
+ with the persistent storage of the object attributes.\r
+\r
+ A Printer object can represent either one or more physical output\r
+ devices or a logical device which "processes" jobs but never actually\r
+ uses a physical output device to put marks on paper. Examples of\r
+ logical devices include a Web page publisher or a gateway into an\r
+ online document archive or repository. A Printer object contains\r
+ zero or more Job objects.\r
+\r
+ A Job object is contained by exactly one Printer object, however the\r
+ identical document data associated with a Job object could be sent to\r
+ either the same or a different Printer object. In this case, a\r
+ second Job object would be created which would be almost identical to\r
+ the first Job object, however it would have new (different) Job\r
+ object identifiers (see section 2.4).\r
+\r
+ A Job object is either empty (before any documents have been added)\r
+ or contains one or more documents. If the contained document is a\r
+ stream of document data, that stream can be contained in only one\r
+ document. However, there can be identical copies of the stream in\r
+ other documents in the same or different Job objects. If the\r
+ contained document is just a reference to a stream of document data,\r
+ other documents (in the same or different Job object(s)) may contain\r
+ the same reference.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 16]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+2.4 Object Identity\r
+\r
+ All Printer and Job objects are identified by a Uniform Resource\r
+ Identifier (URI) [RFC2396] so that they can be persistently and\r
+ unambiguously referenced. Since every URL is a specialized form of a\r
+ URI, even though the more generic term URI is used throughout the\r
+ rest of this document, its usage is intended to cover the more\r
+ specific notion of URL as well.\r
+\r
+ An administrator configures Printer objects to either support or not\r
+ support authentication and/or message privacy using Transport Layer\r
+ Security (TLS) [RFC2246] (the mechanism for security configuration is\r
+ outside the scope of this IPP/1.1 document). In some situations,\r
+ both types of connections (both authenticated and unauthenticated)\r
+ can be established using a single communication channel that has some\r
+ sort of negotiation mechanism. In other situations, multiple\r
+ communication channels are used, one for each type of security\r
+ configuration. Section 8 provides a full description of all security\r
+ considerations and configurations.\r
+\r
+ If a Printer object supports more than one communication channel,\r
+ some or all of those channels might support and/or require different\r
+ security mechanisms. In such cases, an administrator could expose\r
+ the simultaneous support for these multiple communication channels as\r
+ multiple URIs for a single Printer object where each URI represents\r
+ one of the communication channels to the Printer object. To support\r
+ this flexibility, the IPP Printer object type defines a multi-valued\r
+ identification attribute called the "printer-uri-supported"\r
+ attribute. It MUST contain at least one URI. It MAY contain more\r
+ than one URI. That is, every Printer object will have at least one\r
+ URI that identifies at least one communication channel to the Printer\r
+ object, but it may have more than one URI where each URI identifies a\r
+ different communication channel to the Printer object. The\r
+ "printer-uri-supported" attribute has two companion attributes, the\r
+ "uri-security-supported" attribute and the "uri-authentication-\r
+ supported". Both have the same cardinality as "printer-uri-\r
+ supported". The purpose of the "uri-security-supported" attribute is\r
+ to indicate the security mechanisms (if any) used for each URI listed\r
+ in "printer-uri-supported". The purpose of the "uri-authentication-\r
+ supported" attribute is to indicate the authentication mechanisms (if\r
+ any) used for each URI listed in "printer-uri-supported". These\r
+ three attributes are fully described in sections 4.4.1, 4.4.2, and\r
+ 4.4.3.\r
+\r
+ When a job is submitted to the Printer object via a create request,\r
+ the client supplies only a single Printer object URI. The client\r
+ supplied Printer object URI MUST be one of the values in the\r
+ "printer-uri-supported" Printer attribute.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 17]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ IPP/1.1 does not specify how the client obtains the client supplied\r
+ URI, but it is RECOMMENDED that a Printer object be registered as an\r
+ entry in a directory service. End-users and programs can then\r
+ interrogate the directory searching for Printers. Section 16 defines\r
+ a generic schema for Printer object entries in the directory service\r
+ and describes how the entry acts as a bridge to the actual IPP\r
+ Printer object. The entry in the directory that represents the IPP\r
+ Printer object includes the possibly many URIs for that Printer\r
+ object as values in one its attributes.\r
+\r
+ When a client submits a create request to the Printer object, the\r
+ Printer object validates the request and creates a new Job object.\r
+ The Printer object assigns the new Job object a URI which is stored\r
+ in the "job-uri" Job attribute. This URI is then used by clients as\r
+ the target for subsequent Job operations. The Printer object\r
+ generates a Job URI based on its configured security policy and the\r
+ URI used by the client in the create request.\r
+\r
+ For example, consider a Printer object that supports both a\r
+ communication channel secured by the use of SSL3 (using HTTP over\r
+ SSL3 with an "https" schemed URI) and another open communication\r
+ channel that is not secured with SSL3 (using a simple "http" schemed\r
+ URI). If a client were to submit a job using the secure URI, the\r
+ Printer object would assign the new Job object a secure URI as well.\r
+ If a client were to submit a job using the open-channel URI, the\r
+ Printer would assign the new Job object an open-channel URI.\r
+\r
+ In addition, the Printer object also populates the Job object's\r
+ "job-printer-uri" attribute. This is a reference back to the Printer\r
+ object that created the Job object. If a client only has access to a\r
+ Job object's "job-uri" identifier, the client can query the Job's\r
+ "job-printer-uri" attribute in order to determine which Printer\r
+ object created the Job object. If the Printer object supports more\r
+ than one URI, the Printer object picks the one URI supplied by the\r
+ client when creating the job to build the value for and to populate\r
+ the Job's "job-printer-uri" attribute.\r
+\r
+ Allowing Job objects to have URIs allows for flexibility and\r
+ scalability. For example, in some implementations, the Printer\r
+ object might create Jobs that are processed in the same local\r
+ environment as the Printer object itself. In this case, the Job URI\r
+ might just be a composition of the Printer's URI and some unique\r
+ component for the Job object, such as the unique 32-bit positive\r
+ integer mentioned later in this paragraph. In other implementations,\r
+ the Printer object might be a central clearing-house for validating\r
+ all Job object creation requests, but the Job object itself might be\r
+ created in some environment that is remote from the Printer object.\r
+ In this case, the Job object's URI may have no physical-location\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 18]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ relationship at all to the Printer object's URI. Again, the fact\r
+ that Job objects have URIs allows for flexibility and scalability,\r
+ however, many existing printing systems have local models or\r
+ interface constraints that force print jobs to be identified using\r
+ only a 32-bit positive integer rather than an independent URI. This\r
+ numeric Job ID is only unique within the context of the Printer\r
+ object to which the create request was originally submitted.\r
+ Therefore, in order to allow both types of client access to IPP Job\r
+ objects (either by Job URI or by numeric Job ID), when the Printer\r
+ object successfully processes a create request and creates a new Job\r
+ object, the Printer object MUST generate both a Job URI and a Job ID.\r
+ The Job ID (stored in the "job-id" attribute) only has meaning in the\r
+ context of the Printer object to which the create request was\r
+ originally submitted. This requirement to support both Job URIs and\r
+ Job IDs allows all types of clients to access Printer objects and Job\r
+ objects no matter the local constraints imposed on the client\r
+ implementation.\r
+\r
+ In addition to identifiers, Printer objects and Job objects have\r
+ names ("printer-name" and "job-name"). An object name NEED NOT be\r
+ unique across all instances of all objects. A Printer object's name\r
+ is chosen and set by an administrator through some mechanism outside\r
+ the scope of this IPP/1.1 document. A Job object's name is\r
+ optionally chosen and supplied by the IPP client submitting the job.\r
+ If the client does not supply a Job object name, the Printer object\r
+ generates a name for the new Job object. In all cases, the name only\r
+ has local meaning.\r
+\r
+ To summarize:\r
+\r
+ - Each Printer object is identified with one or more URIs. The\r
+ Printer's "printer-uri-supported" attribute contains the URI(s).\r
+ - The Printer object's "uri-security-supported" attribute\r
+ identifies the communication channel security protocols that may\r
+ or may not have been configured for the various Printer object\r
+ URIs (e.g., 'tls' or 'none').\r
+ - The Printer object's "uri-authentication-supported" attribute\r
+ identifies the authentication mechanisms that may or may not\r
+ have been configured for the various Printer object URIs (e.g.,\r
+ 'digest' or 'none').\r
+ - Each Job object is identified with a Job URI. The Job's "job-\r
+ uri" attribute contains the URI.\r
+ - Each Job object is also identified with Job ID which is a 32-\r
+ bit, positive integer. The Job's "job-id" attribute contains\r
+ the Job ID. The Job ID is only unique within the context of the\r
+ Printer object which created the Job object.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 19]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - Each Job object has a "job-printer-uri" attribute which contains\r
+ the URI of the Printer object that was used to create the Job\r
+ object. This attribute is used to determine the Printer object\r
+ that created a Job object when given only the URI for the Job\r
+ object. This linkage is necessary to determine the languages,\r
+ charsets, and operations which are supported on that Job (the\r
+ basis for such support comes from the creating Printer object).\r
+ - Each Printer object has a name (which is not necessarily\r
+ unique). The administrator chooses and sets this name through\r
+ some mechanism outside the scope of this IPP/1.1 document. The\r
+ Printer object's "printer-name" attribute contains the name.\r
+ - Each Job object has a name (which is not necessarily unique).\r
+ The client optionally supplies this name in the create request.\r
+ If the client does not supply this name, the Printer object\r
+ generates a name for the Job object. The Job object's "job-name"\r
+ attribute contains the name.\r
+\r
+3. IPP Operations\r
+\r
+ IPP objects support operations. An operation consists of a request\r
+ and a response. When a client communicates with an IPP object, the\r
+ client issues an operation request to the URI for that object.\r
+ Operation requests and responses have parameters that identify the\r
+ operation. Operations also have attributes that affect the run-time\r
+ characteristics of the operation (the intended target, localization\r
+ information, etc.). These operation-specific attributes are called\r
+ operation attributes (as compared to object attributes such as\r
+ Printer object attributes or Job object attributes). Each request\r
+ carries along with it any operation attributes, object attributes,\r
+ and/or document data required to perform the operation. Each request\r
+ requires a response from the object. Each response indicates success\r
+ or failure of the operation with a status code as a response\r
+ parameter. The response contains any operation attributes, object\r
+ attributes, and/or status messages generated during the execution of\r
+ the operation request.\r
+\r
+ This section describes the semantics of the IPP operations, both\r
+ requests and responses, in terms of the parameters, attributes, and\r
+ other data associated with each operation.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 20]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The IPP/1.1 Printer operations are:\r
+\r
+ Print-Job (section 3.2.1)\r
+ Print-URI (section 3.2.2)\r
+ Validate-Job (section 3.2.3)\r
+ Create-Job (section 3.2.4)\r
+ Get-Printer-Attributes (section 3.2.5)\r
+ Get-Jobs (section 3.2.6)\r
+ Pause-Printer (section 3.3.5)\r
+ Resume-Printer (section 3.3.6)\r
+ Purge-Jobs (section 3.3.7)\r
+\r
+ The Job operations are:\r
+\r
+ Send-Document (section 3.3.1)\r
+ Send-URI (section 3.3.2)\r
+ Cancel-Job (section 3.3.3)\r
+ Get-Job-Attributes (section 3.3.4)\r
+ Hold-Job (section 3.3.5)\r
+ Release-Job (section 3.3.6)\r
+ Restart-Job (section 3.3.7)\r
+\r
+ The Send-Document and Send-URI Job operations are used to add a new\r
+ document to an existing multi-document Job object created using the\r
+ Create-Job operation.\r
+\r
+3.1 Common Semantics\r
+\r
+ All IPP operations require some common parameters and operation\r
+ attributes. These common elements and their semantic characteristics\r
+ are defined and described in more detail in the following sections.\r
+\r
+3.1.1 Required Parameters\r
+\r
+ Every operation request contains the following REQUIRED parameters:\r
+\r
+ - a "version-number",\r
+ - an "operation-id",\r
+ - a "request-id", and\r
+ - the attributes that are REQUIRED for that type of request.\r
+\r
+ Every operation response contains the following REQUIRED parameters:\r
+\r
+ - a "version-number",\r
+ - a "status-code",\r
+ - the "request-id" that was supplied in the corresponding request,\r
+ and\r
+ - the attributes that are REQUIRED for that type of response.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 21]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The "Encoding and Transport" document [RFC2910] defines special rules\r
+ for the encoding of these parameters. All other operation elements\r
+ are represented using the more generic encoding rules for attributes\r
+ and groups of attributes.\r
+\r
+3.1.2 Operation IDs and Request IDs\r
+\r
+ Each IPP operation request includes an identifying "operation-id"\r
+ value. Valid values are defined in the "operations-supported"\r
+ Printer attribute section (see section 4.4.15). The client specifies\r
+ which operation is being requested by supplying the correct\r
+ "operation-id" value.\r
+\r
+ In addition, every invocation of an operation is identified by a\r
+ "request-id" value. For each request, the client chooses the\r
+ "request-id" which MUST be an integer (possibly unique depending on\r
+ client requirements) in the range from 1 to 2**31 - 1 (inclusive).\r
+ This "request-id" allows clients to manage multiple outstanding\r
+ requests. The receiving IPP object copies all 32-bits of the client-\r
+ supplied "request-id" attribute into the response so that the client\r
+ can match the response with the correct outstanding request, even if\r
+ the "request-id" is out of range. If the request is terminated\r
+ before the complete "request-id" is received, the IPP object rejects\r
+ the request and returns a response with a "request-id" of 0.\r
+\r
+ Note: In some cases, the transport protocol underneath IPP might be a\r
+ connection oriented protocol that would make it impossible for a\r
+ client to receive responses in any order other than the order in\r
+ which the corresponding requests were sent. In such cases, the\r
+ "request-id" attribute would not be essential for correct protocol\r
+ operation. However, in other mappings, the operation responses can\r
+ come back in any order. In these cases, the "request-id" would be\r
+ essential.\r
+\r
+3.1.3 Attributes\r
+\r
+ Operation requests and responses are both composed of groups of\r
+ attributes and/or document data. The attributes groups are:\r
+\r
+ - Operation Attributes: These attributes are passed in the\r
+ operation and affect the IPP object's behavior while processing\r
+ the operation request and may affect other attributes or groups\r
+ of attributes. Some operation attributes describe the document\r
+ data associated with the print job and are associated with new\r
+ Job objects, however most operation attributes do not persist\r
+ beyond the life of the operation. The description of each\r
+ operation attribute includes conformance statements indicating\r
+ which operation attributes are REQUIRED and which are OPTIONAL\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 22]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ for an IPP object to support and which attributes a client MUST\r
+ supply in a request and an IPP object MUST supply in a response.\r
+ - Job Template Attributes: These attributes affect the processing\r
+ of a job. A client OPTIONALLY supplies Job Template Attributes\r
+ in a create request, and the receiving object MUST be prepared\r
+ to receive all supported attributes. The Job object can later\r
+ be queried to find out what Job Template attributes were\r
+ originally requested in the create request, and such attributes\r
+ are returned in the response as Job Object Attributes. The\r
+ Printer object can be queried about its Job Template attributes\r
+ to find out what type of job processing capabilities are\r
+ supported and/or what the default job processing behaviors are,\r
+ though such attributes are returned in the response as Printer\r
+ Object Attributes. The "ipp-attribute-fidelity" operation\r
+ attribute affects processing of all client-supplied Job Template\r
+ attributes (see sections 3.2.1.2 and 15 for a full description\r
+ of "ipp-attribute-fidelity" and its relationship to other\r
+ attributes).\r
+ - Job Object Attributes: These attributes are returned in response\r
+ to a query operation directed at a Job object.\r
+ - Printer Object Attributes: These attributes are returned in\r
+ response to a query operation directed at a Printer object.\r
+ - Unsupported Attributes: In a create request, the client supplies\r
+ a set of Operation and Job Template attributes. If any of these\r
+ attributes or their values is unsupported by the Printer object,\r
+ the Printer object returns the set of unsupported attributes in\r
+ the response. Sections 3.1.7, 3.2.1.2, and 15 give a full\r
+ description of how Job Template attributes supplied by the\r
+ client in a create request are processed by the Printer object\r
+ and how unsupported attributes are returned to the client.\r
+ Because of extensibility, any IPP object might receive a request\r
+ that contains new or unknown attributes or values for which it\r
+ has no support. In such cases, the IPP object processes what it\r
+ can and returns the unsupported attributes in the response. The\r
+ Unsupported Attribute group is defined for all operation\r
+ responses for returning unsupported attributes that the client\r
+ supplied in the request.\r
+\r
+ Later in this section, each operation is formally defined by\r
+ identifying the allowed and expected groups of attributes for each\r
+ request and response. The model identifies a specific order for each\r
+ group in each request or response, but the attributes within each\r
+ group may be in any order, unless specified otherwise.\r
+\r
+ The attributes within a group MUST be unique; if an attribute with\r
+ the same name occurs more than once, the group is mal-formed.\r
+ Clients MUST NOT submit such malformed requests and Printers MUST NOT\r
+ return such malformed responses. If such a malformed request is\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 23]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ submitted to a Printer, the Printer MUST either (1) reject the\r
+ request with the 'client-error-bad-request' status code (see section\r
+ 13.1.4.1) or (2) process the request normally after selecting only\r
+ one of the attribute instances, depending on implementation. Which\r
+ attribute is selected when there are duplicate attributes depends on\r
+ implementation. The IPP Printer MUST NOT use the values from more\r
+ than one such duplicate attribute instance.\r
+\r
+ Each attribute definition includes the attribute's name followed by\r
+ the name of its attribute syntax(es) in parenthesizes. In addition,\r
+ each 'integer' attribute is followed by the allowed range in\r
+ parentheses, (m:n), for values of that attribute. Each 'text' or\r
+ 'name' attribute is followed by the maximum size in octets in\r
+ parentheses, (size), for values of that attribute. For more details\r
+ on attribute syntax notation, see the descriptions of these\r
+ attributes syntaxes in section 4.1.\r
+\r
+ Note: Document data included in the operation is not strictly an\r
+ attribute, but it is treated as a special attribute group for\r
+ ordering purposes. The only operations that support supplying the\r
+ document data within an operation request are Print-Job and Send-\r
+ Document. There are no operation responses that include document\r
+ data.\r
+\r
+ Some operations are REQUIRED for IPP objects to support; the others\r
+ are OPTIONAL (see section 5.2.2). Therefore, before using an\r
+ OPTIONAL operation, a client SHOULD first use the REQUIRED Get-\r
+ Printer-Attributes operation to query the Printer's "operations-\r
+ supported" attribute in order to determine which OPTIONAL Printer and\r
+ Job operations are actually supported. The client SHOULD NOT use an\r
+ OPTIONAL operation that is not supported. When an IPP object\r
+ receives a request to perform an operation it does not support, it\r
+ returns the 'server-error-operation-not-supported' status code (see\r
+ section 13.1.5.2). An IPP object is non-conformant if it does not\r
+ support a REQUIRED operation.\r
+\r
+3.1.4 Character Set and Natural Language Operation Attributes\r
+\r
+ Some Job and Printer attributes have values that are text strings and\r
+ names intended for human understanding rather than machine\r
+ understanding (see the 'text' and 'name' attribute syntax\r
+ descriptions in section 4.1). The following sections describe two\r
+ special Operation Attributes called "attributes-charset" and\r
+ "attributes-natural-language". These attributes are always part of\r
+ the Operation Attributes group. For most attribute groups, the order\r
+ of the attributes within the group is not important. However, for\r
+ these two attributes within the Operation Attributes group, the order\r
+ is critical. The "attributes-charset" attribute MUST be the first\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 24]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ attribute in the group and the "attributes-natural-language"\r
+ attribute MUST be the second attribute in the group. In other words,\r
+ these attributes MUST be supplied in every IPP request and response,\r
+ they MUST come first in the group, and MUST come in the specified\r
+ order. For job creation operations, the IPP Printer implementation\r
+ saves these two attributes with the new Job object as Job Description\r
+ attributes. For the sake of brevity in this document, these\r
+ operation attribute descriptions are not repeated with every\r
+ operation request and response, but have a reference back to this\r
+ section instead.\r
+\r
+3.1.4.1 Request Operation Attributes\r
+\r
+ The client MUST supply and the Printer object MUST support the\r
+ following REQUIRED operation attributes in every IPP/1.1 operation\r
+ request:\r
+\r
+ "attributes-charset" (charset):\r
+ This operation attribute identifies the charset (coded\r
+ character set and encoding method) used by any 'text' and\r
+ 'name' attributes that the client is supplying in this request.\r
+ It also identifies the charset that the Printer object MUST use\r
+ (if supported) for all 'text' and 'name' attributes and status\r
+ messages that the Printer object returns in the response to\r
+ this request. See Sections 4.1.1 and 4.1.2 for the definition\r
+ of the 'text' and 'name' attribute syntaxes.\r
+\r
+ All clients and IPP objects MUST support the 'utf-8' charset\r
+ [RFC2279] and MAY support additional charsets provided that\r
+ they are registered with IANA [IANA-CS]. If the Printer object\r
+ does not support the client supplied charset value, the Printer\r
+ object MUST reject the request, set the "attributes-charset" to\r
+ 'utf-8' in the response, and return the 'client-error-charset-\r
+ not-supported' status code and any 'text' or 'name' attributes\r
+ using the 'utf-8' charset. The Printer NEED NOT return any\r
+ attributes in the Unsupported Attributes Group (See sections\r
+ 3.1.7 and 3.2.1.2). The Printer object MUST indicate the\r
+ charset(s) supported as the values of the "charset-supported"\r
+ Printer attribute (see Section 4.4.18), so that the client can\r
+ query to determine which charset(s) are supported.\r
+\r
+ Note to client implementers: Since IPP objects are only\r
+ required to support the 'utf-8' charset, in order to maximize\r
+ interoperability with multiple IPP object implementations, a\r
+ client may want to supply 'utf-8' in the "attributes-charset"\r
+ operation attribute, even though the client is only passing and\r
+ able to present a simpler charset, such as US-ASCII [ASCII] or\r
+ ISO-8859-1 [ISO8859-1]. Then the client will have to filter\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 25]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ out (or charset convert) those characters that are returned in\r
+ the response that it cannot present to its user. On the other\r
+ hand, if both the client and the IPP objects also support a\r
+ charset in common besides utf-8, the client may want to use\r
+ that charset in order to avoid charset conversion or data loss.\r
+\r
+ See the 'charset' attribute syntax description in Section 4.1.7\r
+ for the syntax and semantic interpretation of the values of\r
+ this attribute and for example values.\r
+\r
+ "attributes-natural-language" (naturalLanguage):\r
+ This operation attribute identifies the natural language used\r
+ by any 'text' and 'name' attributes that the client is\r
+ supplying in this request. This attribute also identifies the\r
+ natural language that the Printer object SHOULD use for all\r
+ 'text' and 'name' attributes and status messages that the\r
+ Printer object returns in the response to this request. See\r
+ the 'naturalLanguage' attribute syntax description in section\r
+ 4.1.8 for the syntax and semantic interpretation of the values\r
+ of this attribute and for example values.\r
+\r
+ There are no REQUIRED natural languages required for the\r
+ Printer object to support. However, the Printer object's\r
+ "generated-natural-language-supported" attribute identifies the\r
+ natural languages supported by the Printer object and any\r
+ contained Job objects for all text strings generated by the IPP\r
+ object. A client MAY query this attribute to determine which\r
+ natural language(s) are supported for generated messages.\r
+\r
+ For any of the attributes for which the Printer object\r
+ generates text, i.e., for the "job-state-message", "printer-\r
+ state-message", and status messages (see Section 3.1.6), the\r
+ Printer object MUST be able to generate these text strings in\r
+ any of its supported natural languages. If the client requests\r
+ a natural language that is not supported, the Printer object\r
+ MUST return these generated messages in the Printer's\r
+ configured natural language as specified by the Printer's\r
+ "natural-language-configured" attribute" (see Section 4.4.19).\r
+\r
+ For other 'text' and 'name' attributes supplied by the client,\r
+ authentication system, operator, system administrator, or\r
+ manufacturer (i.e., for "job-originating-user-name", "printer-\r
+ name" (name), "printer-location" (text), "printer-info" (text),\r
+ and "printer-make-and-model" (text)), the Printer object is\r
+ only required to support the configured natural language of the\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 26]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Printer identified by the Printer object's "natural-language-\r
+ configured" attribute, though support of additional natural\r
+ languages for these attributes is permitted.\r
+\r
+ For any 'text' or 'name' attribute in the request that is in a\r
+ different natural language than the value supplied in the\r
+ "attributes-natural-language" operation attribute, the client\r
+ MUST use the Natural Language Override mechanism (see sections\r
+ 4.1.1.2 and 4.1.2.2) for each such attribute value supplied.\r
+ The client MAY use the Natural Language Override mechanism\r
+ redundantly, i.e., use it even when the value is in the same\r
+ natural language as the value supplied in the "attributes-\r
+ natural-language" operation attribute of the request.\r
+\r
+ The IPP object MUST accept any natural language and any Natural\r
+ Language Override, whether the IPP object supports that natural\r
+ language or not (and independent of the value of the "ipp-\r
+ attribute-fidelity" Operation attribute). That is the IPP\r
+ object accepts all client supplied values no matter what the\r
+ values are in the Printer object's "generated-natural-\r
+ language-supported" attribute. That attribute, "generated-\r
+ natural-language-supported", only applies to generated\r
+ messages, not client supplied messages. The IPP object MUST\r
+ remember that natural language for all client-supplied\r
+ attributes, and when returning those attributes in response to\r
+ a query, the IPP object MUST indicate that natural language.\r
+\r
+ Each value whose attribute syntax type is 'text' or 'name' (see\r
+ sections 4.1.1 and 4.1.2) has an Associated Natural-Language.\r
+ This document does not specify how this association is stored\r
+ in a Printer or Job object. When such a value is encoded in a\r
+ request or response, the natural language is either implicit or\r
+ explicit:\r
+\r
+ - In the implicit case, the value contains only the text/name\r
+ value, and the language is specified by the "attributes-\r
+ natural-language" operation attribute in the request or\r
+ response (see sections 4.1.1.1 textWithoutLanguage and\r
+ 4.1.2.1 nameWithoutLanguage).\r
+\r
+ - In the explicit case (also known as the Natural-Language\r
+ Override case), the value contains both the language and the\r
+ text/name value (see sections 4.1.1.2 textWithLanguage and\r
+ 4.1.2.2 nameWithLanguage).\r
+\r
+ For example, the "job-name" attribute MAY be supplied by the\r
+ client in a create request. The text value for this attribute\r
+ will be in the natural language identified by the "attribute-\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 27]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ natural-language" attribute, or if different, as identified by\r
+ the Natural Language Override mechanism. If supplied, the IPP\r
+ object will use the value of the "job-name" attribute to\r
+ populate the Job object's "job-name" attribute. Whenever any\r
+ client queries the Job object's "job-name" attribute, the IPP\r
+ object returns the attribute as stored and uses the Natural\r
+ Language Override mechanism to specify the natural language, if\r
+ it is different from that reported in the "attributes-natural-\r
+ language" operation attribute of the response. The IPP object\r
+ MAY use the Natural Language Override mechanism redundantly,\r
+ i.e., use it even when the value is in the same natural\r
+ language as the value supplied in the "attributes-natural-\r
+ language" operation attribute of the response.\r
+\r
+ An IPP object MUST NOT reject a request based on a supplied\r
+ natural language in an "attributes-natural-language" Operation\r
+ attribute or in any attribute that uses the Natural Language\r
+ Override.\r
+\r
+ Clients SHOULD NOT supply 'text' or 'name' attributes that use an\r
+ illegal combination of natural language and charset. For example,\r
+ suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and\r
+ 'iso-8859-7'. Suppose also, that it supports natural languages 'en'\r
+ (English), 'fr' (French), and 'el' (Greek). Although the Printer\r
+ object supports the charset 'iso-8859-1' and natural language 'el',\r
+ it probably does not support the combination of Greek text strings\r
+ using the 'iso-8859-1' charset. The Printer object handles this\r
+ apparent incompatibility differently depending on the context in\r
+ which it occurs:\r
+\r
+ - In a create request: If the client supplies a text or name\r
+ attribute (for example, the "job-name" operation attribute) that\r
+ uses an apparently incompatible combination, it is a client\r
+ choice that does not affect the Printer object or its correct\r
+ operation. Therefore, the Printer object simply accepts the\r
+ client supplied value, stores it with the Job object, and\r
+ responds back with the same combination whenever the client (or\r
+ any client) queries for that attribute.\r
+ - In a query-type operation, like Get-Printer-Attributes: If the\r
+ client requests an apparently incompatible combination, the\r
+ Printer object responds (as described in section 3.1.4.2) using\r
+ the Printer's configured natural language rather than the\r
+ natural language requested by the client.\r
+\r
+ In either case, the Printer object does not reject the request\r
+ because of the apparent incompatibility. The potential incompatible\r
+ combination of charset and natural language can occur either at the\r
+ global operation level or at the Natural Language Override\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 28]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ attribute-by-attribute level. In addition, since the response always\r
+ includes explicit charset and natural language information, there is\r
+ never any question or ambiguity in how the client interprets the\r
+ response.\r
+\r
+3.1.4.2 Response Operation Attributes\r
+\r
+ The Printer object MUST supply and the client MUST support the\r
+ following REQUIRED operation attributes in every IPP/1.1 operation\r
+ response:\r
+\r
+ "attributes-charset" (charset):\r
+ This operation attribute identifies the charset used by any\r
+ 'text' and 'name' attributes that the Printer object is\r
+ returning in this response. The value in this response MUST be\r
+ the same value as the "attributes-charset" operation attribute\r
+ supplied by the client in the request. If this is not possible\r
+ (i.e., the charset requested is not supported), the request\r
+ would have been rejected. See "attributes-charset" described\r
+ in Section 3.1.4.1 above.\r
+\r
+ If the Printer object supports more than just the 'utf-8'\r
+ charset, the Printer object MUST be able to code convert\r
+ between each of the charsets supported on a highest fidelity\r
+ possible basis in order to return the 'text' and 'name'\r
+ attributes in the charset requested by the client. However,\r
+ some information loss MAY occur during the charset conversion\r
+ depending on the charsets involved. For example, the Printer\r
+ object may convert from a UTF-8 'a' to a US-ASCII 'a' (with no\r
+ loss of information), from an ISO Latin 1 CAPITAL LETTER A WITH\r
+ ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a\r
+ UTF-8 Japanese Kanji character to some ISO Latin 1 error\r
+ character indication such as '?', decimal code equivalent, or\r
+ to the absence of a character, depending on implementation.\r
+\r
+ Whether an implementation that supports more than one charset\r
+ stores the data in the charset supplied by the client or code\r
+ converts to one of the other supported charsets, depends on\r
+ implementation. The strategy should try to minimize loss of\r
+ information during code conversion. On each response, such an\r
+ implementation converts from its internal charset to that\r
+ requested.\r
+\r
+ "attributes-natural-language" (naturalLanguage):\r
+ This operation attribute identifies the natural language used\r
+ by any 'text' and 'name' attributes that the IPP object is\r
+ returning in this response. Unlike the "attributes-charset"\r
+ operation attribute, the IPP object NEED NOT return the same\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 29]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ value as that supplied by the client in the request. The IPP\r
+ object MAY return the natural language of the Job object or the\r
+ Printer's configured natural language as identified by the\r
+ Printer object's "natural-language-configured" attribute,\r
+ rather than the natural language supplied by the client. For\r
+ any 'text' or 'name' attribute or status message in the\r
+ response that is in a different natural language than the value\r
+ returned in the "attributes-natural-language" operation\r
+ attribute, the IPP object MUST use the Natural Language\r
+ Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on each\r
+ attribute value returned. The IPP object MAY use the Natural\r
+ Language Override mechanism redundantly, i.e., use it even when\r
+ the value is in the same natural language as the value supplied\r
+ in the "attributes-natural-language" operation attribute of the\r
+ response.\r
+\r
+3.1.5 Operation Targets\r
+\r
+ All IPP operations are directed at IPP objects. For Printer\r
+ operations, the operation is always directed at a Printer object\r
+ using one of its URIs (i.e., one of the values in the Printer\r
+ object's "printer-uri-supported" attribute). Even if the Printer\r
+ object supports more than one URI, the client supplies only one URI\r
+ as the target of the operation. The client identifies the target\r
+ object by supplying the correct URI in the "printer-uri (uri)"\r
+ operation attribute.\r
+\r
+ For Job operations, the operation is directed at either:\r
+\r
+ - The Job object itself using the Job object's URI. In this case,\r
+ the client identifies the target object by supplying the correct\r
+ URI in the "job-uri (uri)" operation attribute.\r
+ - The Printer object that created the Job object using both the\r
+ Printer objects URI and the Job object's Job ID. Since the\r
+ Printer object that created the Job object generated the Job ID,\r
+ it MUST be able to correctly associate the client supplied Job\r
+ ID with the correct Job object. The client supplies the Printer\r
+ object's URI in the "printer-uri (uri)" operation attribute and\r
+ the Job object's Job ID in the "job-id (integer(1:MAX))"\r
+ operation attribute.\r
+\r
+ If the operation is directed at the Job object directly using the Job\r
+ object's URI, the client MUST NOT include the redundant "job-id"\r
+ operation attribute.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 30]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The operation target attributes are REQUIRED operation attributes\r
+ that MUST be included in every operation request. Like the charset\r
+ and natural language attributes (see section 3.1.4), the operation\r
+ target attributes are specially ordered operation attributes. In all\r
+ cases, the operation target attributes immediately follow the\r
+ "attributes-charset" and "attributes-natural-language" attributes\r
+ within the operation attribute group, however the specific ordering\r
+ rules are:\r
+\r
+ - In the case where there is only one operation target attribute\r
+ (i.e., either only the "printer-uri" attribute or only the\r
+ "job-uri" attribute), that attribute MUST be the third attribute\r
+ in the operation attributes group.\r
+ - In the case where Job operations use two operation target\r
+ attributes (i.e., the "printer-uri" and "job-id" attributes),\r
+ the "printer-uri" attribute MUST be the third attribute and the\r
+ "job-id" attribute MUST be the fourth attribute.\r
+\r
+ In all cases, the target URIs contained within the body of IPP\r
+ operation requests and responses must be in absolute format rather\r
+ than relative format (a relative URL identifies a resource with the\r
+ scope of the HTTP server, but does not include scheme, host or port).\r
+\r
+ The following rules apply to the use of port numbers in URIs that\r
+ identify IPP objects:\r
+\r
+ 1. If the URI scheme allows the port number to be explicitly\r
+ included in the URI string, and a port number is specified\r
+ within the URI, then that port number MUST be used by the\r
+ client to contact the IPP object.\r
+\r
+ 2. If the URI scheme allows the port number to be explicitly\r
+ included in the URI string, and a port number is not specified\r
+ within the URI, then default port number implied by that URI\r
+ scheme MUST be used by the client to contact the IPP object.\r
+\r
+ 3. If the URI scheme does not allow an explicit port number to be\r
+ specified within the URI, then the default port number implied\r
+ by that URI MUST be used by the client to contact the IPP\r
+ object.\r
+\r
+ Note: The IPP "Encoding and Transport document [RFC2910] shows a\r
+ mapping of IPP onto HTTP/1.1 [RFC2616] and defines a new default port\r
+ number for using IPP over HTTP/1.1.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 31]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.1.6 Operation Response Status Codes and Status Messages\r
+\r
+ Every operation response includes a REQUIRED "status-code" parameter\r
+ and an OPTIONAL "status-message" operation attribute, and an OPTIONAL\r
+ "detailed-status-message" operation attribute. The Print-URI and\r
+ Send-URI response MAY include an OPTIONAL "document-access-error"\r
+ operation attribute.\r
+\r
+3.1.6.1 "status-code" (type2 enum)\r
+\r
+ The REQUIRED "status-code" parameter provides information on the\r
+ processing of a request.\r
+\r
+ The status code is intended for use by automata. A client\r
+ implementation of IPP SHOULD convert status code values into any\r
+ localized message that has semantic meaning to the end user.\r
+\r
+ The "status-code" value is a numeric value that has semantic meaning.\r
+ The "status-code" syntax is similar to a "type2 enum" (see section\r
+ 4.1 on "Attribute Syntaxes") except that values can range only from\r
+ 0x0000 to 0x7FFF. Section 13 describes the status codes, assigns the\r
+ numeric values, and suggests a corresponding status message for each\r
+ status code for use by the client when the user's natural language is\r
+ English.\r
+\r
+ If the Printer performs an operation with no errors and it encounters\r
+ no problems, it MUST return the status code 'successful-ok' in the\r
+ response. See section 13.\r
+\r
+ If the client supplies unsupported values for the following\r
+ parameters or Operation attributes, the Printer object MUST reject\r
+ the operation, NEED NOT return the unsupported attribute value in the\r
+ Unsupported Attributes group, and MUST return the indicated status\r
+ code:\r
+\r
+ Parameter/Attribute Status code\r
+\r
+ version-number server-error-version-not-supported\r
+ operation-id server-error-operation-not-supported\r
+ attributes-charset client-error-charset-not-supported\r
+ compression client-error-compression-not-supported\r
+ document-format client-error-document-format-not-supported\r
+ document-uri client-error-uri-scheme-not-supported,\r
+ client-error-document-access-error\r
+\r
+ If the client supplies unsupported values for other attributes, or\r
+ unsupported attributes, the Printer returns the status code defined\r
+ in section 3.1.7 on Unsupported Attributes.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 32]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.1.6.2 "status-message" (text(255))\r
+\r
+ The OPTIONAL "status-message" operation attribute provides a short\r
+ textual description of the status of the operation. The "status-\r
+ message" attribute's syntax is "text(255)", so the maximum length is\r
+ 255 octets (see section 4.1.1). The status message is intended for\r
+ the human end user. If a response does include a "status-message"\r
+ attribute, an IPP client NEED NOT examine or display the messages,\r
+ however it SHOULD do so in some implementation specific manner. The\r
+ "status-message" is especially useful for a later version of a\r
+ Printer object to return as supplemental information for the human\r
+ user to accompany a status code that an earlier version of a client\r
+ might not understand.\r
+\r
+ If the Printer object supports the "status-message" operation\r
+ attribute, the Printer object MUST be able to generate this message\r
+ in any of the natural languages identified by the Printer object's\r
+ "generated-natural-language-supported" attribute (see the\r
+ "attributes-natural-language" operation attribute specified in\r
+ section 3.1.4.1. Section 13 suggests the text for the status message\r
+ returned by the Printer for use with the English natural language.\r
+\r
+ As described in section 3.1.4.1 for any returned 'text' attribute, if\r
+ there is a choice for generating this message, the Printer object\r
+ uses the natural language indicated by the value of the "attributes-\r
+ natural-language" in the client request if supported, otherwise the\r
+ Printer object uses the value in the Printer object's own "natural-\r
+ language-configured" attribute.\r
+\r
+ If the Printer object supports the "status-message" operation\r
+ attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a\r
+ status message for the following error status codes (see section 13):\r
+ 'client-error-bad-request', 'client-error-charset-not-supported',\r
+ 'server-error-internal-error', 'server-error-operation-not-\r
+ supported', and 'server-error-version-not-supported'. In this case,\r
+ it MUST set the value of the "attributes-charset" operation attribute\r
+ to 'utf-8' in the error response.\r
+\r
+3.1.6.3 "detailed-status-message" (text(MAX))\r
+\r
+ The OPTIONAL "detailed-status-message" operation attribute provides\r
+ additional more detailed technical and implementation-specific\r
+ information about the operation. The "detailed-status-message"\r
+ attribute's syntax is "text(MAX)", so the maximum length is 1023\r
+ octets (see section 4.1.1). If the Printer objects supports the\r
+ "detailed-status-message" operation attribute, the Printer NEED NOT\r
+ localize the message, since it is intended for use by the system\r
+ administrator or other experienced technical persons. Localization\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 33]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ might obscure the technical meaning of such messages. Clients MUST\r
+ NOT attempt to parse the value of this attribute. See the\r
+ "document-access-error" operation attribute (section 3.1.6.4) for\r
+ additional errors that a program can process.\r
+\r
+3.1.6.4 "document-access-error" (text(MAX))\r
+\r
+ This OPTIONAL operation attribute provides additional information\r
+ about any document access errors encountered by the Printer before it\r
+ returned a response to the Print-URI (section 3.2.2) or Send-URI\r
+ (section 3.3.1) operation. For errors in the protocol identified by\r
+ the URI scheme in the "document-uri" operation attribute, such as\r
+ 'http:' or 'ftp:', the error code is returned in parentheses,\r
+ followed by the URI. For example:\r
+\r
+ (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf\r
+\r
+ Most Internet protocols use decimal error codes (unlike IPP), so the\r
+ ASCII error code representation is in decimal.\r
+\r
+3.1.7 Unsupported Attributes\r
+\r
+ The Unsupported Attributes group contains attributes that are not\r
+ supported by the operation. This group is primarily for the job\r
+ creation operations, but all operations can return this group.\r
+\r
+ A Printer object MUST include an Unsupported Attributes group in a\r
+ response if the status code is one of the following: 'successful-\r
+ ok-ignored-or-substituted-attributes', 'successful-ok-conflicting-\r
+ attributes', 'client-error-attributes-or-values-not-supported' or\r
+ 'client-error-conflicting-attributes'.\r
+\r
+ If the status code is one of the four specified in the preceding\r
+ paragraph, the Unsupported Attributes group MUST contain all of those\r
+ attributes and only those attributes that are:\r
+\r
+ a. an Operation or Job Template attribute supplied in the request,\r
+ and\r
+\r
+ b. unsupported by the printer. See below for details on the three\r
+ categories "unsupported" attributes.\r
+\r
+ If the status code is one of those in the table in section 3.1.6.1,\r
+ the Unsupported Attributes group NEED NOT contain the unsupported\r
+ parameter or attribute indicated in that table.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 34]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ If the Printer object is not returning any Unsupported Attributes in\r
+ the response, the Printer object SHOULD omit Group 2 rather than\r
+ sending an empty group. However, a client MUST be able to accept an\r
+ empty group.\r
+\r
+ Unsupported attributes fall into three categories:\r
+\r
+ 1. The Printer object does not support the supplied attribute (no\r
+ matter what the attribute syntax or value).\r
+\r
+ 2. The Printer object does support the attribute, but does not\r
+ support some or all of the particular attribute syntaxes or\r
+ values supplied by the client (i.e., the Printer object does\r
+ not have those attribute syntaxes or values in its\r
+ corresponding "xxx-supported" attribute).\r
+\r
+ 3. The Printer object does support the attributes and values\r
+ supplied, but the particular values are in conflict with one\r
+ another, because they violate a constraint, such as not being\r
+ able to staple transparencies.\r
+\r
+ In the case of an unsupported attribute name, the Printer object\r
+ returns the client-supplied attribute with a substituted value of\r
+ 'unsupported'. This value's syntax type is "out-of-band" and its\r
+ encoding is defined by special rules for "out-of-band" values in the\r
+ "Encoding and Transport" document [RFC2910]. Its value indicates no\r
+ support for the attribute itself (see the beginning of section 4.1).\r
+\r
+ In the case of a supported attribute with one or more unsupported\r
+ attribute syntaxes or values, the Printer object simply returns the\r
+ client-supplied attribute with the unsupported attribute syntaxes or\r
+ values as supplied by the client. This indicates support for the\r
+ attribute, but no support for that particular attribute syntax or\r
+ value. If the client supplies a multi-valued attribute with more\r
+ than one value and the Printer object supports the attribute but only\r
+ supports a subset of the client-supplied attribute syntaxes or\r
+ values, the Printer object\r
+\r
+ MUST return only those attribute syntaxes or values that are\r
+ unsupported.\r
+\r
+ In the case of two (or more) supported attribute values that are in\r
+ conflict with one another (although each is supported independently,\r
+ the values conflict when requested together within the same job), the\r
+ Printer object MUST return all the values that it ignores or\r
+ substitutes to resolve the conflict, but not any of the values that\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 35]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ it is still using. The choice for exactly how to resolve the\r
+ conflict is implementation dependent. See sections 3.2.1.2 and 15.\r
+ See The Implementer's Guide [IPP-IIG] for an example.\r
+\r
+3.1.8 Versions\r
+\r
+ Each operation request and response carries with it a "version-\r
+ number" parameter. Each value of the "version-number" is in the form\r
+ "X.Y" where X is the major version number and Y is the minor version\r
+ number. By including a version number in the client request, it\r
+ allows the client to identify which version of IPP it is interested\r
+ in using, i.e., the version whose conformance requirements the client\r
+ may be depending upon the Printer to meet.\r
+\r
+ If the IPP object does not support that major version number supplied\r
+ by the client, i.e., the major version field of the "version-number"\r
+ parameter does not match any of the values of the Printer's "ipp-\r
+ versions-supported" (see section 4.4.14), the object MUST respond\r
+ with a status code of 'server-error-version-not-supported' along with\r
+ the closest version number that is supported (see section 13.1.5.4).\r
+ If the major version number is supported, but the minor version\r
+ number is not, the IPP object SHOULD accept and attempt to perform\r
+ the request (or reject the request if the operation is not\r
+ supported), else it rejects the request and returns the 'server-\r
+ error-version-not-supported' status code. In all cases, the IPP\r
+ object MUST return the "version-number" that it supports that is\r
+ closest to the version number supplied by the client in the request.\r
+\r
+ There is no version negotiation per se. However, if after receiving\r
+ a 'server-error-version-not-supported' status code from an IPP\r
+ object, a client SHOULD try again with a different version number. A\r
+ client MAY also determine the versions supported either from a\r
+ directory that conforms to Appendix E (see section 16) or by querying\r
+ the Printer object's "ipp-versions-supported" attribute (see section\r
+ 4.4.14) to determine which versions are supported.\r
+\r
+ An IPP object implementation MUST support version '1.1', i.e., meet\r
+ the conformance requirements for IPP/1.1 as specified in this\r
+ document and [RFC2910]. It is recommended that IPP object\r
+ implementations accept any request with the major version '1' (or\r
+ reject the request if the operation is not supported).\r
+\r
+ There is only one notion of "version number" that covers both IPP\r
+ Model and IPP Protocol changes. Thus the version number MUST change\r
+ when introducing a new version of the Model and Semantics document\r
+ (this document) or a new version of the "Encoding and Transport"\r
+ document [RFC2910].\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 36]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Changes to the major version number of the Model and Semantics\r
+ document indicate structural or syntactic changes that make it\r
+ impossible for older version of IPP clients and Printer objects to\r
+ correctly parse and correctly process the new or changed attributes,\r
+ operations and responses. If the major version number changes, the\r
+ minor version numbers is set to zero. As an example, adding the\r
+ REQUIRED "ipp-attribute-fidelity" attribute to version '1.1' (if it\r
+ had not been part of version '1.0'), would have required a change to\r
+ the major version number, since an IPP/1.0 Printer would not have\r
+ processed a request with the correct semantics that contained the\r
+ "ipp-attribute-fidelity" attribute that it did not know about. Items\r
+ that might affect the changing of the major version number include\r
+ any changes to the Model and Semantics document (this document) or\r
+ the "Encoding and Transport" document [RFC2910] itself, such as:\r
+\r
+ - reordering of ordered attributes or attribute sets\r
+ - changes to the syntax of existing attributes\r
+ - adding REQUIRED (for an IPP object to support) operation\r
+ attribute groups\r
+ - adding values to existing REQUIRED operation attributes\r
+ - adding REQUIRED operations\r
+\r
+ Changes to the minor version number indicate the addition of new\r
+ features, attributes and attribute values that may not be understood\r
+ by all IPP objects, but which can be ignored if not understood.\r
+ Items that might affect the changing of the minor version number\r
+ include any changes to the model objects and attributes but not the\r
+ encoding and transport rules [RFC2910] (except adding attribute\r
+ syntaxes). Examples of such changes are:\r
+\r
+ - grouping all extensions not included in a previous version into\r
+ a new version\r
+ - adding new attribute values\r
+ - adding new object attributes\r
+ - adding OPTIONAL (for an IPP object to support) operation\r
+ attributes (i.e., those attributes that an IPP object can ignore\r
+ without confusing clients)\r
+ - adding OPTIONAL (for an IPP object to support) operation\r
+ attribute groups (i.e., those attributes that an IPP object can\r
+ ignore without confusing clients)\r
+ - adding new attribute syntaxes\r
+ - adding OPTIONAL operations\r
+ - changing Job Description attributes or Printer Description\r
+ attributes from OPTIONAL to REQUIRED or vice versa.\r
+ - adding OPTIONAL attribute syntaxes to an existing attribute.\r
+\r
+ The encoding of the "version-number" MUST NOT change over any version\r
+ number (either major or minor). This rule guarantees that all future\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 37]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ versions will be backwards compatible with all previous versions (at\r
+ least for checking the "version-number"). In addition, any protocol\r
+ elements (attributes, error codes, tags, etc.) that are not carried\r
+ forward from one version to the next are deprecated so that they can\r
+ never be reused with new semantics.\r
+\r
+ Implementations that support a certain version NEED NOT support ALL\r
+ previous versions. As each new version is defined (through the\r
+ release of a new IPP specification document), that version will\r
+ specify which previous versions MUST and which versions SHOULD be\r
+ supported in compliant implementations.\r
+\r
+3.1.9 Job Creation Operations\r
+\r
+ In order to "submit a print job" and create a new Job object, a\r
+ client issues a create request. A create request is any one of\r
+ following three operation requests:\r
+\r
+ - The Print-Job Request: A client that wants to submit a print job\r
+ with only a single document uses the Print-Job operation. The\r
+ operation allows for the client to "push" the document data to\r
+ the Printer object by including the document data in the request\r
+ itself.\r
+\r
+ - The Print-URI Request: A client that wants to submit a print job\r
+ with only a single document (where the Printer object "pulls"\r
+ the document data instead of the client "pushing" the data to\r
+ the Printer object) uses the Print-URI operation. In this\r
+ case, the client includes in the request only a URI reference to\r
+ the document data (not the document data itself).\r
+\r
+ - The Create-Job Request: A client that wants to submit a print\r
+ job with multiple documents uses the Create-Job operation. This\r
+ operation is followed by an arbitrary number (one or more) of\r
+ Send-Document and/or Send-URI operations (each creating another\r
+ document for the newly create Job object). The Send-Document\r
+ operation includes the document data in the request (the client\r
+ "pushes" the document data to the printer), and the Send-URI\r
+ operation includes only a URI reference to the document data in\r
+ the request (the Printer "pulls" the document data from the\r
+ referenced location). The last Send-Document or Send-URI\r
+ request for a given Job object includes a "last-document"\r
+ operation attribute set to 'true' indicating that this is the\r
+ last request.\r
+\r
+ Throughout this model document, the term "create request" is used to\r
+ refer to any of these three operation requests.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 38]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ A Create-Job operation followed by only one Send-Document operation\r
+ is semantically equivalent to a Print-Job operation, however, for\r
+ performance reasons, the client SHOULD use the Print-Job operation\r
+ for all single document jobs. Also, Print-Job is a REQUIRED\r
+ operation (all implementations MUST support it) whereas Create-Job is\r
+ an OPTIONAL operation, hence some implementations might not support\r
+ it.\r
+\r
+ Job submission time is the point in time when a client issues a\r
+ create request. The initial state of every Job object is the\r
+ 'pending', 'pending-held', or 'processing' state (see section 4.3.7).\r
+ When the Printer object begins processing the print job, the Job\r
+ object's state moves to 'processing'. This is known as job\r
+ processing time. There are validation checks that must be done at\r
+ job submission time and others that must be performed at job\r
+ processing time.\r
+\r
+ At job submission time and at the time a Validate-Job operation is\r
+ received, the Printer MUST do the following:\r
+\r
+ 1. Process the client supplied attributes and either accept or\r
+ reject the request\r
+ 2. Validate the syntax of and support for the scheme of any client\r
+ supplied URI\r
+\r
+ At job submission time the Printer object MUST validate whether or\r
+ not the supplied attributes, attribute syntaxes, and values are\r
+ supported by matching them with the Printer object's corresponding\r
+ "xxx-supported" attributes. See section 3.1.7 for details. [IPP-\r
+ IIG] presents suggested steps for an IPP object to either accept or\r
+ reject any request and additional steps for processing create\r
+ requests.\r
+\r
+ At job submission time the Printer object NEED NOT perform the\r
+ validation checks reserved for job processing time such as:\r
+\r
+ 1. Validating the document data\r
+ 2. Validating the actual contents of any client supplied URI\r
+ (resolve the reference and follow the link to the document\r
+ data)\r
+\r
+ At job submission time, these additional job processing time\r
+ validation checks are essentially useless, since they require\r
+ actually parsing and interpreting the document data, are not\r
+ guaranteed to be 100% accurate, and MUST be done, yet again, at job\r
+ processing time. Also, in the case of a URI, checking for\r
+ availability at job submission time does not guarantee availability\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 39]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ at job processing time. In addition, at job processing time, the\r
+ Printer object might discover any of the following conditions that\r
+ were not detectable at job submission time:\r
+\r
+ - runtime errors in the document data,\r
+ - nested document data that is in an unsupported format,\r
+ - the URI reference is no longer valid (i.e., the server hosting\r
+ the document might be down), or\r
+ - any other job processing error\r
+\r
+ At job submission time, a Printer object, especially a non-spooling\r
+ Printer, MAY accept jobs that it does not have enough space for. In\r
+ such a situation, a Printer object MAY stop reading data from a\r
+ client for an indefinite period of time. A client MUST be prepared\r
+ for a write operation to block for an indefinite period of time (see\r
+ section 5.1 on client conformance).\r
+\r
+ When a Printer object has too little space for starting a new job, it\r
+ MAY reject a new create request. In this case, a Printer object MUST\r
+ return a response (in reply to the rejected request) with a status-\r
+ code of 'server-error-busy' (see section 14.1.5.8) and it MAY close\r
+ the connection before receiving all bytes of the operation. A\r
+ Printer SHOULD indicate that it is temporarily unable to accept jobs\r
+ by setting the 'spool-space-full' value in its "printer-state-\r
+ reasons" attribute and removing the value when it can accept another\r
+ job (see section 4.4.12).\r
+\r
+ When receiving a 'server-error-busy' status-code in an operation\r
+ response, a client MUST be prepared for the Printer object to close\r
+ the connection before the client has sent all of the data (especially\r
+ for the Print-Job operation). A client MUST be prepared to keep\r
+ submitting a create request until the IPP Printer object accepts the\r
+ create request.\r
+\r
+ At job processing time, since the Printer object has already\r
+ responded with a successful status code in the response to the create\r
+ request, if the Printer object detects an error, the Printer object\r
+ is unable to inform the end user of the error with an operation\r
+ status code. In this case, the Printer, depending on the error, can\r
+ set the job object's "job-state", "job-state-reasons", or "job-\r
+ state-message" attributes to the appropriate value(s) so that later\r
+ queries can report the correct job status.\r
+\r
+ Note: Asynchronous notification of events is outside the scope of\r
+ this IPP/1.1 document.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 40]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.2 Printer Operations\r
+\r
+ All Printer operations are directed at Printer objects. A client\r
+ MUST always supply the "printer-uri" operation attribute in order to\r
+ identify the correct target of the operation.\r
+\r
+3.2.1 Print-Job Operation\r
+\r
+ This REQUIRED operation allows a client to submit a print job with\r
+ only one document and supply the document data (rather than just a\r
+ reference to the data). See Section 15 for the suggested steps for\r
+ processing create operations and their Operation and Job Template\r
+ attributes.\r
+\r
+3.2.1.1 Print-Job Request\r
+\r
+ The following groups of attributes are supplied as part of the\r
+ Print-Job Request:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.1. The Printer object\r
+ MUST copy these values to the corresponding Job Description\r
+ attributes described in sections 4.3.19 and 4.3.20.\r
+\r
+ Target:\r
+ The "printer-uri" (uri) operation attribute which is the target\r
+ for this operation as described in section 3.1.5.\r
+\r
+ Requesting User Name:\r
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be\r
+ supplied by the client as described in section 8.3.\r
+\r
+ "job-name" (name(MAX)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. It contains the client\r
+ supplied Job name. If this attribute is supplied by the\r
+ client, its value is used for the "job-name" attribute of the\r
+ newly created Job object. The client MAY automatically include\r
+ any information that will help the end-user distinguish amongst\r
+ his/her jobs, such as the name of the application program along\r
+ with information from the document, such as the document name,\r
+ document subject, or source file name. If this attribute is\r
+ not supplied by the client, the Printer generates a name to use\r
+ in the "job-name" attribute of the newly created Job object\r
+ (see Section 4.3.5).\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 41]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ "ipp-attribute-fidelity" (boolean):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. The value 'true' indicates\r
+ that total fidelity to client supplied Job Template attributes\r
+ and values is required, else the Printer object MUST reject the\r
+ Print-Job request. The value 'false' indicates that a\r
+ reasonable attempt to print the Job object is acceptable and\r
+ the Printer object MUST accept the Print-Job request. If not\r
+ supplied, the Printer object assumes the value is 'false'. All\r
+ Printer objects MUST support both types of job processing. See\r
+ section 15 for a full description of "ipp-attribute-fidelity"\r
+ and its relationship to other attributes, especially the\r
+ Printer object's "pdl-override-supported" attribute.\r
+\r
+ "document-name" (name(MAX)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. It contains the client\r
+ supplied document name. The document name MAY be different\r
+ than the Job name. Typically, the client software\r
+ automatically supplies the document name on behalf of the end\r
+ user by using a file name or an application generated name. If\r
+ this attribute is supplied, its value can be used in a manner\r
+ defined by each implementation. Examples include: printed\r
+ along with the Job (job start sheet, page adornments, etc.),\r
+ used by accounting or resource tracking management tools, or\r
+ even stored along with the document as a document level\r
+ attribute. IPP/1.1 does not support the concept of document\r
+ level attributes.\r
+\r
+ "compression" (type3 keyword):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute and the "compression-\r
+ supported" attribute (see section 4.4.32). The client supplied\r
+ "compression" operation attribute identifies the compression\r
+ algorithm used on the document data. The following cases exist:\r
+\r
+ a) If the client omits this attribute, the Printer object MUST\r
+ assume that the data is not compressed (i.e. the Printer\r
+ follows the rules below as if the client supplied the\r
+ "compression" attribute with a value of 'none').\r
+ b) If the client supplies this attribute, but the value is not\r
+ supported by the Printer object, i.e., the value is not one\r
+ of the values of the Printer object's "compression-\r
+ supported" attribute, the Printer object MUST reject the\r
+ request, and return the 'client-error-compression-not-\r
+ supported' status code. See section 3.1.7 for returning\r
+ unsupported attributes and values.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 42]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ c) If the client supplies the attribute and the Printer object\r
+ supports the attribute value, the Printer object uses the\r
+ corresponding decompression algorithm on the document data.\r
+ d) If the decompression algorithm fails before the Printer\r
+ returns an operation response, the Printer object MUST\r
+ reject the request and return the 'client-error-\r
+ compression-error' status code.\r
+ e) If the decompression algorithm fails after the Printer\r
+ returns an operation response, the Printer object MUST abort\r
+ the job and add the 'compression-error' value to the job's\r
+ "job-state-reasons" attribute.\r
+ f) If the decompression algorithm succeeds, the document data\r
+ MUST then have the format specified by the job's "document-\r
+ format" attribute, if supplied (see "document-format"\r
+ operation attribute definition below).\r
+\r
+ "document-format" (mimeMediaType):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. The value of this\r
+ attribute identifies the format of the supplied document data.\r
+ The following cases exist:\r
+\r
+ a) If the client does not supply this attribute, the Printer\r
+ object assumes that the document data is in the format\r
+ defined by the Printer object's "document-format-default"\r
+ attribute. (i.e. the Printer follows the rules below as if\r
+ the client supplied the "document-format" attribute with a\r
+ value equal to the printer's default value).\r
+ b) If the client supplies this attribute, but the value is not\r
+ supported by the Printer object, i.e., the value is not one\r
+ of the values of the Printer object's "document-format-\r
+ supported" attribute, the Printer object MUST reject the\r
+ request and return the 'client-error-document-format-not-\r
+ supported' status code.\r
+ c) If the client supplies this attribute and its value is\r
+ 'application/octet-stream' (i.e. to be auto-sensed, see\r
+ Section 4.1.9.1), and the format is not one of the\r
+ document-formats that the Printer can auto-sense, and this\r
+ check occurs before the Printer returns an operation\r
+ response, then the Printer MUST reject the request and\r
+ return the 'client-error-document-format-not-supported'\r
+ status code.\r
+ d) If the client supplies this attribute, and the value is\r
+ supported by the Printer object, the Printer is capable of\r
+ interpreting the document data.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 43]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ e) If interpreting of the document data fails before the\r
+ Printer returns an operation response, the Printer object\r
+ MUST reject the request and return the 'client-error-\r
+ document-format-error' status code.\r
+ f) If interpreting of the document data fails after the Printer\r
+ returns an operation response, the Printer object MUST abort\r
+ the job and add the 'document-format-error' value to the\r
+ job's "job-state-reasons" attribute.\r
+\r
+ "document-natural-language" (naturalLanguage):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object OPTIONALLY supports this attribute. This attribute\r
+ specifies the natural language of the document for those\r
+ document-formats that require a specification of the natural\r
+ language in order to image the document unambiguously. There\r
+ are no particular values required for the Printer object to\r
+ support.\r
+\r
+ "job-k-octets" (integer(0:MAX)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object OPTIONALLY supports this attribute and the "job-k-\r
+ octets-supported" attribute (see section 4.4.33). The client\r
+ supplied "job-k-octets" operation attribute identifies the\r
+ total size of the document(s) in K octets being submitted (see\r
+ section 4.3.17.1 for the complete semantics). If the client\r
+ supplies the attribute and the Printer object supports the\r
+ attribute, the value of the attribute is used to populate the\r
+ Job object's "job-k-octets" Job Description attribute.\r
+\r
+ For this attribute and the following two attributes ("job-\r
+ impressions", and "job-media-sheets"), if the client supplies\r
+ the attribute, but the Printer object does not support the\r
+ attribute, the Printer object ignores the client-supplied\r
+ value. If the client supplies the attribute and the Printer\r
+ supports the attribute, and the value is within the range of\r
+ the corresponding Printer object's "xxx-supported" attribute,\r
+ the Printer object MUST use the value to populate the Job\r
+ object's "xxx" attribute. If the client supplies the attribute\r
+ and the Printer supports the attribute, but the value is\r
+ outside the range of the corresponding Printer object's "xxx-\r
+ supported" attribute, the Printer object MUST copy the\r
+ attribute and its value to the Unsupported Attributes response\r
+ group, reject the request, and return the 'client-error-\r
+ attributes-or-values-not-supported' status code. If the client\r
+ does not supply the attribute, the Printer object MAY choose to\r
+ populate the corresponding Job object attribute depending on\r
+ whether the Printer object supports the attribute and is able\r
+ to calculate or discern the correct value.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 44]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ "job-impressions" (integer(0:MAX)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object OPTIONALLY supports this attribute and the "job-\r
+ impressions-supported" attribute (see section 4.4.34). The\r
+ client supplied "job-impressions" operation attribute\r
+ identifies the total size in number of impressions of the\r
+ document(s) being submitted (see section 4.3.17.2 for the\r
+ complete semantics).\r
+\r
+ See last paragraph under "job-k-octets".\r
+\r
+ "job-media-sheets" (integer(0:MAX)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object OPTIONALLY supports this attribute and the "job-media-\r
+ sheets-supported" attribute (see section 4.4.35). The client\r
+ supplied "job-media-sheets" operation attribute identifies the\r
+ total number of media sheets to be produced for this job (see\r
+ section 4.3.17.3 for the complete semantics).\r
+\r
+ See last paragraph under "job-k-octets".\r
+\r
+ Group 2: Job Template Attributes\r
+\r
+ The client OPTIONALLY supplies a set of Job Template attributes as\r
+ defined in section 4.2. If the client is not supplying any Job\r
+ Template attributes in the request, the client SHOULD omit Group 2\r
+ rather than sending an empty group. However, a Printer object\r
+ MUST be able to accept an empty group.\r
+\r
+ Group 3: Document Content\r
+\r
+ The client MUST supply the document data to be processed.\r
+\r
+ In addition to the MANDATORY parameters required for every\r
+ operation request, the simplest Print-Job Request consists of just\r
+ the "attributes-charset" and "attributes-natural-language"\r
+ operation attributes; the "printer-uri" target operation\r
+ attribute; the Document Content and nothing else. In this simple\r
+ case, the Printer object:\r
+\r
+ - creates a new Job object (the Job object contains a single\r
+ document),\r
+ - stores a generated Job name in the "job-name" attribute in the\r
+ natural language and charset requested (see Section 3.1.4.1) (if\r
+ those are supported, otherwise using the Printer object's\r
+ default natural language and charset), and\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 45]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - at job processing time, uses its corresponding default value\r
+ attributes for the supported Job Template attributes that were\r
+ not supplied by the client as IPP attribute or embedded\r
+ instructions in the document data.\r
+\r
+3.2.1.2 Print-Job Response\r
+\r
+ The Printer object MUST return to the client the following sets of\r
+ attributes as part of the Print-Job Response:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Status Message:\r
+ In addition to the REQUIRED status code returned in every\r
+ response, the response OPTIONALLY includes a "status-message"\r
+ (text(255)) and/or a "detailed-status-message" (text(MAX))\r
+ operation attribute as described in sections 13 and 3.1.6. If\r
+ the client supplies unsupported or conflicting Job Template\r
+ attributes or values, the Printer object MUST reject or accept\r
+ the Print-Job request depending on the whether the client\r
+ supplied a 'true' or 'false' value for the "ipp-attribute-\r
+ fidelity" operation attribute. See the Implementer's Guide\r
+ [IPP-IIG] for a complete description of the suggested steps for\r
+ processing a create request.\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.2.\r
+\r
+ Group 2: Unsupported Attributes\r
+\r
+ See section 3.1.7 for details on returning Unsupported Attributes.\r
+\r
+ The value of the "ipp-attribute-fidelity" supplied by the client\r
+ does not affect what attributes the Printer object returns in this\r
+ group. The value of "ipp-attribute-fidelity" only affects whether\r
+ the Print-Job operation is accepted or rejected. If the job is\r
+ accepted, the client may query the job using the Get-Job-\r
+ Attributes operation requesting the unsupported attributes that\r
+ were returned in the create response to see which attributes were\r
+ ignored (not stored on the Job object) and which attributes were\r
+ stored with other (substituted) values.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 46]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Group 3: Job Object Attributes\r
+\r
+ "job-uri" (uri):\r
+ The Printer object MUST return the Job object's URI by\r
+ returning the contents of the REQUIRED "job-uri" Job object\r
+ attribute. The client uses the Job object's URI when directing\r
+ operations at the Job object. The Printer object always uses\r
+ its configured security policy when creating the new URI.\r
+ However, if the Printer object supports more than one URI, the\r
+ Printer object also uses information about which URI was used\r
+ in the Print-Job Request to generated the new URI so that the\r
+ new URI references the correct access channel. In other words,\r
+ if the Print-Job Request comes in over a secure channel, the\r
+ Printer object MUST generate a Job URI that uses the secure\r
+ channel as well.\r
+\r
+ "job-id" (integer(1:MAX)):\r
+ The Printer object MUST return the Job object's Job ID by\r
+ returning the REQUIRED "job-id" Job object attribute. The\r
+ client uses this "job-id" attribute in conjunction with the\r
+ "printer-uri" attribute used in the Print-Job Request when\r
+ directing Job operations at the Printer object.\r
+\r
+ "job-state" (type1 enum):\r
+ The Printer object MUST return the Job object's REQUIRED "job-\r
+ state" attribute. The value of this attribute (along with the\r
+ value of the next attribute: "job-state-reasons") is taken\r
+ from a "snapshot" of the new Job object at some meaningful\r
+ point in time (implementation defined) between when the Printer\r
+ object receives the Print-Job Request and when the Printer\r
+ object returns the response.\r
+\r
+ "job-state-reasons" (1setOf type2 keyword):\r
+ The Printer object MUST return the Job object's REQUIRED "job-\r
+ state-reasons" attribute.\r
+\r
+ "job-state-message" (text(MAX)):\r
+ The Printer object OPTIONALLY returns the Job object's OPTIONAL\r
+ "job-state-message" attribute. If the Printer object supports\r
+ this attribute then it MUST be returned in the response. If\r
+ this attribute is not returned in the response, the client can\r
+ assume that the "job-state-message" attribute is not supported\r
+ and will not be returned in a subsequent Job object query.\r
+\r
+ "number-of-intervening-jobs" (integer(0:MAX)):\r
+ The Printer object OPTIONALLY returns the Job object's OPTIONAL\r
+ "number-of-intervening-jobs" attribute. If the Printer object\r
+ supports this attribute then it MUST be returned in the\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 47]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ response. If this attribute is not returned in the response,\r
+ the client can assume that the "number-of-intervening-jobs"\r
+ attribute is not supported and will not be returned in a\r
+ subsequent Job object query.\r
+\r
+ Note: Since any printer state information which affects a job's\r
+ state is reflected in the "job-state" and "job-state-reasons"\r
+ attributes, it is sufficient to return only these attributes\r
+ and no specific printer status attributes.\r
+\r
+ Note: In addition to the MANDATORY parameters required for every\r
+ operation response, the simplest response consists of the just the\r
+ "attributes-charset" and "attributes-natural-language" operation\r
+ attributes and the "job-uri", "job-id", and "job-state" Job Object\r
+ Attributes. In this simplest case, the status code is 'successful-\r
+ ok' and there is no "status-message" or "detailed-status-message"\r
+ operation attribute.\r
+\r
+3.2.2 Print-URI Operation\r
+\r
+ This OPTIONAL operation is identical to the Print-Job operation\r
+ (section 3.2.1) except that a client supplies a URI reference to the\r
+ document data using the "document-uri" (uri) operation attribute (in\r
+ Group 1) rather than including the document data itself. Before\r
+ returning the response, the Printer MUST validate that the Printer\r
+ supports the retrieval method (e.g., http, ftp, etc.) implied by the\r
+ URI, and MUST check for valid URI syntax. If the client-supplied URI\r
+ scheme is not supported, i.e. the value is not in the Printer\r
+ object's "referenced-uri-scheme-supported" attribute, the Printer\r
+ object MUST reject the request and return the 'client-error-uri-\r
+ scheme-not-supported' status code.\r
+\r
+ The IPP Printer MAY validate the accessibility of the document as\r
+ part of the operation or subsequently. If the Printer determines an\r
+ accessibility problem before returning an operation response, it\r
+ rejects the request and returns the 'client-error-document-access-\r
+ error' status code. The Printer MAY also return a specific document\r
+ access error code using the "document-access-error" operation\r
+ attribute (see section 3.1.6.4).\r
+\r
+ If the Printer determines this document accessibility problem after\r
+ accepting the request and returning an operation response with one of\r
+ the successful status codes, the Printer adds the 'document-access-\r
+ error' value to the job's "job-state-reasons" attribute and MAY\r
+ populate the job's "job-document-access-errors" Job Description\r
+ attribute (see section 4.3.11). See The Implementer's Guide [IPP-\r
+ IIG] for suggested additional checks.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 48]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ If the Printer object supports this operation, it MUST support the\r
+ "reference-uri-schemes-supported" Printer attribute (see section\r
+ 4.4.27).\r
+\r
+ It is up to the IPP object to interpret the URI and subsequently\r
+ "pull" the document from the source referenced by the URI string.\r
+\r
+3.2.3 Validate-Job Operation\r
+\r
+ This REQUIRED operation is similar to the Print-Job operation\r
+ (section 3.2.1) except that a client supplies no document data and\r
+ the Printer allocates no resources (i.e., it does not create a new\r
+ Job object). This operation is used only to verify capabilities of a\r
+ printer object against whatever attributes are supplied by the client\r
+ in the Validate-Job request. By using the Validate-Job operation a\r
+ client can validate that an identical Print-Job operation (with the\r
+ document data) would be accepted. The Validate-Job operation also\r
+ performs the same security negotiation as the Print-Job operation\r
+ (see section 8), so that a client can check that the client and\r
+ Printer object security requirements can be met before performing a\r
+ Print-Job operation.\r
+\r
+ The Validate-Job operation does not accept a "document-uri" attribute\r
+ in order to allow a client to check that the same Print-URI operation\r
+ will be accepted, since the client doesn't send the data with the\r
+ Print-URI operation. The client SHOULD just issue the Print-URI\r
+ request.\r
+\r
+ The Printer object returns the same status codes, Operation\r
+ Attributes (Group 1) and Unsupported Attributes (Group 2) as the\r
+ Print-Job operation. However, no Job Object Attributes (Group 3) are\r
+ returned, since no Job object is created.\r
+\r
+3.2.4 Create-Job Operation\r
+\r
+ This OPTIONAL operation is similar to the Print-Job operation\r
+ (section 3.2.1) except that in the Create-Job request, a client does\r
+ not supply document data or any reference to document data. Also,\r
+ the client does not supply any of the "document-name", "document-\r
+ format", "compression", or "document-natural-language" operation\r
+ attributes. This operation is followed by one or more Send-Document\r
+ or Send-URI operations. In each of those operation requests, the\r
+ client OPTIONALLY supplies the "document-name", "document-format",\r
+ and "document-natural-language" attributes for each document in the\r
+ multi-document Job object.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 49]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ If a Printer object supports the Create-Job operation, it MUST also\r
+ support the Send-Document operation and also MAY support the Send-URI\r
+ operation.\r
+\r
+ If the Printer object supports this operation, it MUST support the\r
+ "multiple-operation-time-out" Printer attribute (see section 4.4.31).\r
+\r
+ If the Printer object supports this operation, then it MUST support\r
+ the "multiple-document-jobs-supported" Printer Description attribute\r
+ (see section 4.4.16) and indicate whether or not it supports\r
+ multiple-document jobs.\r
+\r
+ If the Printer object supports this operation and supports multiple\r
+ documents in a job, then it MUST support the "multiple-document-\r
+ handling" Job Template job attribute with at least one value (see\r
+ section 4.2.4) and the associated "multiple-document-handling-\r
+ default" and "multiple-document-handling-supported" Job Template\r
+ Printer attributes (see section 4.2).\r
+\r
+ After the Create-Job operation has completed, the value of the "job-\r
+ state" attribute is similar to the "job-state" after a Print-Job,\r
+ even though no document-data has arrived. A Printer MAY set the\r
+ 'job-data-insufficient' value of the job's "job-state-reason"\r
+ attribute to indicate that processing cannot begin until sufficient\r
+ data has arrived and set the "job-state" to either 'pending' or\r
+ 'pending-held'. A non-spooling printer that doesn't implement the\r
+ 'pending' job state may even set the "job-state" to 'processing',\r
+ even though there is not yet any data to process. See sections 4.3.7\r
+ and 4.3.8.\r
+\r
+3.2.5 Get-Printer-Attributes Operation\r
+\r
+ This REQUIRED operation allows a client to request the values of the\r
+ attributes of a Printer object. In the request, the client supplies\r
+ the set of Printer attribute names and/or attribute group names in\r
+ which the requester is interested. In the response, the Printer\r
+ object returns a corresponding attribute set with the appropriate\r
+ attribute values filled in.\r
+\r
+ For Printer objects, the possible names of attribute groups are:\r
+\r
+ - 'job-template': the subset of the Job Template attributes that\r
+ apply to a Printer object (the last two columns of the table in\r
+ Section 4.2) that the implementation supports for Printer\r
+ objects.\r
+ - 'printer-description': the subset of the attributes specified in\r
+ Section 4.4 that the implementation supports for Printer\r
+ objects.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 50]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - 'all': the special group 'all' that includes all attributes that\r
+ the implementation supports for Printer objects.\r
+\r
+ Since a client MAY request specific attributes or named groups, there\r
+ is a potential that there is some overlap. For example, if a client\r
+ requests, 'printer-name' and 'all', the client is actually requesting\r
+ the "printer-name" attribute twice: once by naming it explicitly, and\r
+ once by inclusion in the 'all' group. In such cases, the Printer\r
+ object NEED NOT return each attribute only once in the response even\r
+ if it is requested multiple times. The client SHOULD NOT request the\r
+ same attribute in multiple ways.\r
+\r
+ It is NOT REQUIRED that a Printer object support all attributes\r
+ belonging to a group (since some attributes are OPTIONAL). However,\r
+ it is REQUIRED that each Printer object support all group names.\r
+\r
+3.2.5.1 Get-Printer-Attributes Request\r
+\r
+ The following sets of attributes are part of the Get-Printer-\r
+ Attributes Request:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.1.\r
+\r
+ Target:\r
+ The "printer-uri" (uri) operation attribute which is the target\r
+ for this operation as described in section 3.1.5.\r
+\r
+ Requesting User Name:\r
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be\r
+ supplied by the client as described in section 8.3.\r
+\r
+ "requested-attributes" (1setOf keyword):\r
+ The client OPTIONALLY supplies a set of attribute names and/or\r
+ attribute group names in whose values the requester is\r
+ interested. The Printer object MUST support this attribute.\r
+ If the client omits this attribute, the Printer MUST respond as\r
+ if this attribute had been supplied with a value of 'all'.\r
+\r
+ "document-format" (mimeMediaType):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. This attribute is useful\r
+ for a Printer object to determine the set of supported\r
+ attribute values that relate to the requested document format.\r
+ The Printer object MUST return the attributes and values that\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 51]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ it uses to validate a job on a create or Validate-Job operation\r
+ in which this document format is supplied. The Printer object\r
+ SHOULD return only (1) those attributes that are supported for\r
+ the specified format and (2) the attribute values that are\r
+ supported for the specified document format. By specifying the\r
+ document format, the client can get the Printer object to\r
+ eliminate the attributes and values that are not supported for\r
+ a specific document format. For example, a Printer object\r
+ might have multiple interpreters to support both\r
+ 'application/postscript' (for PostScript) and 'text/plain' (for\r
+ text) documents. However, for only one of those interpreters\r
+ might the Printer object be able to support "number-up" with\r
+ values of '1', '2', and '4'. For the other interpreter it\r
+ might be able to only support "number-up" with a value of '1'.\r
+ Thus a client can use the Get-Printer-Attributes operation to\r
+ obtain the attributes and values that will be used to\r
+ accept/reject a create job operation.\r
+\r
+ If the Printer object does not distinguish between different\r
+ sets of supported values for each different document format\r
+ when validating jobs in the create and Validate-Job operations,\r
+ it MUST NOT distinguish between different document formats in\r
+ the Get-Printer-Attributes operation. If the Printer object\r
+ does distinguish between different sets of supported values for\r
+ each different document format specified by the client, this\r
+ specialization applies only to the following Printer object\r
+ attributes:\r
+\r
+ - Printer attributes that are Job Template attributes ("xxx-\r
+ default" "xxx-supported", and "xxx-ready" in the Table in\r
+ Section 4.2),\r
+ - "pdl-override-supported",\r
+ - "compression-supported",\r
+ - "job-k-octets-supported",\r
+ - "job-impressions-supported",\r
+ - "job-media-sheets-supported",\r
+ - "printer-driver-installer",\r
+ - "color-supported", and\r
+ - "reference-uri-schemes-supported"\r
+\r
+ The values of all other Printer object attributes (including\r
+ "document-format-supported") remain invariant with respect to the\r
+ client supplied document format (except for new Printer\r
+ description attribute as registered according to section 6.2).\r
+\r
+ If the client omits this "document-format" operation attribute,\r
+ the Printer object MUST respond as if the attribute had been\r
+ supplied with the value of the Printer object's "document-format-\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 52]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ default" attribute. It is RECOMMENDED that the client always\r
+ supply a value for "document-format", since the Printer object's\r
+ "document-format-default" may be 'application/octet-stream', in\r
+ which case the returned attributes and values are for the union of\r
+ the document formats that the Printer can automatically sense.\r
+ For more details, see the description of the 'mimeMediaType'\r
+ attribute syntax in section 4.1.9.\r
+\r
+ If the client supplies a value for the "document-format" Operation\r
+ attribute that is not supported by the Printer, i.e., is not among\r
+ the values of the Printer object's "document-format-supported"\r
+ attribute, the Printer object MUST reject the operation and return\r
+ the 'client-error-document-format-not-supported' status code.\r
+\r
+3.2.5.2 Get-Printer-Attributes Response\r
+\r
+ The Printer object returns the following sets of attributes as part\r
+ of the Get-Printer-Attributes Response:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Status Message:\r
+ In addition to the REQUIRED status code returned in every\r
+ response, the response OPTIONALLY includes a "status-message"\r
+ (text(255)) and/or a "detailed-status-message" (text(MAX))\r
+ operation attribute as described in sections 13 and 3.1.6.\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.2.\r
+\r
+ Group 2: Unsupported Attributes\r
+\r
+ See section 3.1.7 for details on returning Unsupported Attributes.\r
+\r
+ The response NEED NOT contain the "requested-attributes" operation\r
+ attribute with any supplied values (attribute keywords) that were\r
+ requested by the client but are not supported by the IPP object.\r
+ If the Printer object does return unsupported attributes\r
+ referenced in the "requested-attributes" operation attribute and\r
+ that attribute included group names, such as 'all', the\r
+ unsupported attributes MUST NOT include attributes described in\r
+ the standard but not supported by the implementation.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 53]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Group 3: Printer Object Attributes\r
+\r
+ This is the set of requested attributes and their current values.\r
+ The Printer object ignores (does not respond with) any requested\r
+ attribute which is not supported. The Printer object MAY respond\r
+ with a subset of the supported attributes and values, depending on\r
+ the security policy in force. However, the Printer object MUST\r
+ respond with the 'unknown' value for any supported attribute\r
+ (including all REQUIRED attributes) for which the Printer object\r
+ does not know the value. Also the Printer object MUST respond\r
+ with the 'no-value' for any supported attribute (including all\r
+ REQUIRED attributes) for which the system administrator has not\r
+ configured a value. See the description of the "out-of-band"\r
+ values in the beginning of Section 4.1.\r
+\r
+3.2.6 Get-Jobs Operation\r
+\r
+ This REQUIRED operation allows a client to retrieve the list of Job\r
+ objects belonging to the target Printer object. The client may also\r
+ supply a list of Job attribute names and/or attribute group names. A\r
+ group of Job object attributes will be returned for each Job object\r
+ that is returned.\r
+\r
+ This operation is similar to the Get-Job-Attributes operation, except\r
+ that this Get-Jobs operation returns attributes from possibly more\r
+ than one object.\r
+\r
+3.2.6.1 Get-Jobs Request\r
+\r
+ The client submits the Get-Jobs request to a Printer object.\r
+\r
+ The following groups of attributes are part of the Get-Jobs Request:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.1.\r
+\r
+ Target:\r
+ The "printer-uri" (uri) operation attribute which is the target\r
+ for this operation as described in section 3.1.5.\r
+\r
+ Requesting User Name:\r
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be\r
+ supplied by the client as described in section 8.3.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 54]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ "limit" (integer(1:MAX)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. It is an integer value that\r
+ determines the maximum number of jobs that a client will\r
+ receive from the Printer even if "which-jobs" or "my-jobs"\r
+ constrain which jobs are returned. The limit is a "stateless\r
+ limit" in that if the value supplied by the client is 'N', then\r
+ only the first 'N' jobs are returned in the Get-Jobs Response.\r
+ There is no mechanism to allow for the next 'M' jobs after the\r
+ first 'N' jobs. If the client does not supply this attribute,\r
+ the Printer object responds with all applicable jobs.\r
+\r
+ "requested-attributes" (1setOf type2 keyword):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. It is a set of Job\r
+ attribute names and/or attribute groups names in whose values\r
+ the requester is interested. This set of attributes is\r
+ returned for each Job object that is returned. The allowed\r
+ attribute group names are the same as those defined in the\r
+ Get-Job-Attributes operation in section 3.3.4. If the client\r
+ does not supply this attribute, the Printer MUST respond as if\r
+ the client had supplied this attribute with two values: 'job-\r
+ uri' and 'job-id'.\r
+\r
+ "which-jobs" (type2 keyword):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. It indicates which Job\r
+ objects MUST be returned by the Printer object. The values for\r
+ this attribute are:\r
+\r
+ 'completed': This includes any Job object whose state is\r
+ 'completed', 'canceled', or 'aborted'.\r
+ 'not-completed': This includes any Job object whose state is\r
+ 'pending', 'processing', 'processing-stopped', or 'pending-\r
+ held'.\r
+\r
+ A Printer object MUST support both values. However, if the\r
+ implementation does not keep jobs in the 'completed',\r
+ 'canceled', and 'aborted' states, then it returns no jobs when\r
+ the 'completed' value is supplied.\r
+\r
+ If a client supplies some other value, the Printer object MUST\r
+ copy the attribute and the unsupported value to the Unsupported\r
+ Attributes response group, reject the request, and return the\r
+ 'client-error-attributes-or-values-not-supported' status code.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 55]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ If the client does not supply this attribute, the Printer\r
+ object MUST respond as if the client had supplied the attribute\r
+ with a value of 'not-completed'.\r
+\r
+ "my-jobs" (boolean):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. It indicates whether jobs\r
+ from all users or just the jobs submitted by the requesting\r
+ user of this request MUST be considered as candidate jobs to be\r
+ returned by the Printer object. If the client does not supply\r
+ this attribute, the Printer object MUST respond as if the\r
+ client had supplied the attribute with a value of 'false',\r
+ i.e., jobs from all users. The means for authenticating the\r
+ requesting user and matching the jobs is described in section\r
+ 8.\r
+\r
+3.2.6.2 Get-Jobs Response\r
+\r
+ The Printer object returns all of the Job objects up to the number\r
+ specified by the "limit" attribute that match the criteria as defined\r
+ by the attribute values supplied by the client in the request. It is\r
+ possible that no Job objects are returned since there may literally\r
+ be no Job objects at the Printer, or there may be no Job objects that\r
+ match the criteria supplied by the client. If the client requests\r
+ any Job attributes at all, there is a set of Job Object Attributes\r
+ returned for each Job object.\r
+\r
+ It is not an error for the Printer to return 0 jobs. If the response\r
+ returns 0 jobs because there are no jobs matching the criteria, and\r
+ the request would have returned 1 or more jobs with a status code of\r
+ 'successful-ok' if there had been jobs matching the criteria, then\r
+ the status code for 0 jobs MUST be 'successful-ok'.\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Status Message:\r
+ In addition to the REQUIRED status code returned in every\r
+ response, the response OPTIONALLY includes a "status-message"\r
+ (text(255)) and/or a "detailed-status-message" (text(MAX))\r
+ operation attribute as described in sections 13 and 3.1.6.\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.2.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 56]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Group 2: Unsupported Attributes\r
+\r
+ See section 3.1.7 for details on returning Unsupported Attributes.\r
+\r
+ The response NEED NOT contain the "requested-attributes" operation\r
+ attribute with any supplied values (attribute keywords) that were\r
+ requested by the client but are not supported by the IPP object.\r
+ If the Printer object does return unsupported attributes\r
+ referenced in the "requested-attributes" operation attribute and\r
+ that attribute included group names, such as 'all', the\r
+ unsupported attributes MUST NOT include attributes described in\r
+ the standard but not supported by the implementation.\r
+\r
+ Groups 3 to N: Job Object Attributes\r
+\r
+ The Printer object responds with one set of Job Object Attributes\r
+ for each returned Job object. The Printer object ignores (does\r
+ not respond with) any requested attribute or value which is not\r
+ supported or which is restricted by the security policy in force,\r
+ including whether the requesting user is the user that submitted\r
+ the job (job originating user) or not (see section 8). However,\r
+ the Printer object MUST respond with the 'unknown' value for any\r
+ supported attribute (including all REQUIRED attributes) for which\r
+ the Printer object does not know the value, unless it would\r
+ violate the security policy. See the description of the "out-of-\r
+ band" values in the beginning of Section 4.1.\r
+\r
+ Jobs are returned in the following order:\r
+\r
+ - If the client requests all 'completed' Jobs (Jobs in the\r
+ 'completed', 'aborted', or 'canceled' states), then the Jobs are\r
+ returned newest to oldest (with respect to actual completion\r
+ time)\r
+ - If the client requests all 'not-completed' Jobs (Jobs in the\r
+ 'pending', 'processing', 'pending-held', and 'processing-\r
+ stopped' states), then Jobs are returned in relative\r
+ chronological order of expected time to complete (based on\r
+ whatever scheduling algorithm is configured for the Printer\r
+ object).\r
+\r
+3.2.7 Pause-Printer Operation\r
+\r
+ This OPTIONAL operation allows a client to stop the Printer object\r
+ from scheduling jobs on all its devices. Depending on\r
+ implementation, the Pause-Printer operation MAY also stop the Printer\r
+ from processing the current job or jobs. Any job that is currently\r
+ being printed is either stopped as soon as the implementation permits\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 57]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ or is completed, depending on implementation. The Printer object\r
+ MUST still accept create operations to create new jobs, but MUST\r
+ prevent any jobs from entering the 'processing' state.\r
+\r
+ If the Pause-Printer operation is supported, then the Resume-Printer\r
+ operation MUST be supported, and vice-versa.\r
+\r
+ The IPP Printer stops the current job(s) on its device(s) that were\r
+ in the 'processing' or 'processing-stopped' states as soon as the\r
+ implementation permits. If the implementation will take appreciable\r
+ time to stop, the IPP Printer adds the 'moving-to-paused' value to\r
+ the Printer object's "printer-state-reasons" attribute (see section\r
+ 4.4.12). When the device(s) have all stopped, the IPP Printer\r
+ transitions the Printer object to the 'stopped' state, removes the\r
+ 'moving-to-paused' value, if present, and adds the 'paused' value to\r
+ the Printer object's "printer-state-reasons" attribute.\r
+\r
+ When the current job(s) complete that were in the 'processing' state,\r
+ the IPP Printer transitions them to the 'completed' state. When the\r
+ current job(s) stop in mid processing that were in the 'processing'\r
+ state, the IPP Printer transitions them to the 'processing-stopped'\r
+ state and adds the 'printer-stopped' value to the job's "job-state-\r
+ reasons" attribute.\r
+\r
+ For any jobs that are 'pending' or 'pending-held', the 'printer-\r
+ stopped' value of the jobs' "job-state-reasons" attribute also\r
+ applies. However, the IPP Printer NEED NOT update those jobs' "job-\r
+ state-reasons" attributes and only need return the 'printer-stopped'\r
+ value when those jobs are queried (so-called "lazy evaluation").\r
+\r
+ Whether the Pause-Printer operation affects jobs that were submitted\r
+ to the device from other sources than the IPP Printer object in the\r
+ same way that the Pause-Printer operation affects jobs that were\r
+ submitted to the IPP Printer object using IPP, depends on\r
+ implementation, i.e., on whether the IPP protocol is being used as a\r
+ universal management protocol or just to manage IPP jobs,\r
+ respectively.\r
+\r
+ The IPP Printer MUST accept the request in any state and transition\r
+ the Printer to the indicated new "printer-state" before returning as\r
+ follows:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 58]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Current New "printer IPP Printer's response status\r
+ "printer- "printer- -state- code and action:\r
+ state" state" reasons"\r
+\r
+ 'idle' 'stopped' 'paused' 'successful-ok'\r
+ 'processing' 'processing' 'moving- OPTION 1: 'successful-ok';\r
+ to- Later, when all output has\r
+ paused' stopped, the "printer-state"\r
+ becomes 'stopped', and the\r
+ 'paused' value replaces the\r
+ 'moving-to-paused' value in the\r
+ "printer-state-reasons"\r
+ attribute\r
+ 'processing' 'stopped' 'paused' OPTION 2: 'successful-ok';\r
+ all device output stopped\r
+ immediately\r
+ 'stopped' 'stopped' 'paused' 'successful-ok'\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must be an operator or administrator of the Printer\r
+ object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST\r
+ reject the operation and return: 'client-error-forbidden', 'client-\r
+ error-not-authenticated', or 'client-error-not-authorized' as\r
+ appropriate.\r
+\r
+3.2.7.1 Pause-Printer Request\r
+\r
+ The following groups of attributes are part of the Pause-Printer\r
+ Request:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.1.\r
+\r
+ Target:\r
+ The "printer-uri" (uri) operation attribute which is the target\r
+ for this operation as described in section 3.1.5.\r
+\r
+ Requesting User Name:\r
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be\r
+ supplied by the client as described in section 8.3.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 59]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.2.7.2 Pause-Printer Response\r
+\r
+ The following groups of attributes are part of the Pause-Printer\r
+ Response:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Status Message:\r
+ In addition to the REQUIRED status code returned in every\r
+ response, the response OPTIONALLY includes a "status-message"\r
+ (text(255)) and/or a "detailed-status-message" (text(MAX))\r
+ operation attribute as described in sections 13 and 3.1.6.\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.2.\r
+\r
+ Group 2: Unsupported Attributes\r
+\r
+ See section 3.1.7 for details on returning Unsupported Attributes.\r
+\r
+3.2.8 Resume-Printer Operation\r
+\r
+ This operation allows a client to resume the Printer object\r
+ scheduling jobs on all its devices. The Printer object MUST remove\r
+ the 'paused' and 'moving-to-paused' values from the Printer object's\r
+ "printer-state-reasons" attribute, if present. If there are no other\r
+ reasons to keep a device paused (such as media-jam), the IPP Printer\r
+ is free to transition itself to the 'processing' or 'idle' states,\r
+ depending on whether there are jobs to be processed or not,\r
+ respectively, and the device(s) resume processing jobs.\r
+\r
+ If the Pause-Printer operation is supported, then the Resume-Printer\r
+ operation MUST be supported, and vice-versa.\r
+\r
+ The IPP Printer removes the 'printer-stopped' value from any job's\r
+ "job-state-reasons" attributes contained in that Printer.\r
+\r
+ The IPP Printer MUST accept the request in any state, transition the\r
+ Printer object to the indicated new state as follows:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 60]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Current New "printer- IPP Printer's response status code and\r
+ "printer- state" action:\r
+ state"\r
+\r
+ 'idle' 'idle' 'successful-ok'\r
+ 'processing' 'processing' 'successful-ok'\r
+\r
+ 'stopped' 'processing' 'successful-ok';\r
+ when there are jobs to be processed\r
+ 'stopped' 'idle' 'successful-ok';\r
+ when there are no jobs to be processed.\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must be an operator or administrator of the Printer\r
+ object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST\r
+ reject the operation and return: 'client-error-forbidden', 'client-\r
+ error-not-authenticated', or 'client-error-not-authorized' as\r
+ appropriate.\r
+\r
+ The Resume-Printer Request and Resume-Printer Response have the same\r
+ attribute groups and attributes as the Pause-Printer operation (see\r
+ sections 3.2.7.1 and 3.2.7.2).\r
+\r
+3.2.9 Purge-Jobs Operation\r
+\r
+ This OPTIONAL operation allows a client to remove all jobs from an\r
+ IPP Printer object, regardless of their job states, including jobs in\r
+ the Printer object's Job History (see Section 4.3.7.2). After a\r
+ Purge-Jobs operation has been performed, a Printer object MUST return\r
+ no jobs in subsequent Get-Job-Attributes and Get-Jobs responses\r
+ (until new jobs are submitted).\r
+\r
+ Whether the Purge-Jobs (and Get-Jobs) operation affects jobs that\r
+ were submitted to the device from other sources than the IPP Printer\r
+ object in the same way that the Purge-Jobs operation affects jobs\r
+ that were submitted to the IPP Printer object using IPP, depends on\r
+ implementation, i.e., on whether the IPP protocol is being used as a\r
+ universal management protocol or just to manage IPP jobs,\r
+ respectively.\r
+\r
+ Note: if an operator wants to cancel all jobs without clearing out\r
+ the Job History, the operator uses the Cancel-Job operation on each\r
+ job instead of using the Purge-Jobs operation.\r
+\r
+ The Printer object MUST accept this operation in any state and\r
+ transition the Printer object to the 'idle' state.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 61]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must be an operator or administrator of the Printer\r
+ object (see Sections 1 and 8.5). Otherwise, the IPP object MUST\r
+ reject the operation and return: client-error-forbidden, client-\r
+ error-not-authenticated, and client-error-not-authorized as\r
+ appropriate.\r
+\r
+ The Purge-Jobs Request and Purge-Jobs Response have the same\r
+ attribute groups and attributes as the Pause-Printer operation (see\r
+ sections 3.2.7.1 and 3.2.7.2).\r
+\r
+3.3 Job Operations\r
+\r
+ All Job operations are directed at Job objects. A client MUST always\r
+ supply some means of identifying the Job object in order to identify\r
+ the correct target of the operation. That job identification MAY\r
+ either be a single Job URI or a combination of a Printer URI with a\r
+ Job ID. The IPP object implementation MUST support both forms of\r
+ identification for every job.\r
+\r
+3.3.1 Send-Document Operation\r
+\r
+ This OPTIONAL operation allows a client to create a multi-document\r
+ Job object that is initially "empty" (contains no documents). In the\r
+ Create-Job response, the Printer object returns the Job object's URI\r
+ (the "job-uri" attribute) and the Job object's 32-bit identifier (the\r
+ "job-id" attribute). For each new document that the client desires\r
+ to add, the client uses a Send-Document operation. Each Send-\r
+ Document Request contains the entire stream of document data for one\r
+ document.\r
+\r
+ If the Printer supports this operation but does not support multiple\r
+ documents per job, the Printer MUST reject subsequent Send-Document\r
+ operations supplied with data and return the 'server-error-multiple-\r
+ document-jobs-not-supported'. However, the Printer MUST accept the\r
+ first document with a 'true' or 'false' value for the "last-document"\r
+ operation attribute (see below), so that clients MAY always submit\r
+ one document jobs with a 'false' value for "last-document" in the\r
+ first Send-Document and a 'true' for "last-document" in the second\r
+ Send-Document (with no data).\r
+\r
+ Since the Create-Job and the send operations (Send-Document or Send-\r
+ URI operations) that follow could occur over an arbitrarily long\r
+ period of time for a particular job, a client MUST send another send\r
+ operation within an IPP Printer defined minimum time interval after\r
+ the receipt of the previous request for the job. If a Printer object\r
+ supports the Create-Job and Send-Document operations, the Printer\r
+ object MUST support the "multiple-operation-time-out" attribute (see\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 62]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ section 4.4.31). This attribute indicates the minimum number of\r
+ seconds the Printer object will wait for the next send operation\r
+ before taking some recovery action.\r
+\r
+ An IPP object MUST recover from an errant client that does not supply\r
+ a send operation, sometime after the minimum time interval specified\r
+ by the Printer object's "multiple-operation-time-out" attribute.\r
+ Such recovery MAY include any of the following or other recovery\r
+ actions:\r
+\r
+ 1. Assume that the Job is an invalid job, start the process of\r
+ changing the job state to 'aborted', add the 'aborted-by-\r
+ system' value to the job's "job-state-reasons" attribute (see\r
+ section 4.3.8), and clean up all resources associated with the\r
+ Job. In this case, if another send operation is finally\r
+ received, the Printer responds with an "client-error-not-\r
+ possible" or "client-error-not-found" depending on whether or\r
+ not the Job object is still around when the send operation\r
+ finally arrives.\r
+ 2. Assume that the last send operation received was in fact the\r
+ last document (as if the "last-document" flag had been set to\r
+ 'true'), close the Job object, and proceed to process it (i.e.,\r
+ move the Job's state to 'pending').\r
+ 3. Assume that the last send operation received was in fact the\r
+ last document, close the Job, but move it to the 'pending-held'\r
+ and add the 'submission-interrupted' value to the job's "job-\r
+ state-reasons" attribute (see section 4.3.8). This action\r
+ allows the user or an operator to determine whether to continue\r
+ processing the Job by moving it back to the 'pending' state\r
+ using the Release-Job operation (see section 3.3.6) or to\r
+ cancel the job using the Cancel-Job operation (see section\r
+ 3.3.3).\r
+\r
+ Each implementation is free to decide the "best" action to take\r
+ depending on local policy, whether any documents have been added,\r
+ whether the implementation spools jobs or not, and/or any other\r
+ piece of information available to it. If the choice is to abort the\r
+ Job object, it is possible that the Job object may already have been\r
+ processed to the point that some media sheet pages have been printed.\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must either be the job owner (as determined in the\r
+ Create-Job operation) or an operator or administrator of the Printer\r
+ object (see Sections 1 and 8.5). Otherwise, the IPP object MUST\r
+ reject the operation and return: 'client-error-forbidden', 'client-\r
+ error-not-authenticated', or 'client-error-not-authorized' as\r
+ appropriate.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 63]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.3.1.1 Send-Document Request\r
+\r
+ The following attribute sets are part of the Send-Document Request:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.1.\r
+\r
+ Target:\r
+ Either (1) the "printer-uri" (uri) plus "job-id"\r
+ (integer(1:MAX))or (2) the "job-uri" (uri) operation\r
+ attribute(s) which define the target for this operation as\r
+ described in section 3.1.5.\r
+\r
+ Requesting User Name:\r
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be\r
+ supplied by the client as described in section 8.3.\r
+\r
+ "document-name" (name(MAX)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object MUST support this attribute. It contains the client\r
+ supplied document name. The document name MAY be different than\r
+ the Job name. It might be helpful, but NEED NOT be unique\r
+ across multiple documents in the same Job. Typically, the\r
+ client software automatically supplies the document name on\r
+ behalf of the end user by using a file name or an application\r
+ generated name. See the description of the "document-name"\r
+ operation attribute in the Print-Job Request (section 3.2.1.1)\r
+ for more information about this attribute.\r
+\r
+ "compression" (type3 keyword):\r
+ See the description of "compression" for the Print-Job operation\r
+ in Section 3.2.1.1.\r
+\r
+ "document-format" (mimeMediaType):\r
+ See the description of "document-format" for the Print-Job\r
+ operation in Section 3.2.1.1.\r
+\r
+ "document-natural-language" (naturalLanguage):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object OPTIONALLY supports this attribute. This attribute\r
+ specifies the natural language of the document for those\r
+ document-formats that require a specification of the natural\r
+ language in order to image the document unambiguously. There\r
+ are no particular values required for the Printer object to\r
+ support.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 64]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ "last-document" (boolean):\r
+ The client MUST supply this attribute. The Printer object MUST\r
+ support this attribute. It is a boolean flag that is set to\r
+ 'true' if this is the last document for the Job, 'false'\r
+ otherwise.\r
+\r
+ Group 2: Document Content\r
+\r
+ The client MUST supply the document data if the "last-document"\r
+ flag is set to 'false'. However, since a client might not know\r
+ that the previous document sent with a Send-Document (or Send-URI)\r
+ operation was the last document (i.e., the "last-document"\r
+ attribute was set to 'false'), it is legal to send a Send-Document\r
+ request with no document data where the "last-document" flag is\r
+ set to 'true'. Such a request MUST NOT increment the value of the\r
+ Job object's "number-of-documents" attribute, since no real\r
+ document was added to the job. It is not an error for a client to\r
+ submit a job with no actual document data, i.e., only a single\r
+ Create-Job and Send-Document request with a "last-document"\r
+ operation attribute set to 'true' with no document data.\r
+\r
+3.3.1.2 Send-Document Response\r
+\r
+ The following sets of attributes are part of the Send-Document\r
+ Response:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Status Message:\r
+ In addition to the REQUIRED status code returned in every\r
+ response, the response OPTIONALLY includes a "status-message"\r
+ (text(255)) and/or a "detailed-status-message" (text(MAX))\r
+ operation attribute as described in sections 13 and 3.1.6.\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.2.\r
+\r
+ Group 2: Unsupported Attributes\r
+\r
+ See section 3.1.7 for details on returning Unsupported Attributes.\r
+\r
+ Group 3: Job Object Attributes\r
+\r
+ This is the same set of attributes as described in the Print-Job\r
+ response (see section 3.2.1.2).\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 65]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.3.2 Send-URI Operation\r
+\r
+ This OPTIONAL operation is identical to the Send-Document operation\r
+ (see section 3.3.1) except that a client MUST supply a URI reference\r
+ ("document-uri" operation attribute) rather than the document data\r
+ itself. If a Printer object supports this operation, clients can use\r
+ both Send-URI or Send-Document operations to add new documents to an\r
+ existing multi-document Job object. However, if a client needs to\r
+ indicate that the previous Send-URI or Send-Document was the last\r
+ document, the client MUST use the Send-Document operation with no\r
+ document data and the "last-document" flag set to 'true' (rather than\r
+ using a Send-URI operation with no "document-uri" operation\r
+ attribute).\r
+\r
+ If a Printer object supports this operation, it MUST also support the\r
+ Print-URI operation (see section 3.2.2).\r
+\r
+ The Printer object MUST validate the syntax and URI scheme of the\r
+ supplied URI before returning a response, just as in the Print-URI\r
+ operation. The IPP Printer MAY validate the accessibility of the\r
+ document as part of the operation or subsequently (see section\r
+ 3.2.2).\r
+\r
+3.3.3 Cancel-Job Operation\r
+\r
+ This REQUIRED operation allows a client to cancel a Print Job from\r
+ the time the job is created up to the time it is completed, canceled,\r
+ or aborted. Since a Job might already be printing by the time a\r
+ Cancel-Job is received, some media sheet pages might be printed\r
+ before the job is actually terminated.\r
+\r
+ The IPP object MUST accept or reject the request based on the job's\r
+ current state and transition the job to the indicated new state as\r
+ follows:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 66]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Current "job- New "job- IPP object's response status\r
+ state" state" code and action:\r
+\r
+ 'pending' 'canceled' 'successful-ok'\r
+ 'pending-held' 'canceled' 'successful-ok'\r
+ 'processing' 'canceled' 'successful-ok'\r
+ 'processing' 'processing' 'successful-ok' See Rule 1\r
+ 'processing' 'processing' 'client-error-not-possible'\r
+ See Rule 2\r
+ 'processing- 'canceled' 'successful-ok'\r
+ stopped'\r
+ 'processing- 'processing- 'successful-ok' See Rule 1\r
+ stopped' stopped'\r
+ 'processing- 'processing- 'client-error-not-possible'\r
+ stopped' stopped' See Rule 2\r
+ 'completed' 'completed' 'client-error-not-possible'\r
+ 'canceled' 'canceled' 'client-error-not-possible'\r
+ 'aborted' 'aborted' 'client-error-not-possible'\r
+\r
+ Rule 1: If the implementation requires some measurable time to\r
+ cancel the job in the 'processing' or 'processing-stopped' job\r
+ states, the IPP object MUST add the 'processing-to-stop-point' value\r
+ to the job's "job-state-reasons" attribute and then transition the\r
+ job to the 'canceled' state when the processing ceases (see section\r
+ 4.3.8).\r
+\r
+ Rule 2: If the Job object already has the 'processing-to-stop-point'\r
+ value in its "job-state-reasons" attribute, then the Printer object\r
+ MUST reject a Cancel-Job operation.\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must either be the job owner or an operator or\r
+ administrator of the Printer object (see Sections 1 and 8.5).\r
+ Otherwise, the IPP object MUST reject the operation and return:\r
+ 'client-error-forbidden', 'client-error-not-authenticated', or\r
+ 'client-error-not-authorized' as appropriate.\r
+\r
+3.3.3.1 Cancel-Job Request\r
+\r
+ The following groups of attributes are part of the Cancel-Job\r
+ Request:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.1.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 67]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Target:\r
+ Either (1) the "printer-uri" (uri) plus "job-id"\r
+ (integer(1:MAX))or (2) the "job-uri" (uri) operation\r
+ attribute(s) which define the target for this operation as\r
+ described in section 3.1.5.\r
+\r
+ Requesting User Name:\r
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be\r
+ supplied by the client as described in section 8.3.\r
+\r
+ "message" (text(127)):\r
+ The client OPTIONALLY supplies this attribute. The Printer\r
+ object OPTIONALLY supports this attribute. It is a message to\r
+ the operator. This "message" attribute is not the same as the\r
+ "job-message-from-operator" attribute. That attribute is used\r
+ to report a message from the operator to the end user that\r
+ queries that attribute. This "message" operation attribute is\r
+ used to send a message from the client to the operator along\r
+ with the operation request. It is an implementation decision\r
+ of how or where to display this message to the operator (if at\r
+ all).\r
+\r
+3.3.3.2 Cancel-Job Response\r
+\r
+ The following sets of attributes are part of the Cancel-Job Response:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Status Message:\r
+ In addition to the REQUIRED status code returned in every\r
+ response, the response OPTIONALLY includes a "status-message"\r
+ (text(255)) and/or a "detailed-status-message" (text(MAX))\r
+ operation attribute as described in sections 13 and 3.1.6.\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.2.\r
+\r
+ Group 2: Unsupported Attributes\r
+\r
+ See section 3.1.7 for details on returning Unsupported Attributes.\r
+\r
+ Once a successful response has been sent, the implementation\r
+ guarantees that the Job will eventually end up in the 'canceled'\r
+ state. Between the time of the Cancel-Job operation is accepted and\r
+ when the job enters the 'canceled' job-state (see section 4.3.7), the\r
+ "job-state-reasons" attribute SHOULD contain the 'processing-to-\r
+ stop-point'\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 68]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ value which indicates to later queries that although the Job might\r
+ still be 'processing', it will eventually end up in the\r
+ 'canceled' state, not the 'completed' state.\r
+\r
+3.3.4 Get-Job-Attributes Operation\r
+\r
+ This REQUIRED operation allows a client to request the values of\r
+ attributes of a Job object and it is almost identical to the Get-\r
+ Printer-Attributes operation (see section 3.2.5). The only\r
+ differences are that the operation is directed at a Job object rather\r
+ than a Printer object, there is no "document-format" operation\r
+ attribute used when querying a Job object, and the returned attribute\r
+ group is a set of Job object attributes rather than a set of Printer\r
+ object attributes.\r
+\r
+ For Jobs, the possible names of attribute groups are:\r
+\r
+ - 'job-template': the subset of the Job Template attributes that\r
+ apply to a Job object (the first column of the table in Section\r
+ 4.2) that the implementation supports for Job objects.\r
+ - 'job-description': the subset of the Job Description attributes\r
+ specified in Section 4.3 that the implementation supports for\r
+ Job objects.\r
+ - 'all': the special group 'all' that includes all attributes that\r
+ the implementation supports for Job objects.\r
+\r
+ Since a client MAY request specific attributes or named groups, there\r
+ is a potential that there is some overlap. For example, if a client\r
+ requests, 'job-name' and 'job-description', the client is actually\r
+ requesting the "job-name" attribute once by naming it explicitly, and\r
+ once by inclusion in the 'job-description' group. In such cases, the\r
+ Printer object NEED NOT return the attribute only once in the\r
+ response even if it is requested multiple times. The client SHOULD\r
+ NOT request the same attribute in multiple ways.\r
+\r
+ It is NOT REQUIRED that a Job object support all attributes belonging\r
+ to a group (since some attributes are OPTIONAL). However it is\r
+ REQUIRED that each Job object support all these group names.\r
+\r
+3.3.4.1 Get-Job-Attributes Request\r
+\r
+ The following groups of attributes are part of the Get-Job-Attributes\r
+ Request when the request is directed at a Job object:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 69]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.1.\r
+\r
+ Target:\r
+ Either (1) the "printer-uri" (uri) plus "job-id"\r
+ (integer(1:MAX)) or (2) the "job-uri" (uri) operation\r
+ attribute(s) which define the target for this operation as\r
+ described in section 3.1.5.\r
+\r
+ Requesting User Name:\r
+ The "requesting-user-name" (name(MAX)) attribute SHOULD be\r
+ supplied by the client as described in section 8.3.\r
+\r
+ "requested-attributes" (1setOf keyword):\r
+ The client OPTIONALLY supplies this attribute. The IPP object\r
+ MUST support this attribute. It is a set of attribute names\r
+ and/or attribute group names in whose values the requester is\r
+ interested. If the client omits this attribute, the IPP object\r
+ MUST respond as if this attribute had been supplied with a value\r
+ of 'all'.\r
+\r
+3.3.4.2 Get-Job-Attributes Response\r
+\r
+ The Printer object returns the following sets of attributes as part\r
+ of the Get-Job-Attributes Response:\r
+\r
+ Group 1: Operation Attributes\r
+\r
+ Status Message:\r
+ In addition to the REQUIRED status code returned in every\r
+ response, the response OPTIONALLY includes a "status-message"\r
+ (text(255)) and/or a "detailed-status-message" (text(MAX))\r
+ operation attribute as described in sections 13 and 3.1.6.\r
+\r
+ Natural Language and Character Set:\r
+ The "attributes-charset" and "attributes-natural-language"\r
+ attributes as described in section 3.1.4.2. The "attributes-\r
+ natural-language" MAY be the natural language of the Job\r
+ object, rather than the one requested.\r
+\r
+ Group 2: Unsupported Attributes\r
+\r
+ See section 3.1.7 for details on returning Unsupported Attributes.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 70]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The response NEED NOT contain the "requested-attributes" operation\r
+ attribute with any supplied values (attribute keywords) that were\r
+ requested by the client but are not supported by the IPP object.\r
+ If the Printer object does return unsupported attributes\r
+ referenced in the "requested-attributes" operation attribute and\r
+ that attribute included group names, such as 'all', the\r
+ unsupported attributes MUST NOT include attributes described in\r
+ the standard but not supported by the implementation.\r
+\r
+ Group 3: Job Object Attributes\r
+\r
+ This is the set of requested attributes and their current values.\r
+ The IPP object ignores (does not respond with) any requested\r
+ attribute or value which is not supported or which is restricted\r
+ by the security policy in force, including whether the requesting\r
+ user is the user that submitted the job (job originating user) or\r
+ not (see section 8). However, the IPP object MUST respond with\r
+ the 'unknown' value for any supported attribute (including all\r
+ REQUIRED attributes) for which the IPP object does not know the\r
+ value, unless it would violate the security policy. See the\r
+ description of the "out-of-band" values in the beginning of\r
+ Section 4.1.\r
+\r
+3.3.5 Hold-Job Operation\r
+\r
+ This OPTIONAL operation allows a client to hold a pending job in the\r
+ queue so that it is not eligible for scheduling. If the Hold-Job\r
+ operation is supported, then the Release-Job operation MUST be\r
+ supported, and vice-versa. The OPTIONAL "job-hold-until" operation\r
+ attribute allows a client to specify whether to hold the job\r
+ indefinitely or until a specified time period, if supported.\r
+\r
+ The IPP object MUST accept or reject the request based on the job's\r
+ current state and transition the job to the indicated new state as\r
+ follows:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 71]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Current "job- New "job-state" IPP object's response status\r
+ state" code and action:\r
+\r
+ 'pending' 'pending-held' 'successful-ok' See Rule 1\r
+ 'pending' 'pending' 'successful-ok' See Rule 2\r
+ 'pending-held' 'pending-held' 'successful-ok' See Rule 1\r
+ 'pending-held' 'pending' 'successful-ok' See Rule 2\r
+ 'processing' 'processing' 'client-error-not-possible'\r
+ 'processing- 'processing- 'client-error-not-possible'\r
+ stopped' stopped'\r
+ 'completed' 'completed' 'client-error-not-possible'\r
+ 'canceled' 'canceled' 'client-error-not-possible'\r
+ 'aborted' 'aborted' 'client-error-not-possible'\r
+\r
+ Rule 1: If the implementation supports multiple reasons for a job to\r
+ be in the 'pending-held' state, the IPP object MUST add the 'job-\r
+ hold-until-specified' value to the job's "job-state-reasons"\r
+ attribute.\r
+\r
+ Rule 2: If the IPP object supports the "job-hold-until" operation\r
+ attribute, but the specified time period has already started (or is\r
+ the 'no-hold' value) and there are no other reasons to hold the job,\r
+ the IPP object MUST make the job be a candidate for processing\r
+ immediately (see Section 4.2.2) by putting the job in the 'pending'\r
+ state.\r
+\r
+ Note: In order to keep the Hold-Job operation simple, such a request\r
+ is rejected when the job is in the 'processing' or 'processing-\r
+ stopped' states. If an operation is needed to hold jobs while in\r
+ these states, it will be added as an additional operation, rather\r
+ than overloading the Hold-Job operation. Then it is clear to clients\r
+ by querying the Printer object's "operations-supported" (see Section\r
+ 4.4.15) and the Job object's "job-state" (see Section 4.3.7)\r
+ attributes which operations are possible.\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must either be the job owner or an operator or\r
+ administrator of the Printer object (see Sections 1 and 8.5).\r
+ Otherwise, the IPP object MUST reject the operation and return:\r
+ 'client-error-forbidden', 'client-error-not-authenticated', or\r
+ 'client-error-not-authorized' as appropriate.\r
+\r
+3.3.5.1 Hold-Job Request\r
+\r
+ The groups and operation attributes are the same as for a Cancel-Job\r
+ request (see section 3.3.3.1), with the addition of the following\r
+ Group 1 Operation attribute:\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 72]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ "job-hold-until" (type3 keyword | name(MAX)):\r
+ The client OPTIONALLY supplies this Operation attribute. The\r
+ IPP object MUST support this operation attribute in a Hold-Job\r
+ request, if it supports the "job-hold-until" Job template\r
+ attribute in create operations. See section 4.2.2. The IPP\r
+ object SHOULD support the "job-hold-until" Job Template\r
+ attribute for use in job create operations with at least the\r
+ 'indefinite' value, if it supports the Hold-Job operation.\r
+ Otherwise, a client cannot create a job and hold it immediately\r
+ (without picking some supported time period in the future).\r
+\r
+ If supplied and supported as specified in the Printer's "job-\r
+ hold-until-supported" attribute, the IPP object copies the\r
+ supplied operation attribute to the Job object, replacing the\r
+ job's previous "job-hold-until" attribute, if present, and\r
+ makes the job a candidate for scheduling during the supplied\r
+ named time period.\r
+\r
+ If supplied, but either the "job-hold-until" Operation\r
+ attribute itself or the value supplied is not supported, the\r
+ IPP object accepts the request, returns the unsupported\r
+ attribute or value in the Unsupported Attributes Group\r
+ according to section 3.1.7, returns the 'successful-ok-\r
+ ignored-or-substituted-attributes, and holds the job\r
+ indefinitely until a client performs a subsequent Release-Job\r
+ operation.\r
+\r
+ If the client (1) supplies a value that specifies a time period\r
+ that has already started or the 'no-hold' value (meaning don't\r
+ hold the job) and (2) the IPP object supports the "job-hold-\r
+ until" operation attribute and there are no other reasons to\r
+ hold the job, the IPP object MUST accept the operation and make\r
+ the job be a candidate for processing immediately (see Section\r
+ 4.2.2).\r
+\r
+ If the client does not supply a "job-hold-until" Operation\r
+ attribute in the request, the IPP object MUST populate the job\r
+ object with a "job-hold-until" attribute with the 'indefinite'\r
+ value (if IPP object supports the "job-hold-until" attribute)\r
+ and hold the job indefinitely, until a client performs a\r
+ Release-Job operation.\r
+\r
+3.3.5.2 Hold-Job Response\r
+\r
+ The groups and attributes are the same as for a Cancel-Job response\r
+ (see section 3.3.3.2).\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 73]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.3.6 Release-Job Operation\r
+\r
+ This OPTIONAL operation allows a client to release a previously held\r
+ job so that it is again eligible for scheduling. If the Hold-Job\r
+ operation is supported, then the Release-Job operation MUST be\r
+ supported, and vice-versa.\r
+\r
+ This operation removes the "job-hold-until" job attribute, if\r
+ present, from the job object that had been supplied in the create or\r
+ most recent Hold-Job or Restart-Job operation and removes its effect\r
+ on the job. The IPP object MUST remove the 'job-hold-until-\r
+ specified' value from the job's "job-state-reasons" attribute, if\r
+ present. See section 4.3.8.\r
+\r
+ The IPP object MUST accept or reject the request based on the job's\r
+ current state and transition the job to the indicated new state as\r
+ follows:\r
+\r
+ Current "job- New "job-state" IPP object's response status\r
+ state" code and action:\r
+\r
+ 'pending' 'pending' 'successful-ok'\r
+ No effect on the job.\r
+ 'pending-held' 'pending-held' 'successful-ok' See Rule 1\r
+ 'pending-held' 'pending' 'successful-ok'\r
+ 'processing' 'processing' 'successful-ok'\r
+ No effect on the job.\r
+ 'processing- 'processing- 'successful-ok'\r
+ stopped' stopped' No effect on the job.\r
+ 'completed' 'completed' 'client-error-not-possible'\r
+ 'canceled' 'canceled' 'client-error-not-possible'\r
+ 'aborted' 'aborted' 'client-error-not-possible'\r
+\r
+ Rule 1: If there are other reasons to keep the job in the 'pending-\r
+ held' state, such as 'resources-are-not-ready', the job remains in\r
+ the 'pending-held' state. Thus the 'pending-held' state is not just\r
+ for jobs that have the 'job-hold-until' applied to them, but are for\r
+ any reason to keep the job from being a candidate for scheduling and\r
+ processing, such as 'resources-are-not-ready'. See the "job-hold-\r
+ until" attribute (section 4.2.2).\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must either be the job owner or an operator or\r
+ administrator of the Printer object (see Sections 1 and 8.5).\r
+ Otherwise, the IPP object MUST reject the operation and return:\r
+ 'client-error-forbidden', 'client-error-not-authenticated', or\r
+ 'client-error-not-authorized' as appropriate.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 74]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The Release-Job Request and Release-Job Response have the same\r
+ attribute groups and attributes as the Cancel-Job operation (see\r
+ section 3.3.3.1 and 3.3.3.2).\r
+\r
+3.3.7 Restart-Job Operation\r
+\r
+ This OPTIONAL operation allows a client to restart a job that is\r
+ retained in the queue after processing has completed (see section\r
+ 4.3.7.2).\r
+\r
+ The job is moved to the 'pending' or 'pending-held' job state and\r
+ restarts at the beginning on the same IPP Printer object with the\r
+ same attribute values. If any of the documents in the job were\r
+ passed by reference (Print-URI or Send-URI), the Printer MUST re-\r
+ fetch the data, since the semantics of Restart-Job are to repeat all\r
+ Job processing. The Job Description attributes that accumulate job\r
+ progress, such as "job-impressions-completed", "job-media-sheets-\r
+ completed", and "job-k-octets-processed", MUST be reset to 0 so that\r
+ they give an accurate record of the job from its restart point. The\r
+ job object MUST continue to use the same "job-uri" and "job-id"\r
+ attribute values.\r
+\r
+ Note: If in the future an operation is needed that does not reset\r
+ the job progress attributes, then a new operation will be defined\r
+ which makes a copy of the job, assigns a new "job-uri" and "job-id"\r
+ to the copy and resets the job progress attributes in the new copy\r
+ only.\r
+\r
+ The IPP object MUST accept or reject the request based on the job's\r
+ current state, transition the job to the indicated new state as\r
+ follows:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 75]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Current "job- New "job-state" IPP object's response status\r
+ state" code and action:\r
+\r
+ 'pending' 'pending' 'client-error-not-possible'\r
+ 'pending-held' 'pending-held' 'client-error-not-possible'\r
+ 'processing' 'processing' 'client-error-not-possible'\r
+ 'processing- 'processing- 'client-error-not-possible'\r
+ stopped' stopped'\r
+ 'completed' 'pending' or 'successful-ok' - job is started\r
+ 'pending-held' over.\r
+ 'completed' 'completed' 'client-error-not-possible' -\r
+ see Rule 1\r
+ 'canceled' 'pending' or 'successful-ok' - job is started\r
+ 'pending-held' over.\r
+ 'canceled' 'canceled' 'client-error-not-possible' -\r
+ see Rule 1\r
+ 'aborted' 'pending' or 'successful-ok' - job is started\r
+ 'pending-held' over.\r
+ 'aborted' 'aborted' 'client-error-not-possible' -\r
+ see Rule 1\r
+\r
+ Rule 1: If the Job Retention Period has expired for the job in this\r
+ state, then the IPP object rejects the operation. See section\r
+ 4.3.7.2.\r
+\r
+ Note: In order to prevent a user from inadvertently restarting a job\r
+ in the middle, the Restart-Job request is rejected when the job is in\r
+ the 'processing' or 'processing-stopped' states. If in the future an\r
+ operation is needed to hold or restart jobs while in these states, it\r
+ will be added as an additional operation, rather than overloading the\r
+ Restart-Job operation, so that it is clear that the user intended\r
+ that the current job not be completed.\r
+\r
+ Access Rights: The authenticated user (see section 8.3) performing\r
+ this operation must either be the job owner or an operator or\r
+ administrator of the Printer object (see Sections 1 and 8.5).\r
+ Otherwise, the IPP object MUST reject the operation and return:\r
+ 'client-error-forbidden', 'client-error-not-authenticated', or\r
+ 'client-error-not-authorized' as appropriate.\r
+\r
+3.3.7.1 Restart-Job Request\r
+\r
+ The groups and attributes are the same as for a Cancel-Job request\r
+ (see section 3.3.3.1), with the addition of the following Group 1\r
+ Operation attribute:\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 76]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ "job-hold-until" (type3 keyword | name(MAX)):\r
+ The client OPTIONALLY supplies this attribute. The IPP object\r
+ MUST support this Operation attribute in a Restart-Job request,\r
+ if it supports the "job-hold-until" Job Template attribute in\r
+ create operations. See section 4.2.2. Otherwise, the IPP\r
+ object NEED NOT support the "job-hold-until" Operation\r
+ attribute in a Restart-Job request.\r
+\r
+ If supplied and supported as specified in the Printer's "job-\r
+ hold-until-supported" attribute, the IPP object copies the\r
+ supplied Operation attribute to the Job object, replacing the\r
+ job's previous "job-hold-until" attribute, if present, and\r
+ makes the job a candidate for scheduling during the supplied\r
+ named time period. See section 4.2.2.\r
+\r
+ If supplied, but the value is not supported, the IPP object\r
+ accepts the request, returns the unsupported attribute or value\r
+ in the Unsupported Attributes Group according to section 3.1.7,\r
+ returns the 'successful-ok-ignored-or-substituted-attributes'\r
+ status code, and holds the job indefinitely until a client\r
+ performs a subsequent Release-Job operation.\r
+\r
+ If supplied, but the "job-hold-until" Operation attribute\r
+ itself is not supported, the IPP object accepts the request,\r
+ returns the unsupported attribute with the out-of-band\r
+ 'unsupported' value in the Unsupported Attributes Group\r
+ according to section 3.1.7, returns the 'successful-ok-\r
+ ignored-or-substituted-attributes' status code, and restarts\r
+ the job, i.e., ignores the "job-hold-until" attribute.\r
+\r
+ If the client (1) supplies a value that specifies a time period\r
+ that has already started or the 'no-hold' value (meaning don't\r
+ hold the job) and (2) the IPP object supports the "job-hold-\r
+ until" operation attribute and there are no other reasons to\r
+ hold the job, the IPP object makes the job a candidate for\r
+ processing immediately (see Section 4.2.2).\r
+\r
+ If the client does not supply a "job-hold-until" operation\r
+ attribute in the request, the IPP object removes the "job-\r
+ hold-until" attribute, if present, from the job. If there are\r
+ no other reasons to hold the job, the Restart-Job operation\r
+ makes the job a candidate for processing immediately (see\r
+ Section 4.2.2).\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 77]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+3.3.7.2 Restart-Job Response\r
+\r
+ The groups and attributes are the same as for a Cancel-Job response\r
+ (see section 3.3.3.2).\r
+\r
+ Note: In the future an OPTIONAL Modify-Job or Set-Job-Attributes\r
+ operation may be specified that allows the client to modify other\r
+ attributes before releasing the restarted job.\r
+\r
+4. Object Attributes\r
+\r
+ This section describes the attributes with their corresponding\r
+ attribute syntaxes and values that are part of the IPP model. The\r
+ sections below show the objects and their associated attributes which\r
+ are included within the scope of this protocol. Many of these\r
+ attributes are derived from other relevant documents:\r
+\r
+ - Document Printing Application (DPA) [ISO10175]\r
+ - RFC 1759 Printer MIB [RFC1759]\r
+\r
+ Each attribute is uniquely identified in this document using a\r
+ "keyword" (see section 12.2.1) which is the name of the attribute.\r
+ The keyword is included in the section header describing that\r
+ attribute.\r
+\r
+ Note: Not only are keywords used to identify attributes, but one of\r
+ the attribute syntaxes described below is "keyword" so that some\r
+ attributes have keyword values. Therefore, these attributes are\r
+ defined as having an attribute syntax that is a set of keywords.\r
+\r
+4.1 Attribute Syntaxes\r
+\r
+ This section defines the basic attribute syntax types that all\r
+ clients and IPP objects MUST be able to accept in responses and\r
+ accept in requests, respectively. Each attribute description in\r
+ sections 3 and 4 includes the name of attribute syntax(es) in the\r
+ heading (in parentheses). A conforming implementation of an\r
+ attribute MUST include the semantics of the attribute syntax(es) so\r
+ identified. Section 6.3 describes how the protocol can be extended\r
+ with new attribute syntaxes.\r
+\r
+ The attribute syntaxes are specified in the following sub-sections,\r
+ where the sub-section heading is the keyword name of the attribute\r
+ syntax inside the single quotes. In operation requests and responses\r
+ each attribute value MUST be represented as one of the attribute\r
+ syntaxes specified in the sub-section heading for the attribute. In\r
+ addition, the value of an attribute in a response (but not in a\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 78]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ request) MAY be one of the "out-of-band" values whose special\r
+ encoding rules are defined in the "Encoding and Transport" document\r
+ [RFC2910]. Standard "out-of-band" values are:\r
+\r
+ 'unknown': The attribute is supported by the IPP object, but the\r
+ value is unknown to the IPP object for some reason.\r
+ 'unsupported': The attribute is unsupported by the IPP object.\r
+ This value MUST be returned only as the value of an attribute\r
+ in the Unsupported Attributes Group.\r
+ 'no-value': The attribute is supported by the Printer object, but\r
+ the administrator has not yet configured a value.\r
+\r
+ All attributes in a request MUST have one or more values as defined\r
+ in Sections 4.2 to 4.4. Thus clients MUST NOT supply attributes with\r
+ "out-of-band" values for operations defined in this document. All\r
+ attributes in a response MUST have one or more values as defined in\r
+ Sections 4.2 to 4.4 or a single "out-of-band" value.\r
+\r
+ Most attributes are defined to have a single attribute syntax.\r
+ However, a few attributes (e.g., "job-sheet", "media", "job-hold-\r
+ until") are defined to have several attribute syntaxes, depending on\r
+ the value. These multiple attribute syntaxes are separated by the\r
+ "|" character in the sub-section heading to indicate the choice.\r
+ Since each value MUST be tagged as to its attribute syntax in the\r
+ protocol, a single-valued attribute instance may have any one of its\r
+ attribute syntaxes and a multi-valued attribute instance may have a\r
+ mixture of its defined attribute syntaxes.\r
+\r
+4.1.1 'text'\r
+\r
+ A text attribute is an attribute whose value is a sequence of zero or\r
+ more characters encoded in a maximum of 1023 ('MAX') octets. MAX is\r
+ the maximum length for each value of any text attribute. However, if\r
+ an attribute will always contain values whose maximum length is much\r
+ less than MAX, the definition of that attribute will include a\r
+ qualifier that defines the maximum length for values of that\r
+ attribute. For example: the "printer-location" attribute is\r
+ specified as "printer-location (text(127))". In this case, text\r
+ values for "printer-location" MUST NOT exceed 127 octets; if supplied\r
+ with a longer text string via some external interface (other than the\r
+ protocol), implementations are free to truncate to this shorter\r
+ length limitation.\r
+\r
+ In this document, all text attributes are defined using the 'text'\r
+ syntax. However, 'text' is used only for brevity; the formal\r
+ interpretation of 'text' is: 'textWithoutLanguage |\r
+ textWithLanguage'. That is, for any attribute defined in this\r
+ document using the 'text' attribute syntax, all IPP objects and\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 79]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ clients MUST support both the 'textWithoutLanguage' and\r
+ 'textWithLanguage' attribute syntaxes. However, in actual usage and\r
+ protocol execution, objects and clients accept and return only one of\r
+ the two syntax per attribute. The syntax 'text' never appears "on-\r
+ the-wire".\r
+\r
+ Both 'textWithoutLanguage' and 'textWithLanguage' are needed to\r
+ support the real world needs of interoperability between sites and\r
+ systems that use different natural languages as the basis for human\r
+ communication. Generally, one natural language applies to all text\r
+ attributes in a given request or response. The language is indicated\r
+ by the "attributes-natural-language" operation attribute defined in\r
+ section 3.1.4 or "attributes-natural-language" job attribute defined\r
+ in section 4.3.20, and there is no need to identify the natural\r
+ language for each text string on a value-by-value basis. In these\r
+ cases, the attribute syntax 'textWithoutLanguage' is used for text\r
+ attributes. In other cases, the client needs to supply or the\r
+ Printer object needs to return a text value in a natural language\r
+ that is different from the rest of the text values in the request or\r
+ response. In these cases, the client or Printer object uses the\r
+ attribute syntax 'textWithLanguage' for text attributes (this is the\r
+ Natural Language Override mechanism described in section 3.1.4).\r
+\r
+ The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes\r
+ are described in more detail in the following sections.\r
+\r
+4.1.1.1 'textWithoutLanguage'\r
+\r
+ The 'textWithoutLanguage' syntax indicates a value that is sequence\r
+ of zero or more characters encoded in a maximum of 1023 (MAX) octets.\r
+ Text strings are encoded using the rules of some charset. The\r
+ Printer object MUST support the UTF-8 charset [RFC2279] and MAY\r
+ support additional charsets to represent 'text' values, provided that\r
+ the charsets are registered with IANA [IANA-CS]. See Section 4.1.7\r
+ for the definition of the 'charset' attribute syntax, including\r
+ restricted semantics and examples of charsets.\r
+\r
+4.1.1.2 'textWithLanguage'\r
+\r
+ The 'textWithLanguage' attribute syntax is a compound attribute\r
+ syntax consisting of two parts: a 'textWithoutLanguage' part encoded\r
+ in a maximum of 1023 (MAX) octets plus an additional\r
+ 'naturalLanguage' (see section 4.1.8) part that overrides the natural\r
+ language in force. The 'naturalLanguage' part explicitly identifies\r
+ the natural language that applies to the text part of that value and\r
+ that value alone. For any give text attribute, the\r
+ 'textWithoutLanguage' part is limited to the maximum length defined\r
+ for that 'text' attribute, and the 'naturalLanguage' part is always\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 80]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ limited to 63 (additional) octets. Using the 'textWithLanguage'\r
+ attribute syntax rather than the normal 'textWithoutLanguage' syntax\r
+ is the so-called Natural Language Override mechanism and MUST be\r
+ supported by all IPP objects and clients.\r
+\r
+ If the attribute is multi-valued (1setOf text), then the\r
+ 'textWithLanguage' attribute syntax MUST be used to explicitly\r
+ specify each attribute value whose natural language needs to be\r
+ overridden. Other values in a multi-valued 'text' attribute in a\r
+ request or a response revert to the natural language of the operation\r
+ attribute.\r
+\r
+ In a create request, the Printer object MUST accept and store with\r
+ the Job object any natural language in the "attributes-natural-\r
+ language" operation attribute, whether the Printer object supports\r
+ that natural language or not. Furthermore, the Printer object MUST\r
+ accept and store any 'textWithLanguage' attribute value, whether the\r
+ Printer object supports that natural language or not. These\r
+ requirements are independent of the value of the "ipp-attribute-\r
+ fidelity" operation attribute that the client MAY supply.\r
+\r
+ Example: If the client supplies the "attributes-natural-language"\r
+ operation attribute with the value: 'en' indicating English, but the\r
+ value of the "job-name" attribute is in French, the client MUST use\r
+ the 'textWithLanguage' attribute syntax with the following two\r
+ values:\r
+\r
+ 'fr': Natural Language Override indicating French\r
+ 'Rapport Mensuel': the job name in French\r
+\r
+ See the "Encoding and Transport" document [RFC2910] section 3.9 for\r
+ the encoding of the two parts and Appendix A for a detailed example\r
+ of the 'textWithLanguage' attribute syntax.\r
+\r
+4.1.2 'name'\r
+\r
+ This syntax type is used for user-friendly strings, such as a Printer\r
+ name, that, for humans, are more meaningful than identifiers. Names\r
+ are never translated from one natural language to another. The\r
+ 'name' attribute syntax is essentially the same as 'text', including\r
+ the REQUIRED support of UTF-8 except that the sequence of characters\r
+ is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.\r
+\r
+ Also like 'text', 'name' is really an abbreviated notation for either\r
+ 'nameWithoutLanguage' or 'nameWithLanguage'. That is, all IPP\r
+ objects and clients MUST support both the 'nameWithoutLanguage' and\r
+ 'nameWithLanguage' attribute syntaxes. However, in actual usage and\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 81]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ protocol execution, objects and clients accept and return only one of\r
+ the two syntax per attribute. The syntax 'name' never appears "on-\r
+ the-wire".\r
+\r
+ Only the 'text' and 'name' attribute syntaxes permit the Natural\r
+ Language Override mechanism.\r
+\r
+ Some attributes are defined as 'type3 keyword | name'. These\r
+ attributes support values that are either type3 keywords or names.\r
+ This dual-syntax mechanism enables a site administrator to extend\r
+ these attributes to legally include values that are locally defined\r
+ by the site administrator. Such names are not registered with IANA.\r
+\r
+4.1.2.1 'nameWithoutLanguage'\r
+\r
+ The 'nameWithoutLanguage' syntax indicates a value that is sequence\r
+ of zero or more characters encoded in a maximum of 255 (MAX) octets.\r
+\r
+4.1.2.2 'nameWithLanguage'\r
+\r
+ The 'nameWithLanguage' attribute syntax is a compound attribute\r
+ syntax consisting of two parts: a 'nameWithoutLanguage' part encoded\r
+ in a maximum of 1023 (MAX) octets plus an additional\r
+ 'naturalLanguage' (see section 4.1.8) part that overrides the natural\r
+ language in force. The 'naturalLanguage' part explicitly identifies\r
+ the natural language that applies to that name value and that name\r
+ value alone. For any give text attribute, the 'textWithoutLanguage'\r
+ part is limited to the maximum length defined for that 'text'\r
+ attribute, and the 'naturalLanguage' part is always limited to 63\r
+ (additional) octets. Using the 'textWithLanguage' attribute syntax\r
+ rather than the normal 'textWithoutLanguage' syntax is the so-called\r
+ Natural Language Override mechanism and MUST be supported by all IPP\r
+ objects and clients.\r
+\r
+ The 'nameWithLanguage' attribute syntax behaves the same as the\r
+ 'textWithLanguage' syntax. Using the 'textWithLanguage' attribute\r
+ syntax rather than the normal 'textWithoutLanguage' syntax is the\r
+ so-called Natural Language Override mechanism and MUST be supported\r
+ by all IPP objects and clients. If a name is in a language that is\r
+ different than the rest of the object or operation, then this\r
+ 'nameWithLanguage' syntax is used rather than the generic\r
+ 'nameWithoutLanguage' syntax.\r
+\r
+ If the attribute is multi-valued (1setOf text), then the\r
+ 'nameWithLanguage' attribute syntax MUST be used to explicitly\r
+ specify each attribute value whose natural language needs to be\r
+ overridden.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 82]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Other values in a multi-valued 'name' attribute in a request or a\r
+ response revert to the natural language of the operation attribute.\r
+\r
+ In a create request, the Printer object MUST accept and store with\r
+ the Job object any natural language in the "attributes-natural-\r
+ language" operation attribute, whether the Printer object supports\r
+ that natural language or not. Furthermore, the Printer object MUST\r
+ accept and store any 'nameWithLanguage' attribute value, whether the\r
+ Printer object supports that natural language or not. These\r
+ requirements are independent of the value of the "ipp-attribute-\r
+ fidelity" operation attribute that the client MAY supply.\r
+\r
+ Example: If the client supplies the "attributes-natural-language"\r
+ operation attribute with the value: 'en' indicating English, but the\r
+ "printer-name" attribute is in German, the client MUST use the\r
+ 'nameWithLanguage' attribute syntax as follows:\r
+\r
+ 'de': Natural Language Override indicating German\r
+ 'Farbdrucker': the Printer name in German\r
+\r
+ See the "Encoding and Transport" document [RFC2910] section 3.9 for\r
+ the encoding of the two parts and Appendix A for a detailed example\r
+ of the 'nameWithLanguage' attribute syntax.\r
+\r
+4.1.2.3 Matching 'name' attribute values\r
+\r
+ For purposes of matching two 'name' attribute values for equality,\r
+ such as in job validation (where a client-supplied value for\r
+ attribute "xxx" is checked to see if the value is among the values of\r
+ the Printer object's corresponding "xxx-supported" attribute), the\r
+ following match rules apply:\r
+\r
+ 1. 'keyword' values never match 'name' values.\r
+\r
+ 2. 'name' (nameWithoutLanguage and nameWithLanguage) values match\r
+ if (1) the name parts match and (2) the Associated Natural-\r
+ Language parts (see section 3.1.4.1) match. The matching rules\r
+ are:\r
+\r
+ a. the name parts match if the two names are identical\r
+ character by character, except it is RECOMMENDED that case\r
+ be ignored. For example: 'Ajax-letter-head-white' MUST\r
+ match 'Ajax-letter-head-white' and SHOULD match 'ajax-\r
+ letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 83]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ b. the Associated Natural-Language parts match if the shorter\r
+ of the two meets the syntactic requirements of RFC 1766\r
+ [RFC1766] and matches byte for byte with the longer. For\r
+ example, 'en' matches 'en', 'en-us' and 'en-gb', but matches\r
+ neither 'fr' nor 'e'.\r
+\r
+4.1.3 'keyword'\r
+\r
+ The 'keyword' attribute syntax is a sequence of characters, length: 1\r
+ to 255, containing only the US-ASCII [ASCII] encoded values for\r
+ lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot\r
+ ("."), and underscore ("_"). The first character MUST be a lowercase\r
+ letter. Furthermore, keywords MUST be in U.S. English.\r
+\r
+ This syntax type is used for enumerating semantic identifiers of\r
+ entities in the abstract protocol, i.e., entities identified in this\r
+ document. Keywords are used as attribute names or values of\r
+ attributes. Unlike 'text' and 'name' attribute values, 'keyword'\r
+ values MUST NOT use the Natural Language Override mechanism, since\r
+ they MUST always be US-ASCII and U.S. English.\r
+\r
+ Keywords are for use in the protocol. A user interface will likely\r
+ provide a mapping between protocol keywords and displayable user-\r
+ friendly words and phrases which are localized to the natural\r
+ language of the user. While the keywords specified in this document\r
+ MAY be displayed to users whose natural language is U.S. English,\r
+ they MAY be mapped to other U.S. English words for U.S. English\r
+ users, since the user interface is outside the scope of this\r
+ document.\r
+\r
+ In the definition for each attribute of this syntax type, the full\r
+ set of defined keyword values for that attribute are listed.\r
+\r
+ When a keyword is used to represent an attribute (its name), it MUST\r
+ be unique within the full scope of all IPP objects and attributes.\r
+ When a keyword is used to represent a value of an attribute, it MUST\r
+ be unique just within the scope of that attribute. That is, the same\r
+ keyword MUST NOT be used for two different values within the same\r
+ attribute to mean two different semantic ideas. However, the same\r
+ keyword MAY be used across two or more attributes, representing\r
+ different semantic ideas for each attribute. Section 6.1 describes\r
+ how the protocol can be extended with new keyword values. Examples\r
+ of attribute name keywords:\r
+\r
+ "job-name"\r
+ "attributes-charset"\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 84]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Note: This document uses "type1", "type2", and "type3" prefixes to\r
+ the "keyword" basic syntax to indicate different levels of review for\r
+ extensions (see section 6.1).\r
+\r
+4.1.4 'enum'\r
+\r
+ The 'enum' attribute syntax is an enumerated integer value that is in\r
+ the range from 1 to 2**31 - 1 (MAX). Each value has an associated\r
+ 'keyword' name. In the definition for each attribute of this syntax\r
+ type, the full set of possible values for that attribute are listed.\r
+ This syntax type is used for attributes for which there are enum\r
+ values assigned by other standards, such as SNMP MIBs. A number of\r
+ attribute enum values in this document are also used for\r
+ corresponding attributes in other standards [RFC1759]. This syntax\r
+ type is not used for attributes to which the administrator may assign\r
+ values. Section 6.1 describes how the protocol can be extended with\r
+ new enum values.\r
+\r
+ Enum values are for use in the protocol. A user interface will\r
+ provide a mapping between protocol enum values and displayable user-\r
+ friendly words and phrases which are localized to the natural\r
+ language of the user. While the enum symbols specified in this\r
+ document MAY be displayed to users whose natural language is U.S.\r
+ English, they MAY be mapped to other U.S. English words for U.S.\r
+ English users, since the user interface is outside the scope of this\r
+ document.\r
+\r
+ Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP\r
+ "out-of-band" value 'unknown'. See the description of the "out-of-\r
+ band" values at the beginning of Section 4.1. Therefore, attributes\r
+ of type 'enum' start at '3'.\r
+\r
+ Note: This document uses "type1", "type2", and "type3" prefixes to\r
+ the "enum" basic syntax to indicate different levels of review for\r
+ extensions (see section 6.1).\r
+\r
+4.1.5 'uri'\r
+\r
+ The 'uri' attribute syntax is any valid Uniform Resource Identifier\r
+ or URI [RFC2396]. Most often, URIs are simply Uniform Resource\r
+ Locators or URLs. The maximum length of URIs used as values of IPP\r
+ attributes is 1023 octets. Although most other IPP attribute syntax\r
+ types allow for only lower-cased values, this attribute syntax type\r
+ conforms to the case-sensitive and case-insensitive rules specified\r
+ in [RFC2396]. See also [IPP-IIG] for a discussion of case in URIs.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 85]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.1.6 'uriScheme'\r
+\r
+ The 'uriScheme' attribute syntax is a sequence of characters\r
+ representing a URI scheme according to RFC 2396 [RFC2396]. Though\r
+ RFC 2396 requires that the values be case-insensitive, IPP requires\r
+ all lower case values in IPP attributes to simplify comparing by IPP\r
+ clients and Printer objects.\r
+\r
+ Standard values for this syntax type are the following keywords:\r
+\r
+ 'ipp': for IPP schemed URIs (e.g., "ipp:...")\r
+ 'http': for HTTP schemed URIs (e.g., "http:...")\r
+ 'https': for use with HTTPS schemed URIs (e.g., "https:...") (not\r
+ on IETF standards track)\r
+ 'ftp': for FTP schemed URIs (e.g., "ftp:...")\r
+ 'mailto': for SMTP schemed URIs (e.g., "mailto:...")\r
+ 'file': for file schemed URIs (e.g., "file:...")\r
+\r
+ A Printer object MAY support any URI 'scheme' that has been\r
+ registered with IANA [IANA-MT]. The maximum length of URI 'scheme'\r
+ values used to represent IPP attribute values is 63 octets.\r
+\r
+4.1.7 'charset'\r
+\r
+ The 'charset' attribute syntax is a standard identifier for a\r
+ charset. A charset is a coded character set and encoding scheme.\r
+ Charsets are used for labeling certain document contents and 'text'\r
+ and 'name' attribute values. The syntax and semantics of this\r
+ attribute syntax are specified in RFC 2046 [RFC2046] and contained in\r
+ the IANA character-set Registry [IANA-CS] according to the IANA\r
+ procedures [RFC2278]. Though RFC 2046 requires that the values be\r
+ case-insensitive US-ASCII [ASCII], IPP requires all lower case values\r
+ in IPP attributes to simplify comparing by IPP clients and Printer\r
+ objects. When a character-set in the IANA registry has more than one\r
+ name (alias), the name labeled as "(preferred MIME name)", if\r
+ present, MUST be used.\r
+\r
+ The maximum length of 'charset' values used to represent IPP\r
+ attribute values is 63 octets.\r
+\r
+ Some examples are:\r
+\r
+ 'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set\r
+ (UCS) represented as the UTF-8 [RFC2279] transfer encoding\r
+ scheme in which US-ASCII is a subset charset.\r
+ 'us-ascii': 7-bit American Standard Code for Information\r
+ Interchange (ASCII), ANSI X3.4-1986 [ASCII]. That standard\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 86]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the\r
+ control characters from conformant usage in MIME and IPP.\r
+ 'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet\r
+ Nr 1 [ISO8859-1]. That standard defines a coded character set\r
+ that is used by Latin languages in the Western Hemisphere and\r
+ Western Europe. US-ASCII is a subset charset.\r
+\r
+ Some attribute descriptions MAY place additional requirements on\r
+ charset values that may be used, such as REQUIRED values that MUST be\r
+ supported or additional restrictions, such as requiring that the\r
+ charset have US- ASCII as a subset charset.\r
+\r
+4.1.8 'naturalLanguage'\r
+\r
+ The 'naturalLanguage' attribute syntax is a standard identifier for a\r
+ natural language and optionally a country. The values for this\r
+ syntax type are defined by RFC 1766 [RFC1766]. Though RFC 1766\r
+ requires that the values be case-insensitive US-ASCII [ASCII], IPP\r
+ requires all lower case to simplify comparing by IPP clients and\r
+ Printer objects. Examples include:\r
+\r
+ 'en': for English\r
+ 'en-us': for US English\r
+ 'fr': for French\r
+ 'de': for German\r
+\r
+ The maximum length of 'naturalLanguage' values used to represent IPP\r
+ attribute values is 63 octets.\r
+\r
+4.1.9 'mimeMediaType'\r
+\r
+ The 'mimeMediaType' attribute syntax is the Internet Media Type\r
+ (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and\r
+ registered according to the procedures of RFC 2048 [RFC2048] for\r
+ identifying a document format. The value MAY include a charset, or\r
+ other, parameter, depending on the specification of the Media Type in\r
+ the IANA Registry [IANA-MT]. Although most other IPP syntax types\r
+ allow for only lower-cased values, this syntax type allows for\r
+ mixed-case values which are case-insensitive.\r
+\r
+ Examples are:\r
+ 'text/html': An HTML document\r
+ 'text/plain': A plain text document in US-ASCII (RFC 2046\r
+ indicates that in the absence of the charset parameter MUST\r
+ mean US-ASCII rather than simply unspecified) [RFC2046].\r
+ 'text/plain; charset=US-ASCII': A plain text document in US-ASCII\r
+ [52, 56].\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 87]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'text/plain; charset=ISO-8859-1': A plain text document in ISO\r
+ 8859-1 (Latin 1) [ISO8859-1].\r
+ 'text/plain; charset=utf-8': A plain text document in ISO 10646\r
+ represented as UTF-8 [RFC2279]\r
+ 'application/postscript': A PostScript document [RFC2046]\r
+ 'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset\r
+ escape sequence embedded in the document data)\r
+ 'application/pdf': Portable Document Format - see IANA MIME Media\r
+ Type registry\r
+ 'application/octet-stream': Auto-sense - see section 4.1.9.1\r
+\r
+ The maximum length of a 'mimeMediaType' value to represent IPP\r
+ attribute values is 255 octets.\r
+\r
+4.1.9.1 Application/octet-stream -- Auto-Sensing the document format\r
+\r
+ One special type is 'application/octet-stream'. If the Printer\r
+ object supports this value, the Printer object MUST be capable of\r
+ auto-sensing the format of the document data using an\r
+ implementation-dependent method that examines some number of octets\r
+ of the document data, either as part of the create operation and/or\r
+ at document processing time. During auto-sensing, a Printer may\r
+ determine that the document-data has a format that the Printer\r
+ doesn't recognize. If the Printer determines this problem before\r
+ returning an operation response, it rejects the request and returns\r
+ the 'client-error-document-format-not-supported' status code. If the\r
+ Printer determines this problem after accepting the request and\r
+ returning an operation response with one of the successful status\r
+ codes, the Printer adds the 'unsupported-document-format' value to\r
+ the job's "job-state-reasons" attribute.\r
+\r
+ If the Printer object's default value attribute "document-format-\r
+ default" is set to 'application/octet-stream', the Printer object not\r
+ only supports auto-sensing of the document format, but will depend on\r
+ the result of applying its auto-sensing when the client does not\r
+ supply the "document-format" attribute. If the client supplies a\r
+ document format value, the Printer MUST rely on the supplied\r
+ attribute, rather than trust its auto-sensing algorithm. To\r
+ summarize:\r
+\r
+ 1. If the client does not supply a document format value, the\r
+ Printer MUST rely on its default value setting (which may be\r
+ 'application/octet-stream' indicating an auto-sensing\r
+ mechanism).\r
+ 2. If the client supplies a value other than 'application/octet-\r
+ stream', the client is supplying valid information about the\r
+ format of the document data and the Printer object MUST trust\r
+ the client supplied value more than the outcome of applying an\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 88]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ automatic format detection mechanism. For example, the client\r
+ may be requesting the printing of a PostScript file as a\r
+ 'text/plain' document. The Printer object MUST print a text\r
+ representation of the PostScript commands rather than interpret\r
+ the stream of PostScript commands and print the result.\r
+ 3. If the client supplies a value of 'application/octet-stream',\r
+ the client is indicating that the Printer object MUST use its\r
+ auto-sensing mechanism on the client supplied document data\r
+ whether auto-sensing is the Printer object's default or not.\r
+\r
+ Note: Since the auto-sensing algorithm is probabilistic, if the\r
+ client requests both auto-sensing ("document-format" set to\r
+ 'application/octet-stream') and true fidelity ("ipp-attribute-\r
+ fidelity" set to 'true'), the Printer object might not be able to\r
+ guarantee exactly what the end user intended (the auto-sensing\r
+ algorithm might mistake one document format for another), but it is\r
+ able to guarantee that its auto-sensing mechanism be used.\r
+\r
+ When a Printer performs auto-sensing of a document in a submitted\r
+ job, it is RECOMMENDED that the Printer indicate to the user that\r
+ such auto-sensing has occurred and which document-format was auto-\r
+ sensed by printing that information on the job's job-start-sheet.\r
+\r
+4.1.10 'octetString'\r
+\r
+ The 'octetString' attribute syntax is a sequence of octets encoded in\r
+ a maximum of 1023 octets which is indicated in sub-section headers\r
+ using the notation: octetString(MAX). This syntax type is used for\r
+ opaque data.\r
+\r
+4.1.11 'boolean'\r
+\r
+ The 'boolean' attribute syntax has only two values: 'true' and\r
+ 'false'.\r
+\r
+4.1.12 'integer'\r
+\r
+ The 'integer' attribute syntax is an integer value that is in the\r
+ range from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual\r
+ attribute may specify the range constraint explicitly in sub-section\r
+ headers if the range is different from the full range of possible\r
+ integer values. For example: job-priority (integer(1:100)) for the\r
+ "job-priority" attribute. However, the enforcement of that\r
+ additional constraint is up to the IPP objects, not the protocol.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 89]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.1.13 'rangeOfInteger'\r
+\r
+ The 'rangeOfInteger' attribute syntax is an ordered pair of integers\r
+ that defines an inclusive range of integer values. The first integer\r
+ specifies the lower bound and the second specifies the upper bound.\r
+ If a range constraint is specified in the header description for an\r
+ attribute in this document whose attribute syntax is 'rangeOfInteger'\r
+ (i.e., 'X:Y' indicating X as a minimum value and Y as a maximum\r
+ value), then the constraint applies to both integers.\r
+\r
+4.1.14 'dateTime'\r
+\r
+ The 'dateTime' attribute syntax is a standard, fixed length, 11 octet\r
+ representation of the "DateAndTime" syntax as defined in RFC 2579\r
+ [RFC2579]. RFC 2579 also identifies an 8 octet representation of a\r
+ "DateAndTime" value, but IPP objects MUST use the 11 octet\r
+ representation. A user interface will provide a mapping between\r
+ protocol dateTime values and displayable user-friendly words or\r
+ presentation values and phrases which are localized to the natural\r
+ language and date format of the user, including time zone.\r
+\r
+4.1.15 'resolution'\r
+\r
+ The 'resolution' attribute syntax specifies a two-dimensional\r
+ resolution in the indicated units. It consists of 3 values: a cross\r
+ feed direction resolution (positive integer value), a feed direction\r
+ resolution (positive integer value), and a units value. The\r
+ semantics of these three components are taken from the Printer MIB\r
+ [RFC1759] suggested values. That is, the cross feed direction\r
+ component resolution component is the same as the\r
+ prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed\r
+ direction component resolution component is the same as the\r
+ prtMarkerAddressabilityFeedDir in the Printer MIB, and the units\r
+ component is the same as the prtMarkerAddressabilityUnit object in\r
+ the Printer MIB (namely, '3' indicates dots per inch and '4'\r
+ indicates dots per centimeter). All three values MUST be present\r
+ even if the first two values are the same. Example: '300', '600',\r
+ '3' indicates a 300 dpi cross-feed direction resolution, a 600 dpi\r
+ feed direction resolution, since a '3' indicates dots per inch (dpi).\r
+\r
+4.1.16 '1setOf X'\r
+\r
+ The '1setOf X' attribute syntax is 1 or more values of attribute\r
+ syntax type X. This syntax type is used for multi-valued attributes.\r
+ The syntax type is called '1setOf' rather than just 'setOf' as a\r
+ reminder that the set of values MUST NOT be empty (i.e., a set of\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 90]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ size 0). Sets are normally unordered. However each attribute\r
+ description of this type may specify that the values MUST be in a\r
+ certain order for that attribute.\r
+\r
+4.2 Job Template Attributes\r
+\r
+ Job Template attributes describe job processing behavior. Support\r
+ for Job Template attributes by a Printer object is OPTIONAL (see\r
+ section 12.2.3 for a description of support for OPTIONAL attributes).\r
+ Also, clients OPTIONALLY supply Job Template attributes in create\r
+ requests.\r
+\r
+ Job Template attributes conform to the following rules. For each Job\r
+ Template attribute called "xxx":\r
+\r
+ 1. If the Printer object supports "xxx" then it MUST support both\r
+ a "xxx-default" attribute (unless there is a "No" in the table\r
+ below) and a "xxx-supported" attribute. If the Printer object\r
+ doesn't support "xxx", then it MUST support neither an "xxx-\r
+ default" attribute nor an "xxx-supported" attribute, and it\r
+ MUST treat an attribute "xxx" supplied by a client as\r
+ unsupported. An attribute "xxx" may be supported for some\r
+ document formats and not supported for other document formats.\r
+ For example, it is expected that a Printer object would only\r
+ support "orientation-requested" for some document formats (such\r
+ as 'text/plain' or 'text/html') but not others (such as\r
+ 'application/postscript').\r
+\r
+ 2. "xxx" is OPTIONALLY supplied by the client in a create request.\r
+ If "xxx" is supplied, the client is indicating a desired job\r
+ processing behavior for this Job. When "xxx" is not supplied,\r
+ the client is indicating that the Printer object apply its\r
+ default job processing behavior at job processing time if the\r
+ document content does not contain an embedded instruction\r
+ indicating an xxx-related behavior.\r
+\r
+ Since an administrator MAY change the default value attribute\r
+ after a Job object has been submitted but before it has been\r
+ processed, the default value used by the Printer object at job\r
+ processing time may be different that the default value in\r
+ effect at job submission time.\r
+\r
+ 3. The "xxx-supported" attribute is a Printer object attribute\r
+ that describes which job processing behaviors are supported by\r
+ that Printer object. A client can query the Printer object to\r
+ find out what xxx-related behaviors are supported by inspecting\r
+ the returned values of the "xxx-supported" attribute.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 91]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Note: The "xxx" in each "xxx-supported" attribute name is\r
+ singular, even though an "xxx-supported" attribute usually has\r
+ more than one value, such as "job-sheet-supported", unless the\r
+ "xxx" Job Template attribute is plural, such as "finishings" or\r
+ "sides". In such cases the "xxx-supported" attribute names\r
+ are: "finishings- supported" and "sides-supported".\r
+\r
+ 4. The "xxx-default" default value attribute describes what will\r
+ be done at job processing time when no other job processing\r
+ information is supplied by the client (either explicitly as an\r
+ IPP attribute in the create request or implicitly as an\r
+ embedded instruction within the document data).\r
+\r
+ If an application wishes to present an end user with a list of\r
+ supported values from which to choose, the application SHOULD query\r
+ the Printer object for its supported value attributes. The\r
+ application SHOULD also query the default value attributes. If the\r
+ application then limits selectable values to only those value that\r
+ are supported, the application can guarantee that the values supplied\r
+ by the client in the create request all fall within the set of\r
+ supported values at the Printer. When querying the Printer, the\r
+ client MAY enumerate each attribute by name in the Get-Printer-\r
+ Attributes Request, or the client MAY just name the "job-template"\r
+ group in order to get the complete set of supported attributes (both\r
+ supported and default attributes).\r
+\r
+ The "finishings" attribute is an example of a Job Template attribute.\r
+ It can take on a set of values such as 'staple', 'punch', and/or\r
+ 'cover'. A client can query the Printer object for the "finishings-\r
+ supported" attribute and the "finishings-default" attribute. The\r
+ supported attribute contains a set of supported values. The default\r
+ value attribute contains the finishing value(s) that will be used for\r
+ a new Job if the client does not supply a "finishings" attribute in\r
+ the create request and the document data does not contain any\r
+ corresponding finishing instructions. If the client does supply the\r
+ "finishings" attribute in the create request, the IPP object\r
+ validates the value or values to make sure that they are a subset of\r
+ the supported values identified in the Printer object's "finishings-\r
+ supported" attribute. See section 3.1.7.\r
+\r
+ The table below summarizes the names and relationships for all Job\r
+ Template attributes. The first column of the table (labeled "Job\r
+ Attribute") shows the name and syntax for each Job Template attribute\r
+ in the Job object. These are the attributes that can optionally be\r
+ supplied by the client in a create request. The last two columns\r
+ (labeled "Printer: Default Value Attribute" and "Printer: Supported\r
+ Values Attribute") show the name and syntax for each Job Template\r
+ attribute in the Printer object (the default value attribute and the\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 92]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ supported values attribute). A "No" in the table means the Printer\r
+ MUST NOT support the attribute (that is, the attribute is simply not\r
+ applicable). For brevity in the table, the 'text' and 'name' entries\r
+ do not show the maximum length for each attribute.\r
+\r
+ +===================+======================+======================+\r
+ | Job Attribute |Printer: Default Value| Printer: Supported |\r
+ | | Attribute | Values Attribute |\r
+ +===================+======================+======================+\r
+ | job-priority | job-priority-default |job-priority-supported|\r
+ | (integer 1:100) | (integer 1:100) |(integer 1:100) |\r
+ +-------------------+----------------------+----------------------+\r
+ | job-hold-until | job-hold-until- |job-hold-until- |\r
+ | (type3 keyword | | default | supported |\r
+ | name) | (type3 keyword | |(1setOf ( |\r
+ | | name) |type3 keyword | name))|\r
+ +-------------------+----------------------+----------------------+\r
+ | job-sheets | job-sheets-default |job-sheets-supported |\r
+ | (type3 keyword | | (type3 keyword | |(1setOf ( |\r
+ | name) | name) |type3 keyword | name))|\r
+ +-------------------+----------------------+----------------------+\r
+ |multiple-document- |multiple-document- |multiple-document- |\r
+ | handling | handling-default |handling-supported |\r
+ | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|\r
+ +-------------------+----------------------+----------------------+\r
+ | copies | copies-default | copies-supported |\r
+ | (integer (1:MAX)) | (integer (1:MAX)) | (rangeOfInteger |\r
+ | | | (1:MAX)) |\r
+ +-------------------+----------------------+----------------------+\r
+ | finishings | finishings-default | finishings-supported |\r
+ |(1setOf type2 enum)|(1setOf type2 enum) |(1setOf type2 enum) |\r
+ +-------------------+----------------------+----------------------+\r
+ | page-ranges | No | page-ranges- |\r
+ | (1setOf | | supported (boolean) |\r
+ | rangeOfInteger | | |\r
+ | (1:MAX)) | | |\r
+ +-------------------+----------------------+----------------------+\r
+ | sides | sides-default | sides-supported |\r
+ | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|\r
+ +-------------------+----------------------+----------------------+\r
+ | number-up | number-up-default | number-up-supported |\r
+ | (integer (1:MAX)) | (integer (1:MAX)) |(1setOf (integer |\r
+ | | | (1:MAX) | |\r
+ | | | rangeOfInteger |\r
+ | | | (1:MAX))) |\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 93]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ +-------------------+----------------------+----------------------+\r
+ | orientation- |orientation-requested-|orientation-requested-|\r
+ | requested | default | supported |\r
+ | (type2 enum) | (type2 enum) | (1setOf type2 enum) |\r
+ +-------------------+----------------------+----------------------+\r
+ | media | media-default | media-supported |\r
+ | (type3 keyword | | (type3 keyword | |(1setOf ( |\r
+ | name) | name) |type3 keyword | name))|\r
+ | | | |\r
+ | | | media-ready |\r
+ | | |(1setOf ( |\r
+ | | |type3 keyword | name))|\r
+ +-------------------+----------------------+----------------------+\r
+ | printer-resolution| printer-resolution- | printer-resolution- |\r
+ | (resolution) | default | supported |\r
+ | | (resolution) |(1setOf resolution) |\r
+ +-------------------+----------------------+----------------------+\r
+ | print-quality | print-quality-default| print-quality- |\r
+ | (type2 enum) | (type2 enum) | supported |\r
+ | | |(1setOf type2 enum) |\r
+ +-------------------+----------------------+----------------------+\r
+\r
+4.2.1 job-priority (integer(1:100))\r
+\r
+ This attribute specifies a priority for scheduling the Job. A higher\r
+ value specifies a higher priority. The value 1 indicates the lowest\r
+ possible priority. The value 100 indicates the highest possible\r
+ priority. Among those jobs that are ready to print, a Printer MUST\r
+ print all jobs with a priority value of n before printing those with\r
+ a priority value of n-1 for all n.\r
+\r
+ If the Printer object supports this attribute, it MUST always support\r
+ the full range from 1 to 100. No administrative restrictions are\r
+ permitted. This way an end-user can always make full use of the\r
+ entire range with any Printer object. If privileged jobs are\r
+ implemented outside IPP/1.1, they MUST have priorities higher than\r
+ 100, rather than restricting the range available to end-users.\r
+\r
+ If the client does not supply this attribute and this attribute is\r
+ supported by the Printer object, the Printer object MUST use the\r
+ value of the Printer object's "job-priority-default" at job\r
+ submission time (unlike most Job Template attributes that are used if\r
+ necessary at job processing time).\r
+\r
+ The syntax for the "job-priority-supported" is also integer(1:100).\r
+ This single integer value indicates the number of priority levels\r
+ supported. The Printer object MUST take the value supplied by the\r
+ client and map it to the closest integer in a sequence of n integers\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 94]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ values that are evenly distributed over the range from 1 to 100 using\r
+ the formula:\r
+\r
+ roundToNearestInt((100x+50)/n)\r
+\r
+ where n is the value of "job-priority-supported" and x ranges from 0\r
+ through n-1.\r
+\r
+ For example, if n=1 the sequence of values is 50; if n=2, the\r
+ sequence of values is: 25 and 75; if n = 3, the sequence of values\r
+ is: 17, 50 and 83; if n = 10, the sequence of values is: 5, 15, 25,\r
+ 35, 45, 55, 65, 75, 85, and 95; if n = 100, the sequence of values\r
+ is: 1, 2, 3, ... 100.\r
+\r
+ If the value of the Printer object's "job-priority-supported" is 10\r
+ and the client supplies values in the range 1 to 10, the Printer\r
+ object maps them to 5, in the range 11 to 20, the Printer object maps\r
+ them to 15, etc.\r
+\r
+4.2.2 job-hold-until (type3 keyword | name (MAX))\r
+\r
+ This attribute specifies the named time period during which the Job\r
+ MUST become a candidate for printing.\r
+\r
+ Standard keyword values for named time periods are:\r
+\r
+ 'no-hold': immediately, if there are not other reasons to hold the\r
+ job\r
+ 'indefinite': - the job is held indefinitely, until a client\r
+ performs a Release-Job (section 3.3.6)\r
+ 'day-time': during the day\r
+ 'evening': evening\r
+ 'night': night\r
+ 'weekend': weekend\r
+ 'second-shift': second-shift (after close of business)\r
+ 'third-shift': third-shift (after midnight)\r
+\r
+ An administrator MUST associate allowable print times with a named\r
+ time period (by means outside the scope of this IPP/1.1 document).\r
+ An administrator is encouraged to pick names that suggest the type of\r
+ time period. An administrator MAY define additional values using the\r
+ 'name' or 'keyword' attribute syntax, depending on implementation.\r
+\r
+ If the value of this attribute specifies a time period that is in the\r
+ future, the Printer SHOULD add the 'job-hold-until-specified' value\r
+ to the job's "job-state-reasons" attribute, MUST move the job to the\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 95]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'pending-held' state, and MUST NOT schedule the job for printing\r
+ until the specified time-period arrives.\r
+\r
+ When the specified time period arrives, the Printer MUST remove the\r
+ 'job-hold-until-specified' value from the job's "job-state-reason"\r
+ attribute, if present. If there are no other job state reasons that\r
+ keep the job in the 'pending-held' state, the Printer MUST consider\r
+ the job as a candidate for processing by moving the job to the\r
+ 'pending' state.\r
+\r
+ If this job attribute value is the named value 'no-hold', or the\r
+ specified time period has already started, the job MUST be a\r
+ candidate for processing immediately.\r
+\r
+ If the client does not supply this attribute and this attribute is\r
+ supported by the Printer object, the Printer object MUST use the\r
+ value of the Printer object's "job-hold-until-default" at job\r
+ submission time (unlike most Job Template attributes that are used if\r
+ necessary at job processing time).\r
+\r
+4.2.3 job-sheets (type3 keyword | name(MAX))\r
+\r
+ This attribute determines which job start/end sheet(s), if any, MUST\r
+ be printed with a job.\r
+\r
+ Standard keyword values are:\r
+\r
+ 'none': no job sheet is printed\r
+ 'standard': one or more site specific standard job sheets are\r
+ printed, e.g. a single start sheet or both start and end sheet is\r
+ printed\r
+\r
+ An administrator MAY define additional values using the 'name' or\r
+ 'keyword' attribute syntax, depending on implementation.\r
+\r
+ The effect of this attribute on jobs with multiple documents MAY be\r
+ affected by the "multiple-document-handling" job attribute (section\r
+ 4.2.4), depending on the job sheet semantics.\r
+\r
+4.2.4 multiple-document-handling (type2 keyword)\r
+\r
+ This attribute is relevant only if a job consists of two or more\r
+ documents. This attribute MUST be supported with at least one value\r
+ if the Printer supports multiple documents per job (see sections\r
+ 3.2.4 and 3.3.1). The attribute controls finishing operations and\r
+ the placement of one or more print-stream pages into impressions and\r
+ onto media sheets. When the value of the "copies" attribute exceeds\r
+ 1, it also controls the order in which the copies that result from\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 96]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ processing the documents are produced. For the purposes of this\r
+ explanations, if "a" represents an instance of document data, then\r
+ the result of processing the data in document "a" is a sequence of\r
+ media sheets represented by "a(*)".\r
+\r
+ Standard keyword values are:\r
+\r
+ 'single-document': If a Job object has multiple documents, say,\r
+ the document data is called a and b, then the result of\r
+ processing all the document data (a and then b) MUST be treated\r
+ as a single sequence of media sheets for finishing operations;\r
+ that is, finishing would be performed on the concatenation of\r
+ the sequences a(*),b(*). The Printer object MUST NOT force the\r
+ data in each document instance to be formatted onto a new\r
+ print-stream page, nor to start a new impression on a new media\r
+ sheet. If more than one copy is made, the ordering of the sets\r
+ of media sheets resulting from processing the document data\r
+ MUST be a(*), b(*), a(*), b(*), start on a new media sheet.\r
+ 'separate-documents-uncollated-copies': If a Job object has\r
+ multiple documents, say, the document data is called a and b,\r
+ then the result of processing the data in each document\r
+ instance MUST be treated as a single sequence of media sheets\r
+ for finishing operations; that is, the sets a(*) and b(*) would\r
+ each be finished separately. The Printer object MUST force each\r
+ copy of the result of processing the data in a single document\r
+ to start on a new media sheet. If more than one copy is made,\r
+ the ordering of the sets of media sheets resulting from\r
+ processing the document data MUST be a(*), a(*), ..., b(*),\r
+ b(*) ... .\r
+ 'separate-documents-collated-copies': If a Job object has multiple\r
+ documents, say, the document data is called a and b, then the\r
+ result of processing the data in each document instance MUST be\r
+ treated as a single sequence of media sheets for finishing\r
+ operations; that is, the sets a(*) and b(*) would each be\r
+ finished separately. The Printer object MUST force each copy of\r
+ the result of processing the data in a single document to start\r
+ on a new media sheet. If more than one copy is made, the\r
+ ordering of the sets of media sheets resulting from processing\r
+ the document data MUST be a(*), b(*), a(*), b(*), ... .\r
+ 'single-document-new-sheet': Same as 'single-document', except\r
+ that the Printer object MUST ensure that the first impression\r
+ of each document instance in the job is placed on a new media\r
+ sheet. This value allows multiple documents to be stapled\r
+ together with a single staple where each document starts on a\r
+ new sheet.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 97]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The 'single-document' value is the same as 'separate-documents-\r
+ collated-copies' with respect to ordering of print-stream pages, but\r
+ not media sheet generation, since 'single-document' will put the\r
+ first page of the next document on the back side of a sheet if an odd\r
+ number of pages have been produced so far for the job, while\r
+ 'separate-documents-collated- copies' always forces the next document\r
+ or document copy on to a new sheet. In addition, if the "finishings"\r
+ attribute specifies 'staple', then with 'single-document', documents\r
+ a and b are stapled together as a single document with no regard to\r
+ new sheets, with 'single-document-new-sheet', documents a and b are\r
+ stapled together as a single document, but document b starts on a new\r
+ sheet, but with 'separate-documents-uncollated-copies' and\r
+ 'separate-documents-collated-copies', documents a and b are stapled\r
+ separately.\r
+\r
+ Note: None of these values provide means to produce uncollated sheets\r
+ within a document, i.e., where multiple copies of sheet n are\r
+ produced before sheet n+1 of the same document.\r
+\r
+ The relationship of this attribute and the other attributes that\r
+ control document processing is described in section 15.3.\r
+\r
+4.2.5 copies (integer(1:MAX))\r
+\r
+ This attribute specifies the number of copies to be printed.\r
+\r
+ On many devices the supported number of collated copies will be\r
+ limited by the number of physical output bins on the device, and may\r
+ be different from the number of uncollated copies which can be\r
+ supported.\r
+\r
+ Note: The effect of this attribute on jobs with multiple documents is\r
+ controlled by the "multiple-document-handling" job attribute (section\r
+ 4.2.4) and the relationship of this attribute and the other\r
+ attributes that control document processing is described in section\r
+ 15.3.\r
+\r
+4.2.6 finishings (1setOf type2 enum)\r
+\r
+ This attribute identifies the finishing operations that the Printer\r
+ uses for each copy of each printed document in the Job. For Jobs with\r
+ multiple documents, the "multiple-document-handling" attribute\r
+ determines what constitutes a "copy" for purposes of finishing.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 98]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Standard enum values are:\r
+\r
+ Value Symbolic Name and Description\r
+\r
+ '3' 'none': Perform no finishing\r
+ '4' 'staple': Bind the document(s) with one or more staples. The\r
+ exact number and placement of the staples is site-\r
+ defined.\r
+ '5' 'punch': This value indicates that holes are required in the\r
+ finished document. The exact number and placement of the\r
+ holes is site-defined The punch specification MAY be\r
+ satisfied (in a site- and implementation-specific manner)\r
+ either by drilling/punching, or by substituting pre-\r
+ drilled media.\r
+ '6' 'cover': This value is specified when it is desired to select\r
+ a non-printed (or pre-printed) cover for the document.\r
+ This does not supplant the specification of a printed\r
+ cover (on cover stock medium) by the document itself.\r
+ '7' 'bind': This value indicates that a binding is to be applied\r
+ to the document; the type and placement of the binding is\r
+ site-defined.\r
+ '8' 'saddle-stitch': Bind the document(s) with one or more\r
+ staples (wire stitches) along the middle fold. The exact\r
+ number and placement of the staples and the middle fold\r
+ is implementation and/or site-defined.\r
+ '9' 'edge-stitch': Bind the document(s) with one or more staples\r
+ (wire stitches) along one edge. The exact number and\r
+ placement of the staples is implementation and/or site-\r
+ defined.\r
+ '10'-'19' reserved for future generic finishing enum values.\r
+\r
+ The following values are more specific; they indicate a corner or an\r
+ edge as if the document were a portrait document (see below):\r
+\r
+ '20' 'staple-top-left': Bind the document(s) with one or more\r
+ staples in the top left corner.\r
+ '21' 'staple-bottom-left': Bind the document(s) with one or more\r
+ staples in the bottom left corner.\r
+ '22' 'staple-top-right': Bind the document(s) with one or more\r
+ staples in the top right corner.\r
+ '23' 'staple-bottom-right': Bind the document(s) with one or more\r
+ staples in the bottom right corner.\r
+ '24' 'edge-stitch-left': Bind the document(s) with one or more\r
+ staples (wire stitches) along the left edge. The exact\r
+ number and placement of the staples is implementation\r
+ and/or site-defined.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 99]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ '25' 'edge-stitch-top': Bind the document(s) with one or more\r
+ staples (wire stitches) along the top edge. The exact\r
+ number and placement of the staples is implementation\r
+ and/or site-defined.\r
+ '26' 'edge-stitch-right': Bind the document(s) with one or more\r
+ staples (wire stitches) along the right edge. The exact\r
+ number and placement of the staples is implementation\r
+ and/or site-defined.\r
+ '27' 'edge-stitch-bottom': Bind the document(s) with one or more\r
+ staples (wire stitches) along the bottom edge. The exact\r
+ number and placement of the staples is implementation\r
+ and/or site-defined.\r
+ '28' 'staple-dual-left': Bind the document(s) with two staples\r
+ (wire stitches) along the left edge assuming a portrait\r
+ document (see above).\r
+ '29' 'staple-dual-top': Bind the document(s) with two staples\r
+ (wire stitches) along the top edge assuming a portrait\r
+ document (see above).\r
+ '30' 'staple-dual-right': Bind the document(s) with two staples\r
+ (wire stitches) along the right edge assuming a portrait\r
+ document (see above).\r
+ '31' 'staple-dual-bottom': Bind the document(s) with two staples\r
+ (wire stitches) along the bottom edge assuming a portrait\r
+ document (see above).\r
+\r
+ The 'staple-xxx' values are specified with respect to the document as\r
+ if the document were a portrait document. If the document is\r
+ actually a landscape or a reverse-landscape document, the client\r
+ supplies the appropriate transformed value. For example, to position\r
+ a staple in the upper left hand corner of a landscape document when\r
+ held for reading, the client supplies the 'staple-bottom-left' value\r
+ (since landscape is defined as a +90 degree rotation of the image\r
+ with respect to the media from portrait, i.e., anti-clockwise). On\r
+ the other hand, to position a staple in the upper left hand corner of\r
+ a reverse-landscape document when held for reading, the client\r
+ supplies the 'staple-top-right' value (since reverse-landscape is\r
+ defined as a -90 degree rotation of the image with respect to the\r
+ media from portrait, i.e., clockwise).\r
+\r
+ The angle (vertical, horizontal, angled) of each staple with respect\r
+ to the document depends on the implementation which may in turn\r
+ depend on the value of the attribute.\r
+\r
+ Note: The effect of this attribute on jobs with multiple documents is\r
+ controlled by the "multiple-document-handling" job attribute (section\r
+ 4.2.4) and the relationship of this attribute and the other\r
+ attributes that control document processing is described in section\r
+ 15.3.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 100]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ If the client supplies a value of 'none' along with any other\r
+ combination of values, it is the same as if only that other\r
+ combination of values had been supplied (that is the 'none' value has\r
+ no effect).\r
+\r
+4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX))\r
+\r
+ This attribute identifies the range(s) of print-stream pages that the\r
+ Printer object uses for each copy of each document which are to be\r
+ printed. Nothing is printed for any pages identified that do not\r
+ exist in the document(s). Ranges MUST be in ascending order, for\r
+ example: 1-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling\r
+ Printer object can process the job in a single pass. If the ranges\r
+ are not ascending or are overlapping, the IPP object MUST reject the\r
+ request and return the 'client-error-bad-request' status code. The\r
+ attribute is associated with print-stream pages not application-\r
+ numbered pages (for example, the page numbers found in the headers\r
+ and or footers for certain word processing applications).\r
+\r
+ For Jobs with multiple documents, the "multiple-document-handling"\r
+ attribute determines what constitutes a "copy" for purposes of the\r
+ specified page range(s). When "multiple-document-handling" is\r
+ 'single-document', the Printer object MUST apply each supplied page\r
+ range once to the concatenation of the print-stream pages. For\r
+ example, if there are 8 documents of 10 pages each, the page-range\r
+ '41:60' prints the pages in the 5th and 6th documents as a single\r
+ document and none of the pages of the other documents are printed.\r
+ When "multiple-document- handling" is 'separate-documents-\r
+ uncollated-copies' or 'separate-documents-collated-copies', the\r
+ Printer object MUST apply each supplied page range repeatedly to each\r
+ document copy. For the same job, the page-range '1:3, 10:10' would\r
+ print the first 3 pages and the 10th page of each of the 8 documents\r
+ in the Job, as 8 separate documents.\r
+\r
+ In most cases, the exact pages to be printed will be generated by a\r
+ device driver and this attribute would not be required. However,\r
+ when printing an archived document which has already been formatted,\r
+ the end user may elect to print just a subset of the pages contained\r
+ in the document. In this case, if page-range = n.m is specified, the\r
+ first page to be printed will be page n. All subsequent pages of the\r
+ document will be printed through and including page m.\r
+\r
+ "page-ranges-supported" is a boolean value indicating whether or not\r
+ the printer is capable of supporting the printing of page ranges.\r
+ This capability may differ from one PDL to another. There is no\r
+ "page-ranges-default" attribute. If the "page-ranges" attribute is\r
+ not supplied by the client, all pages of the document will be\r
+ printed.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 101]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Note: The effect of this attribute on jobs with multiple documents is\r
+ controlled by the "multiple-document-handling" job attribute (section\r
+ 4.2.4) and the relationship of this attribute and the other\r
+ attributes that control document processing is described in section\r
+ 15.3.\r
+\r
+4.2.8 sides (type2 keyword)\r
+\r
+ This attribute specifies how print-stream pages are to be imposed\r
+ upon the sides of an instance of a selected medium, i.e., an\r
+ impression.\r
+\r
+ The standard keyword values are:\r
+\r
+ 'one-sided': imposes each consecutive print-stream page upon the\r
+ same side of consecutive media sheets.\r
+ 'two-sided-long-edge': imposes each consecutive pair of print-\r
+ stream pages upon front and back sides of consecutive media\r
+ sheets, such that the orientation of each pair of print-stream\r
+ pages on the medium would be correct for the reader as if for\r
+ binding on the long edge. This imposition is sometimes called\r
+ 'duplex' or 'head-to-head'.\r
+ 'two-sided-short-edge': imposes each consecutive pair of print-\r
+ stream pages upon front and back sides of consecutive media\r
+ sheets, such that the orientation of each pair of print-stream\r
+ pages on the medium would be correct for the reader as if for\r
+ binding on the short edge. This imposition is sometimes called\r
+ 'tumble' or 'head-to-toe'.\r
+ 'two-sided-long-edge', 'two-sided-short-edge',\r
+ 'tumble', and 'duplex' all work the same for portrait or\r
+ landscape. However\r
+ 'head-to-toe' is\r
+ 'tumble' in portrait but 'duplex' in landscape. 'head-to-head'\r
+ also switches between 'duplex' and 'tumble' when using portrait\r
+ and landscape modes.\r
+\r
+ Note: The effect of this attribute on jobs with multiple documents is\r
+ controlled by the "multiple-document-handling" job attribute (section\r
+ 4.2.4) and the relationship of this attribute and the other\r
+ attributes that control document processing is described in section\r
+ 15.3.\r
+\r
+4.2.9 number-up (integer(1:MAX))\r
+\r
+ This attribute specifies the number of print-stream pages to impose\r
+ upon a single side of an instance of a selected medium. For example,\r
+ if the value is:\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 102]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Value Description\r
+\r
+ '1' the Printer MUST place one print-stream page on a single side\r
+ of an instance of the selected medium (MAY add some sort\r
+ of translation, scaling, or rotation).\r
+ '2' the Printer MUST place two print-stream pages on a single side\r
+ of an instance of the selected medium (MAY add some sort\r
+ of translation, scaling, or rotation).\r
+ '4' the Printer MUST place four print-stream pages on a single\r
+ side of an instance of the selected medium (MAY add some\r
+ sort of translation, scaling, or rotation).\r
+\r
+ This attribute primarily controls the translation, scaling and\r
+ rotation of print-stream pages.\r
+\r
+ Note: The effect of this attribute on jobs with multiple documents is\r
+ controlled by the "multiple-document-handling" job attribute (section\r
+ 4.2.4) and the relationship of this attribute and the other\r
+ attributes that control document processing is described in section\r
+ 15.3.\r
+\r
+4.2.10 orientation-requested (type2 enum)\r
+\r
+ This attribute indicates the desired orientation for printed print-\r
+ stream pages; it does not describe the orientation of the client-\r
+ supplied print-stream pages.\r
+\r
+ For some document formats (such as 'application/postscript'), the\r
+ desired orientation of the print-stream pages is specified within the\r
+ document data. This information is generated by a device driver\r
+ prior to the submission of the print job. Other document formats\r
+ (such as 'text/plain') do not include the notion of desired\r
+ orientation within the document data. In the latter case it is\r
+ possible for the Printer object to bind the desired orientation to\r
+ the document data after it has been submitted. It is expected that a\r
+ Printer object would only support "orientations-requested" for some\r
+ document formats (e.g., 'text/plain' or 'text/html') but not others\r
+ (e.g., 'application/postscript'). This is no different than any\r
+ other Job Template attribute since section 4.2, item 1, points out\r
+ that a Printer object may support or not support any Job Template\r
+ attribute based on the document format supplied by the client.\r
+ However, a special mention is made here since it is very likely that\r
+ a Printer object will support "orientation-requested" for only a\r
+ subset of the supported document formats.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 103]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Standard enum values are:\r
+\r
+ Value Symbolic Name and Description\r
+\r
+ '3' 'portrait': The content will be imaged across the short edge\r
+ of the medium.\r
+ '4' 'landscape': The content will be imaged across the long edge\r
+ of the medium. Landscape is defined to be a rotation of\r
+ the print-stream page to be imaged by +90 degrees with\r
+ respect to the medium (i.e. anti-clockwise) from the\r
+ portrait orientation. Note: The +90 direction was\r
+ chosen because simple finishing on the long edge is the\r
+ same edge whether portrait or landscape\r
+ '5' 'reverse-landscape': The content will be imaged across the\r
+ long edge of the medium. Reverse-landscape is defined to\r
+ be a rotation of the print-stream page to be imaged by -\r
+ 90 degrees with respect to the medium (i.e. clockwise)\r
+ from the portrait orientation. Note: The 'reverse-\r
+ landscape' value was added because some applications\r
+ rotate landscape -90 degrees from portrait, rather than\r
+ +90 degrees.\r
+ '6' 'reverse-portrait': The content will be imaged across the\r
+ short edge of the medium. Reverse-portrait is defined to\r
+ be a rotation of the print-stream page to be imaged by\r
+ 180 degrees with respect to the medium from the portrait\r
+ orientation. Note: The 'reverse-portrait' value was\r
+ added for use with the "finishings" attribute in cases\r
+ where the opposite edge is desired for finishing a\r
+ portrait document on simple finishing devices that have\r
+ only one finishing position. Thus a 'text'/plain'\r
+ portrait document can be stapled "on the right" by a\r
+ simple finishing device as is common use with some middle\r
+ eastern languages such as Hebrew.\r
+\r
+ Note: The effect of this attribute on jobs with multiple documents is\r
+ controlled by the "multiple-document-handling" job attribute (section\r
+ 4.2.4) and the relationship of this attribute and the other\r
+ attributes that control document processing is described in section\r
+ 15.3.\r
+\r
+4.2.11 media (type3 keyword | name(MAX))\r
+\r
+ This attribute identifies the medium that the Printer uses for all\r
+ impressions of the Job.\r
+\r
+ The values for "media" include medium-names, medium-sizes, input-\r
+ trays and electronic forms so that one attribute specifies the media.\r
+ If a Printer object supports a medium name as a value of this\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 104]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ attribute, such a medium name implicitly selects an input-tray that\r
+ contains the specified medium. If a Printer object supports a medium\r
+ size as a value of this attribute, such a medium size implicitly\r
+ selects a medium name that in turn implicitly selects an input-tray\r
+ that contains the medium with the specified size. If a Printer\r
+ object supports an input-tray as the value of this attribute, such an\r
+ input-tray implicitly selects the medium that is in that input-tray\r
+ at the time the job prints. This case includes manual-feed input-\r
+ trays. If a Printer object supports an electronic form as the value\r
+ of this attribute, such an electronic form implicitly selects a\r
+ medium-name that in turn implicitly selects an input-tray that\r
+ contains the medium specified by the electronic form. The electronic\r
+ form also implicitly selects an image that the Printer MUST merge\r
+ with the document data as its prints each page.\r
+\r
+ Standard keyword values are taken from ISO DPA [ISO10175], the\r
+ Printer MIB [RFC1759], and ASME-Y14.1M [ASME-Y14.1M] and are listed\r
+ in section 14. An administrator MAY define additional values using\r
+ the 'name' or 'keyword' attribute syntax, depending on\r
+ implementation.\r
+\r
+ There is also an additional Printer attribute named "media-ready"\r
+ which differs from "media-supported" in that legal values only\r
+ include the subset of "media-supported" values that are physically\r
+ loaded and ready for printing with no operator intervention required.\r
+ If an IPP object supports "media-supported", it NEED NOT support\r
+ "media-ready".\r
+\r
+ The relationship of this attribute and the other attributes that\r
+ control document processing is described in section 15.3.\r
+\r
+4.2.12 printer-resolution (resolution)\r
+\r
+ This attribute identifies the resolution that Printer uses for the\r
+ Job.\r
+\r
+4.2.13 print-quality (type2 enum)\r
+\r
+ This attribute specifies the print quality that the Printer uses for\r
+ the Job.\r
+\r
+ The standard enum values are:\r
+\r
+ Value Symbolic Name and Description\r
+\r
+ '3' 'draft': lowest quality available on the printer\r
+ '4' 'normal': normal or intermediate quality on the printer\r
+ '5' 'high': highest quality available on the printer\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 105]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.3 Job Description Attributes\r
+\r
+ The attributes in this section form the attribute group called "job-\r
+ description". The following table summarizes these attributes. The\r
+ third column indicates whether the attribute is a REQUIRED attribute\r
+ that MUST be supported by Printer objects. If it is not indicated as\r
+ REQUIRED, then it is OPTIONAL. The maximum size in octets for 'text'\r
+ and 'name' attributes is indicated in parenthesizes.\r
+\r
+ +----------------------------+----------------------+--------------+\r
+ | Attribute | Syntax | REQUIRED? |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-uri | uri | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-id | integer(1:MAX) | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-printer-uri | uri | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-more-info | uri | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-name | name (MAX) | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-originating-user-name | name (MAX) | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-state | type1 enum | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-state-reasons | 1setOf type2 keyword | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-state-message | text (MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-detailed-status- | 1setOf text (MAX) | |\r
+ | messages | | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-document-access-errors | 1setOf text (MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | number-of-documents | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | output-device-assigned | name (127) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | time-at-creation | integer (MIN:MAX) | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | time-at-processing | integer (MIN:MAX) | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | time-at-completed | integer (MIN:MAX) | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-printer-up-time | integer (1:MAX) | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | date-time-at-creation | dateTime | |\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 106]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ +----------------------------+----------------------+--------------+\r
+ | date-time-at-processing | dateTime | |\r
+ +----------------------------+----------------------+--------------+\r
+ | date-time-at-completed | dateTime | |\r
+ +----------------------------+----------------------+--------------+\r
+ | number-of-intervening-jobs | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-message-from-operator | text (127) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-k-octets | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-impressions | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-media-sheets | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-k-octets-processed | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-impressions-completed | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | job-media-sheets-completed | integer (0:MAX) | |\r
+ +----------------------------+----------------------+--------------+\r
+ | attributes-charset | charset | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+ | attributes-natural-language| naturalLanguage | REQUIRED |\r
+ +----------------------------+----------------------+--------------+\r
+\r
+4.3.1 job-uri (uri)\r
+\r
+ This REQUIRED attribute contains the URI for the job. The Printer\r
+ object, on receipt of a new job, generates a URI which identifies the\r
+ new Job. The Printer object returns the value of the "job-uri"\r
+ attribute as part of the response to a create request. The precise\r
+ format of a Job URI is implementation dependent. If the Printer\r
+ object supports more than one URI and there is some relationship\r
+ between the newly formed Job URI and the Printer object's URI, the\r
+ Printer object uses the Printer URI supplied by the client in the\r
+ create request. For example, if the create request comes in over a\r
+ secure channel, the new Job URI MUST use the same secure channel.\r
+ This can be guaranteed because the Printer object is responsible for\r
+ generating the Job URI and the Printer object is aware of its\r
+ security configuration and policy as well as the Printer URI used in\r
+ the create request.\r
+\r
+ For a description of this attribute and its relationship to "job-id"\r
+ and "job-printer-uri" attribute, see the discussion in section 2.4 on\r
+ "Object Identity".\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 107]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.3.2 job-id (integer(1:MAX))\r
+\r
+ This REQUIRED attribute contains the ID of the job. The Printer, on\r
+ receipt of a new job, generates an ID which identifies the new Job on\r
+ that Printer. The Printer returns the value of the "job-id"\r
+ attribute as part of the response to a create request. The 0 value\r
+ is not included to allow for compatibility with SNMP index values\r
+ which also cannot be 0.\r
+\r
+ For a description of this attribute and its relationship to "job-uri"\r
+ and "job-printer-uri" attribute, see the discussion in section 2.4 on\r
+ "Object Identity".\r
+\r
+4.3.3 job-printer-uri (uri)\r
+\r
+ This REQUIRED attribute identifies the Printer object that created\r
+ this Job object. When a Printer object creates a Job object, it\r
+ populates this attribute with the Printer object URI that was used in\r
+ the create request. This attribute permits a client to identify the\r
+ Printer object that created this Job object when only the Job\r
+ object's URI is available to the client. The client queries the\r
+ creating Printer object to determine which languages, charsets,\r
+ operations, are supported for this Job.\r
+\r
+ For a description of this attribute and its relationship to "job-uri"\r
+ and "job-id" attribute, see the discussion in section 2.4 on "Object\r
+ Identity".\r
+\r
+4.3.4 job-more-info (uri)\r
+\r
+ Similar to "printer-more-info", this attribute contains the URI\r
+ referencing some resource with more information about this Job\r
+ object, perhaps an HTML page containing information about the Job.\r
+\r
+4.3.5 job-name (name(MAX))\r
+\r
+ This REQUIRED attribute is the name of the job. It is a name that is\r
+ more user friendly than the "job-uri" attribute value. It does not\r
+ need to be unique between Jobs. The Job's "job-name" attribute is\r
+ set to the value supplied by the client in the "job-name" operation\r
+ attribute in the create request (see Section 3.2.1.1). If, however,\r
+ the "job-name" operation attribute is not supplied by the client in\r
+ the create request, the Printer object, on creation of the Job, MUST\r
+ generate a name. The printer SHOULD generate the value of the Job's\r
+ "job-name" attribute from the first of the following sources that\r
+ produces a value: 1) the "document-name" operation attribute of the\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 108]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ first (or only) document, 2) the "document-URI" attribute of the\r
+ first (or only) document, or 3) any other piece of Job specific\r
+ and/or Document Content information.\r
+\r
+4.3.6 job-originating-user-name (name(MAX))\r
+\r
+ This REQUIRED attribute contains the name of the end user that\r
+ submitted the print job. The Printer object sets this attribute to\r
+ the most authenticated printable name that it can obtain from the\r
+ authentication service over which the IPP operation was received.\r
+ Only if such is not available, does the Printer object use the value\r
+ supplied by the client in the "requesting-user-name" operation\r
+ attribute of the create operation (see Sections 4.4.2, 4.4.3, and 8).\r
+\r
+ Note: The Printer object needs to keep an internal originating user\r
+ id of some form, typically as a credential of a principal, with the\r
+ Job object. Since such an internal attribute is implementation-\r
+ dependent and not of interest to clients, it is not specified as a\r
+ Job Description attribute. This originating user id is used for\r
+ authorization checks (if any) on all subsequent operations.\r
+\r
+4.3.7 job-state (type1 enum)\r
+\r
+ This REQUIRED attribute identifies the current state of the job.\r
+ Even though the IPP protocol defines seven values for job states\r
+ (plus the out-of-band 'unknown' value - see Section 4.1),\r
+ implementations only need to support those states which are\r
+ appropriate for the particular implementation. In other words, a\r
+ Printer supports only those job states implemented by the output\r
+ device and available to the Printer object implementation.\r
+\r
+ Standard enum values are:\r
+\r
+ Values Symbolic Name and Description\r
+\r
+ '3' 'pending': The job is a candidate to start processing, but is\r
+ not yet processing.\r
+\r
+ '4' 'pending-held': The job is not a candidate for processing for\r
+ any number of reasons but will return to the 'pending'\r
+ state as soon as the reasons are no longer present. The\r
+ job's "job-state-reason" attribute MUST indicate why the\r
+ job is no longer a candidate for processing.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 109]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ '5' 'processing': One or more of:\r
+\r
+ 1. the job is using, or is attempting to use, one or\r
+ more purely software processes that are analyzing,\r
+ creating, or interpreting a PDL, etc.,\r
+ 2. the job is using, or is attempting to use, one or\r
+ more hardware devices that are interpreting a PDL, making\r
+ marks on a medium, and/or performing finishing, such as\r
+ stapling, etc.,\r
+ 3. the Printer object has made the job ready for\r
+ printing, but the output device is not yet printing it,\r
+ either because the job hasn't reached the output device\r
+ or because the job is queued in the output device or some\r
+ other spooler, awaiting the output device to print it.\r
+\r
+ When the job is in the 'processing' state, the entire job\r
+ state includes the detailed status represented in the\r
+ Printer object's "printer-state", "printer-state-\r
+ reasons", and "printer-state-message" attributes.\r
+\r
+ Implementations MAY, though they NEED NOT, include\r
+ additional values in the job's "job-state-reasons"\r
+ attribute to indicate the progress of the job, such as\r
+ adding the 'job-printing' value to indicate when the\r
+ output device is actually making marks on paper and/or\r
+ the 'processing-to-stop-point' value to indicate that the\r
+ IPP object is in the process of canceling or aborting the\r
+ job. Most implementations won't bother with this nuance.\r
+\r
+ '6' 'processing-stopped': The job has stopped while processing\r
+ for any number of reasons and will return to the\r
+ 'processing' state as soon as the reasons are no longer\r
+ present.\r
+\r
+ The job's "job-state-reason" attribute MAY indicate why\r
+ the job has stopped processing. For example, if the\r
+ output device is stopped, the 'printer-stopped' value MAY\r
+ be included in the job's "job-state-reasons" attribute.\r
+\r
+ Note: When an output device is stopped, the device\r
+ usually indicates its condition in human readable form\r
+ locally at the device. A client can obtain more complete\r
+ device status remotely by querying the Printer object's\r
+ "printer-state", "printer-state-reasons" and "printer-\r
+ state-message" attributes.\r
+\r
+ '7' 'canceled': The job has been canceled by a Cancel-Job\r
+ operation and the Printer object has completed canceling\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 110]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ the job and all job status attributes have reached their\r
+ final values for the job. While the Printer object is\r
+ canceling the job, the job remains in its current state,\r
+ but the job's "job-state-reasons" attribute SHOULD\r
+ contain the 'processing-to-stop-point' value and one of\r
+ the 'canceled-by-user', 'canceled-by-operator', or\r
+ 'canceled-at-device' value. When the job moves to the\r
+ 'canceled' state, the 'processing-to-stop-point' value,\r
+ if present, MUST be removed, but the 'canceled-by-xxx',\r
+ if present, MUST remain.\r
+\r
+ '8' 'aborted': The job has been aborted by the system, usually\r
+ while the job was in the 'processing' or 'processing-\r
+ stopped' state and the Printer has completed aborting the\r
+ job and all job status attributes have reached their\r
+ final values for the job. While the Printer object is\r
+ aborting the job, the job remains in its current state,\r
+ but the job's "job-state-reasons" attribute SHOULD\r
+ contain the 'processing-to-stop-point' and 'aborted-by-\r
+ system' values. When the job moves to the 'aborted'\r
+ state, the 'processing-to-stop-point' value, if present,\r
+ MUST be removed, but the 'aborted-by-system' value, if\r
+ present, MUST remain.\r
+\r
+ '9' 'completed': The job has completed successfully or with\r
+ warnings or errors after processing and all of the job\r
+ media sheets have been successfully stacked in the\r
+ appropriate output bin(s) and all job status attributes\r
+ have reached their final values for the job. The job's\r
+ "job-state-reasons" attribute SHOULD contain one of:\r
+ 'completed-successfully', 'completed-with-warnings', or\r
+ 'completed-with-errors' values.\r
+\r
+ The final value for this attribute MUST be one of: 'completed',\r
+ 'canceled', or 'aborted' before the Printer removes the job\r
+ altogether. The length of time that jobs remain in the 'canceled',\r
+ 'aborted', and 'completed' states depends on implementation. See\r
+ section 4.3.7.2.\r
+\r
+ The following figure shows the normal job state transitions.\r
+\r
+ +----> canceled\r
+ /\r
+ +----> pending --------> processing ---------+------> completed\r
+ | ^ ^ \\r
+ --->+ | | +----> aborted\r
+ | v v /\r
+ +----> pending-held processing-stopped ---+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 111]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Normally a job progresses from left to right. Other state\r
+ transitions are unlikely, but are not forbidden. Not shown are the\r
+ transitions to the 'canceled' state from the 'pending', 'pending-\r
+ held', and 'processing-stopped' states.\r
+\r
+ Jobs reach one of the three terminal states: 'completed', 'canceled',\r
+ or 'aborted', after the jobs have completed all activity, including\r
+ stacking output media, after the jobs have completed all activity,\r
+ and all job status attributes have reached their final values for the\r
+ job.\r
+\r
+4.3.7.1 Forwarding Servers\r
+\r
+ As with all other IPP attributes, if the implementation cannot\r
+ determine the correct value for this attribute, it SHOULD respond\r
+ with the out-of-band value 'unknown' (see section 4.1) rather than\r
+ try to guess at some possibly incorrect value and give the end user\r
+ the wrong impression about the state of the Job object. For example,\r
+ if the implementation is just a gateway into some printing system\r
+ from which it can normally get status, but temporarily is unable,\r
+ then the implementation should return the 'unknown' value. However,\r
+ if the implementation is a gateway to a printing system that never\r
+ provides detailed status about the print job, the implementation MAY\r
+ set the IPP Job object's state to 'completed', provided that it also\r
+ sets the 'queued-in-device' value in the job's "job-state-reasons"\r
+ attribute (see section 4.3.8).\r
+\r
+4.3.7.2 Partitioning of Job States\r
+\r
+ This section partitions the 7 job states into phases: Job Not\r
+ Completed, Job Retention, Job History, and Job Removal. This section\r
+ also explains the 'job-restartable' value of the "job-state-reasons"\r
+ Job Description attribute for use with the Restart-Job operation.\r
+\r
+ Job Not Completed: When a job is in the 'pending', 'pending-held',\r
+ 'processing', or 'processing-stopped' states, the job is not\r
+ completed.\r
+\r
+ Job Retention: When a job enters one of the three terminal job\r
+ states: 'completed', 'canceled', or 'aborted', the IPP Printer\r
+ object MAY "retain" the job in a restartable condition for an\r
+ implementation-defined time period. This time period MAY be zero\r
+ seconds and MAY depend on the terminal job state. This phase is\r
+ called Job Retention. While in the Job Retention phase, the job's\r
+ document data is retained and a client may restart the job using the\r
+ Restart-Job operation. If the IPP object supports the Restart-Job\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 112]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ operation, then it SHOULD indicate that the job is restartable by\r
+ adding the 'job-restartable' value to the job's "job-state-reasons"\r
+ attribute (see Section 4.3.8) during the Job Retention phase.\r
+\r
+ Job History: After the Job Retention phase expires for a job, the\r
+ Printer object deletes the document data for the job and the job\r
+ becomes part of the Job History. The Printer object MAY also delete\r
+ any number of the job attributes. Since the job is no longer\r
+ restartable, the Printer object MUST remove the 'job-restartable'\r
+ value from the job's "job-state-reasons" attribute, if present.\r
+\r
+ Job Removal: After the job has remained in the Job History for an\r
+ implementation-defined time, such as when the number of jobs exceeds\r
+ a fixed number or after a fixed time period (which MAY be zero\r
+ seconds), the IPP Printer removes the job from the system.\r
+\r
+ Using the Get-Jobs operation and supplying the 'not-completed' value\r
+ for the "which-jobs" operation attribute, a client is requesting jobs\r
+ in the Job Not Completed phase. Using the Get-Jobs operation and\r
+ supplying the 'completed' value for the "which-jobs" operation\r
+ attribute, a client is requesting jobs in the Job Retention and Job\r
+ History phases. Using the Get-Job-Attributes operation, a client is\r
+ requesting a job in any phase except Job Removal. After Job Removal,\r
+ the Get-Job-Attributes and Get-Jobs operations no longer are capable\r
+ of returning any information about a job.\r
+\r
+4.3.8 job-state-reasons (1setOf type2 keyword)\r
+\r
+ This REQUIRED attribute provides additional information about the\r
+ job's current state, i.e., information that augments the value of the\r
+ job's "job-state" attribute.\r
+\r
+ These values MAY be used with any job state or states for which the\r
+ reason makes sense. Some of these value definitions indicate\r
+ conformance requirements; the rest are OPTIONAL. Furthermore, when\r
+ implemented, the Printer MUST return these values when the reason\r
+ applies and MUST NOT return them when the reason no longer applies\r
+ whether the value of the Job's "job-state" attribute changed or not.\r
+ When the Job does not have any reasons for being in its current\r
+ state, the value of the Job's "job-state-reasons" attribute MUST be\r
+ 'none'.\r
+\r
+ Note: While values cannot be added to the 'job-state' attribute\r
+ without impacting deployed clients that take actions upon receiving\r
+ "job-state" values, it is the intent that additional "job-state-\r
+ reasons" values can be defined and registered without impacting such\r
+ deployed clients. In other words, the "job-state-reasons" attribute\r
+ is intended to be extensible.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 113]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The following standard keyword values are defined. For ease of\r
+ understanding, the values are presented in the order in which the\r
+ reasons are likely to occur (if implemented), starting with the\r
+ 'job-incoming' value:\r
+\r
+ 'none': There are no reasons for the job's current state. This\r
+ state reason is semantically equivalent to "job-state-reasons"\r
+ without any value and MUST be used when there is no other\r
+ value, since the 1setOf attribute syntax requires at least one\r
+ value.\r
+ 'job-incoming': Either (1) the Printer has accepted the Create-\r
+ Job operation and is expecting additional Send-Document and/or\r
+ Send-URI operations, or (2) the Printer is retrieving/accepting\r
+ document data as a result of a Print-Job, Print-URI, Send-\r
+ Document or Send-URI operation.\r
+ 'job-data-insufficient': The Create-Job operation has been\r
+ accepted by the Printer, but the Printer is expecting\r
+ additional document data before it can move the job into the\r
+ 'processing' state. If a Printer starts processing before it\r
+ has received all data, the Printer removes the 'job-data-\r
+ insufficient' reason, but the 'job-incoming' remains. If a\r
+ Printer starts processing after it has received all data, the\r
+ Printer removes the 'job-data-insufficient' reason and the\r
+ 'job-incoming' at the same time.\r
+ 'document-access-error': After accepting a Print-URI or Send-URI\r
+ request, the Printer could not access one or more documents\r
+ passed by reference. This reason is intended to cover any file\r
+ access problem, including file does not exist and access denied\r
+ because of an access control problem. The Printer MAY also\r
+ indicate the document access error using the "job-document-\r
+ access-errors" Job Description attribute (see section 4.3.11).\r
+ Whether the Printer aborts the job and moves the job to the\r
+ 'aborted' job state or prints all documents that are accessible\r
+ and moves the job to the 'completed' job state and adds the\r
+ 'completed-with-errors' value in the job's "job-state-reasons"\r
+ attribute depends on implementation and/or site policy. This\r
+ value SHOULD be supported if the Print-URI or Send-URI\r
+ operations are supported.\r
+ 'submission-interrupted': The job was not completely submitted\r
+ for some unforeseen reason, such as: (1) the Printer has\r
+ crashed before the job was closed by the client, (2) the\r
+ Printer or the document transfer method has crashed in some\r
+ non-recoverable way before the document data was entirely\r
+ transferred to the Printer, (3) the client crashed or failed to\r
+ close the job before the time-out period. See section 4.4.31.\r
+ 'job-outgoing': The Printer is transmitting the job to the output\r
+ device.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 114]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'job-hold-until-specified': The value of the job's "job-hold-\r
+ until" attribute was specified with a time period that is still\r
+ in the future. The job MUST NOT be a candidate for processing\r
+ until this reason is removed and there are no other reasons to\r
+ hold the job. This value SHOULD be supported if the "job-\r
+ hold-until" Job Template attribute is supported.\r
+ 'resources-are-not-ready': At least one of the resources needed\r
+ by the job, such as media, fonts, resource objects, etc., is\r
+ not ready on any of the physical printer's for which the job is\r
+ a candidate. This condition MAY be detected when the job is\r
+ accepted, or subsequently while the job is pending or\r
+ processing, depending on implementation. The job may remain in\r
+ its current state or be moved to the 'pending-held' state,\r
+ depending on implementation and/or job scheduling policy.\r
+ 'printer-stopped-partly': The value of the Printer's "printer-\r
+ state-reasons" attribute contains the value 'stopped-partly'.\r
+ 'printer-stopped': The value of the Printer's "printer-state"\r
+ attribute is 'stopped'.\r
+ 'job-interpreting': Job is in the 'processing' state, but more\r
+ specifically, the Printer is interpreting the document data.\r
+ 'job-queued': Job is in the 'processing' state, but more\r
+ specifically, the Printer has queued the document data.\r
+ 'job-transforming': Job is in the 'processing' state, but more\r
+ specifically, the Printer is interpreting document data and\r
+ producing another electronic representation.\r
+ 'job-queued-for-marker': Job is in any of the 'pending-held',\r
+ 'pending', or 'processing' states, but more specifically, the\r
+ Printer has completed enough processing of the document to be\r
+ able to start marking and the job is waiting for the marker.\r
+ Systems that require human intervention to release jobs using\r
+ the Release-Job operation, put the job into the 'pending-held'\r
+ job state. Systems that automatically select a job to use the\r
+ marker put the job into the 'pending' job state or keep the\r
+ job in the 'processing' job state while waiting for the marker,\r
+ depending on implementation. All implementations put the job\r
+ into (or back into) the 'processing' state when marking does\r
+ begin.\r
+ 'job-printing': The output device is marking media. This value is\r
+ useful for Printers which spend a great deal of time processing\r
+ (1) when no marking is happening and then want to show that\r
+ marking is now happening or (2) when the job is in the process\r
+ of being canceled or aborted while the job remains in the\r
+ 'processing' state, but the marking has not yet stopped so that\r
+ impression or sheet counts are still increasing for the job.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 115]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'job-canceled-by-user': The job was canceled by the owner of the\r
+ job using the Cancel-Job request, i.e., by a user whose\r
+ authenticated identity is the same as the value of the\r
+ originating user that created the Job object, or by some other\r
+ authorized end-user, such as a member of the job owner's\r
+ security group. This value SHOULD be supported.\r
+ 'job-canceled-by-operator': The job was canceled by the operator\r
+ using the Cancel-Job request, i.e., by a user who has been\r
+ authenticated as having operator privileges (whether local or\r
+ remote). If the security policy is to allow anyone to cancel\r
+ anyone's job, then this value may be used when the job is\r
+ canceled by other than the owner of the job. For such a\r
+ security policy, in effect, everyone is an operator as far as\r
+ canceling jobs with IPP is concerned. This value SHOULD be\r
+ supported if the implementation permits canceling by other than\r
+ the owner of the job.\r
+ 'job-canceled-at-device': The job was canceled by an unidentified\r
+ local user, i.e., a user at a console at the device. This\r
+ value SHOULD be supported if the implementation supports\r
+ canceling jobs at the console.\r
+ 'aborted-by-system': The job (1) is in the process of being\r
+ aborted, (2) has been aborted by the system and placed in the\r
+ 'aborted' state, or (3) has been aborted by the system and\r
+ placed in the 'pending-held' state, so that a user or operator\r
+ can manually try the job again. This value SHOULD be\r
+ supported.\r
+ 'unsupported-compression': The job was aborted by the system\r
+ because the Printer determined while attempting to decompress\r
+ the document-data's that the compression is actually not among\r
+ those supported by the Printer. This value MUST be supported,\r
+ since "compressions is a REQUIRED operation attribute.\r
+ 'compression-error': The job was aborted by the system because the\r
+ Printer encountered an error in the document-data while\r
+ decompressing it. If the Printer posts this reason, the\r
+ document-data has already passed any tests that would have led\r
+ to the 'unsupported-compression' job-state-reason.\r
+ 'unsupported-document-format': The job was aborted by the system\r
+ because the document-data's document-format is not among those\r
+ supported by the Printer. If the client specifies the\r
+ document-format as 'application/octet-stream', the printer MAY\r
+ abort the job and post this reason even though the format is a\r
+ member of the "document-format-supported" printer attribute,\r
+ but not among the auto-sensed document-formats. This value\r
+ MUST be supported, since "document-format" is a REQUIRED\r
+ operation attribute.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 116]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'document-format-error': The job was aborted by the system because\r
+ the Printer encountered an error in the document-data while\r
+ processing it. If the Printer posts this reason, the\r
+ document-data has already passed any tests that would have led\r
+ to the 'unsupported-document-format' job-state-reason.\r
+ 'processing-to-stop-point': The requester has issued a Cancel-Job\r
+ operation or the Printer object has aborted the job, but is\r
+ still performing some actions on the job until a specified stop\r
+ point occurs or job termination/cleanup is completed.\r
+\r
+ If the implementation requires some measurable time to cancel\r
+ the job in the 'processing' or 'processing-stopped' job states,\r
+ the IPP object MUST use this value to indicate that the Printer\r
+ object is still performing some actions on the job while the\r
+ job remains in the 'processing' or 'processing-stopped' state.\r
+ After all the job's job description attributes have stopped\r
+ incrementing, the Printer object moves the job from the\r
+ 'processing' state to the 'canceled' or\r
+ 'aborted' job states.\r
+\r
+ 'service-off-line': The Printer is off-line and accepting no\r
+ jobs. All 'pending' jobs are put into the 'pending-held'\r
+ state. This situation could be true if the service's or\r
+ document transform's input is impaired or broken.\r
+ 'job-completed-successfully': The job completed successfully.\r
+ This value SHOULD be supported.\r
+ 'job-completed-with-warnings': The job completed with warnings.\r
+ This value SHOULD be supported if the implementation detects\r
+ warnings.\r
+ 'job-completed-with-errors': The job completed with errors (and\r
+ possibly warnings too). This value SHOULD be supported if the\r
+ implementation detects errors.\r
+ 'job-restartable' - This job is retained (see section 4.3.7.2) and\r
+ is currently able to be restarted using the Restart-Job\r
+ operation (see section 3.3.7). If 'job-restartable' is a value\r
+ of the job's 'job-state-reasons' attribute, then the IPP object\r
+ MUST accept a Restart-Job operation for that job. This value\r
+ SHOULD be supported if the Restart-Job operation is supported.\r
+ 'queued-in-device': The job has been forwarded to a device or\r
+ print system that is unable to send back status. The Printer\r
+ sets the job's "job-state " attribute to 'completed' and adds\r
+ the 'queued-in-device' value to the job's "job-state-reasons"\r
+ attribute to indicate that the Printer has no additional\r
+ information about the job and never will have any better\r
+ information. See section 4.3.7.1.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 117]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.3.9 job-state-message (text(MAX))\r
+\r
+ This attribute specifies information about the "job-state" and "job-\r
+ state-reasons" attributes in human readable text. If the Printer\r
+ object supports this attribute, the Printer object MUST be able to\r
+ generate this message in any of the natural languages identified by\r
+ the Printer's "generated-natural-language-supported" attribute (see\r
+ the "attributes-natural-language" operation attribute specified in\r
+ Section 3.1.4.1).\r
+\r
+ The value SHOULD NOT contain additional information not contained in\r
+ the values of the "job-state" and "job-states-reasons" attributes,\r
+ such as interpreter error information. Otherwise, application\r
+ programs might attempt to parse the (localized text). For such\r
+ additional information such as interpreter errors for application\r
+ program consumption or specific document access errors, new\r
+ attributes with keyword values, needs to be developed and registered.\r
+\r
+4.3.10 job-detailed-status-messages (1setOf text(MAX))\r
+\r
+ This attribute specifies additional detailed and technical\r
+ information about the job. The Printer NEED NOT localize the\r
+ message(s), since they are intended for use by the system\r
+ administrator or other experienced technical persons. Localization\r
+ might obscure the technical meaning of such messages. Clients MUST\r
+ NOT attempt to parse the value of this attribute. See "job-\r
+ document-access-errors" (section 4.3.11) for additional errors that a\r
+ program can process.\r
+\r
+4.3.11 job-document-access-errors (1setOf text(MAX))\r
+\r
+ This attribute provides additional information about each document\r
+ access error for this job encountered by the Printer after it\r
+ returned a response to the Print-URI or Send-URI operation and\r
+ subsequently attempted to access document(s) supplied in the Print-\r
+ URI or Send-URI operation. For errors in the protocol that is\r
+ identified by the URI scheme in the "document-uri" operation\r
+ attribute, such as 'http:' or 'ftp:', the error code is returned in\r
+ parentheses, followed by the URI. For example:\r
+\r
+ (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf\r
+\r
+ Most Internet protocols use decimal error codes (unlike IPP), so the\r
+ ASCII error code representation is in decimal.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 118]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.3.12 number-of-documents (integer(0:MAX))\r
+\r
+ This attribute indicates the number of documents in the job, i.e.,\r
+ the number of Send-Document, Send-URI, Print-Job, or Print-URI\r
+ operations that the Printer has accepted for this job, regardless of\r
+ whether the document data has reached the Printer object or not.\r
+\r
+ Implementations supporting the OPTIONAL Create-Job/Send-\r
+ Document/Send-URI operations SHOULD support this attribute so that\r
+ clients can query the number of documents in each job.\r
+\r
+4.3.13 output-device-assigned (name(127))\r
+\r
+ This attribute identifies the output device to which the Printer\r
+ object has assigned this job. If an output device implements an\r
+ embedded Printer object, the Printer object NEED NOT set this\r
+ attribute. If a print server implements a Printer object, the value\r
+ MAY be empty (zero- length string) or not returned until the Printer\r
+ object assigns an output device to the job. This attribute is\r
+ particularly useful when a single Printer object supports multiple\r
+ devices (so called "fan-out" - see section 2.1).\r
+\r
+4.3.14 Event Time Job Description Attributes\r
+\r
+ This section defines the Job Description attributes that indicate the\r
+ time at which certain events occur for a job. If the job event has\r
+ not yet occurred, then the IPP object MUST return the 'no-value'\r
+ out-of-band value (see the beginning of Section 4.1). The "time-at-\r
+ xxx(integer)" attributes represent time as an 'integer' representing\r
+ the number of seconds since the device was powered up (informally\r
+ called "time ticks"). The "date-time-at-xxx(dateTime)" attributes\r
+ represent time as 'dateTime' representing date and time (including an\r
+ offset from UTC).\r
+\r
+ In order to populate these attributes, the Printer object copies the\r
+ value(s) of the following Printer Description attributes at the time\r
+ the event occurs:\r
+\r
+ 1. the value in the Printer's "printer-up-time" attribute for the\r
+ "time-at-xxx(integer)" attributes\r
+\r
+ 2. the value in the Printer's "printer-current-time" attribute for\r
+ the "date-time-at-xxx(dateTime)" attributes.\r
+\r
+ If the Printer resets its "printer-up-time" attribute to 1 on power-\r
+ up (see section 4.4.29) and has persistent jobs, then it MUST change\r
+ all of jobs' "time-at-xxx(integer)" (time tick) job attributes whose\r
+ events have occurred either to:\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 119]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 1. 0 to indicate that the event happened before the most recent\r
+ power up OR\r
+\r
+ 2. the negative of the number of seconds before the most recent\r
+ power-up that the event took place, though the negative number\r
+ NEED NOT reflect the exact number of seconds.\r
+\r
+ If a client queries a "time-at-xxx(integer)" time tick Job attribute\r
+ and finds the value to be 0 or negative, the client MUST assume that\r
+ the event occurred in some life other than the Printer's current\r
+ life.\r
+\r
+ Note: A Printer does not change the values of any "date-time-at-\r
+ xxx(dateTime)" job attributes on power-up.\r
+\r
+4.3.14.1 time-at-creation (integer(MIN:MAX))\r
+\r
+ This REQUIRED attribute indicates the time at which the Job object\r
+ was created.\r
+\r
+4.3.14.2 time-at-processing (integer(MIN:MAX))\r
+\r
+ This REQUIRED attribute indicates the time at which the Job object\r
+ first began processing after the create operation or the most recent\r
+ Restart-Job operation. The out-of-band 'no-value' value is returned\r
+ if the job has not yet been in the 'processing' state (see the\r
+ beginning of Section 4.1).\r
+\r
+4.3.14.3 time-at-completed (integer(MIN:MAX))\r
+\r
+ This REQUIRED attribute indicates the time at which the Job object\r
+ completed (or was canceled or aborted). The out-of-band 'no-value'\r
+ value is returned if the job has not yet completed, been canceled, or\r
+ aborted (see the beginning of Section 4.1).\r
+\r
+4.3.14.4 job-printer-up-time (integer(1:MAX))\r
+\r
+ This REQUIRED Job Description attribute indicates the amount of time\r
+ (in seconds) that the Printer implementation has been up and running.\r
+ This attribute is an alias for the "printer-up-time" Printer\r
+ Description attribute (see Section 4.4.29).\r
+\r
+ A client MAY request this attribute in a Get-Job-Attributes or Get-\r
+ Jobs request and use the value returned in combination with other\r
+ requested Event Time Job Description Attributes in order to display\r
+ time attributes to a user. The difference between this attribute and\r
+ the 'integer' value of a "time-at-xxx" attribute is the number of\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 120]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ seconds ago that the "time-at-xxx" event occurred. A client can\r
+ compute the wall-clock time at which the "time-at-xxx" event occurred\r
+ by subtracting this difference from the client's wall-clock time.\r
+\r
+4.3.14.5 date-time-at-creation (dateTime)\r
+\r
+ This attribute indicates the date and time at which the Job object\r
+ was created.\r
+\r
+4.3.14.6 date-time-at-processing (dateTime)\r
+\r
+ This attribute indicates the date and time at which the Job object\r
+ first began processing after the create operation or the most recent\r
+ Restart-Job operation.\r
+\r
+4.3.14.7 date-time-at-completed (dateTime)\r
+\r
+ This attribute indicates the date and time at which the Job object\r
+ completed (or was canceled or aborted).\r
+\r
+4.3.15 number-of-intervening-jobs (integer(0:MAX))\r
+\r
+ This attribute indicates the number of jobs that are "ahead" of this\r
+ job in the relative chronological order of expected time to complete\r
+ (i.e., the current scheduled order). For efficiency, it is only\r
+ necessary to calculate this value when an operation is performed that\r
+ requests this attribute.\r
+\r
+4.3.16 job-message-from-operator (text(127))\r
+\r
+ This attribute provides a message from an operator, system\r
+ administrator or "intelligent" process to indicate to the end user\r
+ the reasons for modification or other management action taken on a\r
+ job.\r
+\r
+4.3.17 Job Size Attributes\r
+\r
+ This sub-section defines job attributes that describe the size of the\r
+ job. These attributes are not intended to be counters; they are\r
+ intended to be useful routing and scheduling information if known.\r
+ For these attributes, the Printer object may try to compute the value\r
+ if it is not supplied in the create request. Even if the client does\r
+ supply a value for these three attributes in the create request, the\r
+ Printer object MAY choose to change the value if the Printer object\r
+ is able to compute a value which is more accurate than the client\r
+ supplied value. The Printer object may be able to determine the\r
+ correct value for these attributes either right at job submission\r
+ time or at any later point in time.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 121]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.3.17.1 job-k-octets (integer(0:MAX))\r
+\r
+ This attribute specifies the total size of the document(s) in K\r
+ octets, i.e., in units of 1024 octets requested to be processed in\r
+ the job. The value MUST be rounded up, so that a job between 1 and\r
+ 1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2,\r
+ etc.\r
+\r
+ This value MUST NOT include the multiplicative factors contributed by\r
+ the number of copies specified by the "copies" attribute, independent\r
+ of whether the device can process multiple copies without making\r
+ multiple passes over the job or document data and independent of\r
+ whether the output is collated or not. Thus the value is independent\r
+ of the implementation and indicates the size of the document(s)\r
+ measured in K octets independent of the number of copies.\r
+\r
+ This value MUST also not include the multiplicative factor due to a\r
+ copies instruction embedded in the document data. If the document\r
+ data actually includes replications of the document data, this value\r
+ will include such replication. In other words, this value is always\r
+ the size of the source document data, rather than a measure of the\r
+ hardcopy output to be produced.\r
+\r
+4.3.17.2 job-impressions (integer(0:MAX))\r
+\r
+ This attribute specifies the total size in number of impressions of\r
+ the document(s) being submitted (see the definition of impression in\r
+ section 12.2.5).\r
+\r
+ As with "job-k-octets", this value MUST NOT include the\r
+ multiplicative factors contributed by the number of copies specified\r
+ by the "copies" attribute, independent of whether the device can\r
+ process multiple copies without making multiple passes over the job\r
+ or document data and independent of whether the output is collated or\r
+ not. Thus the value is independent of the implementation and\r
+ reflects the size of the document(s) measured in impressions\r
+ independent of the number of copies.\r
+\r
+ As with "job-k-octets", this value MUST also not include the\r
+ multiplicative factor due to a copies instruction embedded in the\r
+ document data. If the document data actually includes replications\r
+ of the document data, this value will include such replication. In\r
+ other words, this value is always the number of impressions in the\r
+ source document data, rather than a measure of the number of\r
+ impressions to be produced by the job.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 122]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.3.17.3 job-media-sheets (integer(0:MAX))\r
+\r
+ This attribute specifies the total number of media sheets to be\r
+ produced for this job.\r
+\r
+ Unlike the "job-k-octets" and the "job-impressions" attributes, this\r
+ value MUST include the multiplicative factors contributed by the\r
+ number of copies specified by the "copies" attribute and a 'number of\r
+ copies' instruction embedded in the document data, if any. This\r
+ difference allows the system administrator to control the lower and\r
+ upper bounds of both (1) the size of the document(s) with "job-k-\r
+ octets-supported" and "job-impressions-supported" and (2) the size of\r
+ the job with "job-media-sheets-supported".\r
+\r
+4.3.18 Job Progress Attributes\r
+\r
+ This sub-section defines job attributes that describe the progress of\r
+ the job. These attributes are intended to be counters. That is, the\r
+ value for a job that has not started processing MUST be 0. When the\r
+ job's "job-state" is 'processing' or 'processing-stopped', this value\r
+ is intended to contain the amount of the job that has been processed\r
+ to the time at which the attributes are requested. When the job\r
+ enters the 'completed', 'canceled', or 'aborted' states, these values\r
+ are the final values for the job.\r
+\r
+4.3.18.1 job-k-octets-processed (integer(0:MAX))\r
+\r
+ This attribute specifies the total number of octets processed in K\r
+ octets, i.e., in units of 1024 octets so far. The value MUST be\r
+ rounded up, so that a job between 1 and 1024 octets inclusive MUST be\r
+ indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc.\r
+\r
+ For implementations where multiple copies are produced by the\r
+ interpreter with only a single pass over the data, the final value\r
+ MUST be equal to the value of the "job-k-octets" attribute. For\r
+ implementations where multiple copies are produced by the interpreter\r
+ by processing the data for each copy, the final value MUST be a\r
+ multiple of the value of the "job-k-octets" attribute.\r
+\r
+4.3.18.2 job-impressions-completed (integer(0:MAX))\r
+\r
+ This job attribute specifies the number of impressions completed for\r
+ the job so far. For printing devices, the impressions completed\r
+ includes interpreting, marking, and stacking the output.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 123]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.3.18.3 job-media-sheets-completed (integer(0:MAX))\r
+\r
+ This job attribute specifies the media-sheets completed marking and\r
+ stacking for the entire job so far whether those sheets have been\r
+ processed on one side or on both.\r
+\r
+4.3.19 attributes-charset (charset)\r
+\r
+ This REQUIRED attribute is populated using the value in the client\r
+ supplied "attributes-charset" attribute in the create request. It\r
+ identifies the charset (coded character set and encoding method) used\r
+ by any Job attributes with attribute syntax 'text' and 'name' that\r
+ were supplied by the client in the create request. See Section 3.1.4\r
+ for a complete description of the "attributes-charset" operation\r
+ attribute.\r
+\r
+ This attribute does not indicate the charset in which the 'text' and\r
+ 'name' values are stored internally in the Job object. The internal\r
+ charset is implementation-defined. The IPP object MUST convert from\r
+ whatever the internal charset is to that being requested in an\r
+ operation as specified in Section 3.1.4.\r
+\r
+4.3.20 attributes-natural-language (naturalLanguage)\r
+\r
+ This REQUIRED attribute is populated using the value in the client\r
+ supplied "attributes-natural-language" attribute in the create\r
+ request. It identifies the natural language used for any Job\r
+ attributes with attribute syntax 'text' and 'name' that were supplied\r
+ by the client in the create request. See Section 3.1.4 for a\r
+ complete description of the "attributes-natural-language" operation\r
+ attribute. See Sections 4.1.1.2 and 4.1.2.2 for how a Natural\r
+ Language Override may be supplied explicitly for each 'text' and\r
+ 'name' attribute value that differs from the value identified by the\r
+ "attributes-natural-language" attribute.\r
+\r
+4.4 Printer Description Attributes\r
+\r
+ These attributes form the attribute group called "printer-\r
+ description". The following table summarizes these attributes, their\r
+ syntax, and whether or not they are REQUIRED for a Printer object to\r
+ support. If they are not indicated as REQUIRED, they are OPTIONAL.\r
+ The maximum size in octets for 'text' and 'name' attributes is\r
+ indicated in parenthesizes.\r
+\r
+ Note: How these attributes are set by an Administrator is outside the\r
+ scope of this IPP/1.1 document.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 124]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ +----------------------------+---------------------------+-----------+\r
+ | Attribute | Syntax | REQUIRED? |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-uri-supported | 1setOf uri | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | uri-security-supported | 1setOf type2 keyword | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | uri-authentication- | 1setOf type2 keyword | REQUIRED |\r
+ | supported | | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-name | name (127) | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-location | text (127) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-info | text (127) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-more-info | uri | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-driver-installer | uri | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-make-and-model | text (127) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-more-info- | uri | |\r
+ | manufacturer | | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-state | type1 enum | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-state-reasons | 1setOf type2 keyword | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-state-message | text (MAX) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | ipp-versions-supported | 1setOf type2 keyword | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | operations-supported | 1setOf type2 enum | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | multiple-document-jobs- | boolean | |\r
+ | supported | | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | charset-configured | charset | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | charset-supported | 1setOf charset | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | natural-language-configured| naturalLanguage | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | generated-natural-language-| 1setOf naturalLanguage | REQUIRED |\r
+ | supported | | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | document-format-default | mimeMediaType | REQUIRED |\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 125]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ +----------------------------+---------------------------+-----------+\r
+ | document-format-supported | 1setOf mimeMediaType | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-is-accepting-jobs | boolean | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | queued-job-count | integer (0:MAX) | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-message-from- | text (127) | |\r
+ | operator | | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | color-supported | boolean | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | reference-uri-schemes- | 1setOf uriScheme | |\r
+ | supported | | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | pdl-override-supported | type2 keyword | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-up-time | integer (1:MAX) | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | printer-current-time | dateTime | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | multiple-operation-time-out| integer (1:MAX) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | compression-supported | 1setOf type3 keyword | REQUIRED |\r
+ +----------------------------+---------------------------+-----------+\r
+ | job-k-octets-supported | rangeOfInteger (0:MAX) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | job-impressions-supported | rangeOfInteger (0:MAX) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | job-media-sheets-supported | rangeOfInteger (0:MAX) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | pages-per-minute | integer(0:MAX) | |\r
+ +----------------------------+---------------------------+-----------+\r
+ | pages-per-minute-color | integer(0:MAX) | |\r
+ +----------------------------+---------------------------+-----------+\r
+\r
+4.4.1 printer-uri-supported (1setOf uri)\r
+\r
+ This REQUIRED Printer attribute contains at least one URI for the\r
+ Printer object. It OPTIONALLY contains more than one URI for the\r
+ Printer object. An administrator determines a Printer object's\r
+ URI(s) and configures this attribute to contain those URIs by some\r
+ means outside the scope of this IPP/1.1 document. The precise format\r
+ of this URI is implementation dependent and depends on the protocol.\r
+ See the next two sections for a description of the "uri-security-\r
+ supported" and "uri-authentication-supported" attributes, both of\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 126]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ which are the REQUIRED companion attributes to this "printer-uri-\r
+ supported" attribute. See section 2.4 on Printer object identity and\r
+ section 8.2 on security and URIs for more information.\r
+\r
+4.4.2 uri-authentication-supported (1setOf type2 keyword)\r
+\r
+ This REQUIRED Printer attribute MUST have the same cardinality\r
+ (contain the same number of values) as the "printer-uri-supported"\r
+ attribute. This attribute identifies the Client Authentication\r
+ mechanism associated with each URI listed in the "printer-uri-\r
+ supported" attribute. The Printer object uses the specified mechanism\r
+ to identify the authenticated user (see section 8.3). The "i th"\r
+ value in "uri-authentication-supported" corresponds to the "i th"\r
+ value in "printer-uri-supported" and it describes the authentication\r
+ mechanisms used by the Printer when accessed via that URI. See\r
+ [RFC2910] for more details on Client Authentication.\r
+\r
+ The following standard keyword values are defined:\r
+\r
+ 'none': There is no authentication mechanism associated with the\r
+ URI. The Printer object assumes that the authenticated user is\r
+ "anonymous".\r
+ 'requesting-user-name': When a client performs an operation whose\r
+ target is the associated URI, the Printer object assumes that\r
+ the authenticated user is specified by the "requesting-user-\r
+ name" Operation attribute (see section 8.3). If the\r
+ "requesting-user-name" attribute is absent in a request, the\r
+ Printer object assumes that the authenticated user is\r
+ "anonymous".\r
+ 'basic': When a client performs an operation whose target is the\r
+ associated URI, the Printer object challenges the client with\r
+ HTTP basic authentication [RFC2617]. The Printer object assumes\r
+ that the authenticated user is the name received via the basic\r
+ authentication mechanism.\r
+ 'digest': When a client performs an operation whose target is the\r
+ associated URI, the Printer object challenges the client with\r
+ HTTP digest authentication [RFC2617]. The Printer object\r
+ assumes that the authenticated user is the name received via\r
+ the digest authentication mechanism.\r
+ 'certificate': When a client performs an operation whose target is\r
+ the associated URI, the Printer object expects the client to\r
+ provide a certificate. The Printer object assumes that the\r
+ authenticated user is the textual name contained within the\r
+ certificate.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 127]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.4.3 uri-security-supported (1setOf type2 keyword)\r
+\r
+ This REQUIRED Printer attribute MUST have the same cardinality\r
+ (contain the same number of values) as the "printer-uri-supported"\r
+ attribute. This attribute identifies the security mechanisms used\r
+ for each URI listed in the "printer-uri-supported" attribute. The "i\r
+ th" value in "uri-security-supported" corresponds to the "i th" value\r
+ in "printer-uri-supported" and it describes the security mechanisms\r
+ used for accessing the Printer object via that URI. See [RFC2910]\r
+ for more details on security mechanisms.\r
+\r
+ The following standard keyword values are defined:\r
+\r
+ 'none': There are no secure communication channel protocols in use\r
+ for the given URI.\r
+ 'ssl3': SSL3 [SSL] is the secure communications channel protocol\r
+ in use for the given URI.\r
+ 'tls': TLS [RFC2246] is the secure communications channel\r
+ protocol in use for the given URI.\r
+\r
+ This attribute is orthogonal to the definition of a Client\r
+ Authentication mechanism. Specifically, 'none' does not exclude\r
+ Client Authentication. See section 4.4.2.\r
+\r
+ Consider the following example. For a single Printer object, an\r
+ administrator configures the "printer-uri-supported", "uri-\r
+ authentication-supported" and "uri-security-supported" attributes as\r
+ follows:\r
+\r
+ "printer-uri-supported": 'xxx://acme.com/open-use-printer',\r
+ 'xxx://acme.com/restricted-use-printer',\r
+ 'xxx://acme.com/private-printer'\r
+ "uri-authentication-supported": 'none', 'digest', 'basic'\r
+ "uri-security-supported": 'none', 'none', 'tls'\r
+\r
+ Note: 'xxx' is not a valid scheme. See the IPP/1.1 "Transport and\r
+ Encoding" document [RFC2910] for the actual URI schemes to be used in\r
+ object target attributes.\r
+\r
+ In this case, one Printer object has three URIs.\r
+\r
+ - For the first URI, 'xxx://acme.com/open-use-printer', the value\r
+ 'none' in "uri-security-supported" indicates that there is no\r
+ secure channel protocol configured to run under HTTP. The value\r
+ of 'none' in "uri-authentication-supported" indicates that all\r
+ users are 'anonymous'. There will be no challenge and the\r
+ Printer will ignore "requesting-user-name".\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 128]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - For the second URI, 'xxx://acme.com/restricted-use-printer', the\r
+ value 'none' in "uri-security-supported" indicates that there is\r
+ no secure channel protocol configured to run under HTTP. The\r
+ value of 'digest' in "uri-authentication-supported" indicates\r
+ that the Printer will issue a challenge and that the Printer\r
+ will use the name supplied by the digest mechanism to determine\r
+ the authenticated user (see section 8.3).\r
+ - For the third URI, 'xxx://acme.com/private-printer', the value\r
+ 'tls' in "uri-security-supported" indicates that TLS is being\r
+ used to secure the channel. The client SHOULD be prepared to\r
+ use TLS framing to negotiate an acceptable ciphersuite to use\r
+ while communicating with the Printer object. In this case, the\r
+ name implies the use of a secure communications channel, but the\r
+ fact is made explicit by the presence of the 'tls' value in\r
+ "uri-security-supported". The client does not need to resort to\r
+ understanding which security it must use by following naming\r
+ conventions or by parsing the URI to determine which security\r
+ mechanisms are implied. The value of 'basic' in "uri-\r
+ authentication-supported" indicates that the Printer will issue\r
+ a challenge and that the Printer will use the name supplied by\r
+ the digest mechanism to determine the authenticated user (see\r
+ section 8.3). Because this challenge occurs in a tls session,\r
+ the channel is secure.\r
+\r
+ It is expected that many IPP Printer objects will be configured to\r
+ support only one channel (either configured to use TLS access or not)\r
+ and only one authentication mechanism. Such Printer objects only have\r
+ one URI listed in the "printer-uri-supported" attribute. No matter\r
+ the configuration of the Printer object (whether it has only one URI\r
+ or more than one URI), a client MUST supply only one URI in the\r
+ target "printer-uri" operation attribute.\r
+\r
+4.4.4 printer-name (name(127))\r
+\r
+ This REQUIRED Printer attribute contains the name of the Printer\r
+ object. It is a name that is more end-user friendly than a URI. An\r
+ administrator determines a printer's name and sets this attribute to\r
+ that name. This name may be the last part of the printer's URI or it\r
+ may be unrelated. In non-US-English locales, a name may contain\r
+ characters that are not allowed in a URI.\r
+\r
+4.4.5 printer-location (text(127))\r
+\r
+ This Printer attribute identifies the location of the device. This\r
+ could include things like: "in Room 123A, second floor of building\r
+ XYZ".\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 129]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.4.6 printer-info (text(127))\r
+\r
+ This Printer attribute identifies the descriptive information about\r
+ this Printer object. This could include things like: "This printer\r
+ can be used for printing color transparencies for HR presentations",\r
+ or "Out of courtesy for others, please print only small (1-5 page)\r
+ jobs at this printer", or even "This printer is going away on July 1,\r
+ 1997, please find a new printer".\r
+\r
+4.4.7 printer-more-info (uri)\r
+\r
+ This Printer attribute contains a URI used to obtain more information\r
+ about this specific Printer object. For example, this could be an\r
+ HTTP type URI referencing an HTML page accessible to a Web Browser.\r
+ The information obtained from this URI is intended for end user\r
+ consumption. Features outside the scope of IPP can be accessed from\r
+ this URI. The information is intended to be specific to this printer\r
+ instance and site specific services (e.g. job pricing, services\r
+ offered, end user assistance). The device manufacturer may initially\r
+ populate this attribute.\r
+\r
+4.4.8 printer-driver-installer (uri)\r
+\r
+ This Printer attribute contains a URI to use to locate the driver\r
+ installer for this Printer object. This attribute is intended for\r
+ consumption by automata. The mechanics of print driver installation\r
+ is outside the scope of this IPP/1.1 document. The device\r
+ manufacturer may initially populate this attribute.\r
+\r
+4.4.9 printer-make-and-model (text(127))\r
+\r
+ This Printer attribute identifies the make and model of the device.\r
+ The device manufacturer may initially populate this attribute.\r
+\r
+4.4.10 printer-more-info-manufacturer (uri)\r
+\r
+ This Printer attribute contains a URI used to obtain more information\r
+ about this type of device. The information obtained from this URI is\r
+ intended for end user consumption. Features outside the scope of IPP\r
+ can be accessed from this URI (e.g., latest firmware, upgrades, print\r
+ drivers, optional features available, details on color support). The\r
+ information is intended to be germane to this printer without regard\r
+ to site specific modifications or services. The device manufacturer\r
+ may initially populate this attribute.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 130]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.4.11 printer-state (type1 enum)\r
+\r
+ This REQUIRED Printer attribute identifies the current state of the\r
+ device. The "printer-state reasons" attribute augments the\r
+ "printer-state" attribute to give more detailed information about the\r
+ Printer in the given printer state.\r
+\r
+ A Printer object need only update this attribute before responding to\r
+ an operation which requests the attribute; the Printer object NEED\r
+ NOT update this attribute continually, since asynchronous event\r
+ notification is not part of IPP/1.1. A Printer NEED NOT implement\r
+ all values if they are not applicable to a given implementation.\r
+\r
+ The following standard enum values are defined:\r
+\r
+ Value Symbolic Name and Description\r
+\r
+ '3' 'idle': Indicates that new jobs can start processing without\r
+ waiting.\r
+ '4' 'processing': Indicates that jobs are processing; new jobs\r
+ will wait before processing.\r
+ '5' 'stopped': Indicates that no jobs can be processed and\r
+ intervention is required.\r
+\r
+ Values of "printer-state-reasons", such as 'spool-area-full' and\r
+ 'stopped-partly', MAY be used to provide further information.\r
+\r
+4.4.12 printer-state-reasons (1setOf type2 keyword)\r
+\r
+ This REQUIRED Printer attribute supplies additional detail about the\r
+ device's state. Some of the these value definitions indicate\r
+ conformance requirements; the rest are OPTIONAL.\r
+\r
+ Each keyword value MAY have a suffix to indicate its level of\r
+ severity. The three levels are: report (least severe), warning, and\r
+ error (most severe).\r
+\r
+ - '-report': This suffix indicates that the reason is a "report".\r
+ An implementation may choose to omit some or all reports. Some\r
+ reports specify finer granularity about the printer state;\r
+ others serve as a precursor to a warning. A report MUST contain\r
+ nothing that could affect the printed output.\r
+ - '-warning': This suffix indicates that the reason is a\r
+ "warning". An implementation may choose to omit some or all\r
+ warnings. Warnings serve as a precursor to an error. A warning\r
+ MUST contain nothing that prevents a job from completing, though\r
+ in some cases the output may be of lower quality.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 131]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - '-error': This suffix indicates that the reason is an "error".\r
+ An implementation MUST include all errors. If this attribute\r
+ contains one or more errors, printer MUST be in the stopped\r
+ state.\r
+\r
+ If the implementation does not add any one of the three suffixes, all\r
+ parties MUST assume that the reason is an "error".\r
+\r
+ If a Printer object controls more than one output device, each value\r
+ of this attribute MAY apply to one or more of the output devices. An\r
+ error on one output device that does not stop the Printer object as a\r
+ whole MAY appear as a warning in the Printer's "printer-state-reasons\r
+ attribute". If the "printer-state" for such a Printer has a value of\r
+ 'stopped', then there MUST be an error reason among the values in the\r
+ "printer-state-reasons" attribute.\r
+\r
+ The following standard keyword values are defined:\r
+\r
+ 'other': The device has detected an error other than one listed in\r
+ this document.\r
+ 'none': There are not reasons. This state reason is semantically\r
+ equivalent to "printer-state-reasons" without any value and\r
+ MUST be used, since the 1setOf attribute syntax requires at\r
+ least one value.\r
+ 'media-needed': A tray has run out of media.\r
+ 'media-jam': The device has a media jam.\r
+ 'moving-to-paused': Someone has paused the Printer object using\r
+ the Pause-Printer operation (see section 3.2.7) or other means,\r
+ but the device(s) are taking an appreciable time to stop.\r
+ Later, when all output has stopped, the "printer-state" becomes\r
+ 'stopped', and the 'paused' value replaces the 'moving-to-\r
+ paused' value in the "printer-state-reasons" attribute. This\r
+ value MUST be supported, if the Pause-Printer operation is\r
+ supported and the implementation takes significant time to\r
+ pause a device in certain circumstances.\r
+ 'paused': Someone has paused the Printer object using the Pause-\r
+ Printer operation (see section 3.2.7) or other means and the\r
+ Printer object's "printer-state" is 'stopped'. In this state,\r
+ a Printer MUST NOT produce printed output, but it MUST perform\r
+ other operations requested by a client. If a Printer had been\r
+ printing a job when the Printer was paused, the Printer MUST\r
+ resume printing that job when the Printer is no longer paused\r
+ and leave no evidence in the printed output of such a pause.\r
+ This value MUST be supported, if the Pause-Printer operation is\r
+ supported.\r
+ 'shutdown': Someone has removed a Printer object from service, and\r
+ the device may be powered down or physically removed. In this\r
+ state, a Printer object MUST NOT produce printed output, and\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 132]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ unless the Printer object is realized by a print server that is\r
+ still active, the Printer object MUST perform no other\r
+ operations requested by a client, including returning this\r
+ value. If a Printer object had been printing a job when it was\r
+ shutdown, the Printer NEED NOT resume printing that job when\r
+ the Printer is no longer shutdown. If the Printer resumes\r
+ printing such a job, it may leave evidence in the printed\r
+ output of such a shutdown, e.g. the part printed before the\r
+ shutdown may be printed a second time after the shutdown.\r
+ 'connecting-to-device': The Printer object has scheduled a job on\r
+ the output device and is in the process of connecting to a\r
+ shared network output device (and might not be able to actually\r
+ start printing the job for an arbitrarily long time depending\r
+ on the usage of the output device by other servers on the\r
+ network).\r
+ 'timed-out': The server was able to connect to the output device\r
+ (or is always connected), but was unable to get a response from\r
+ the output device.\r
+ 'stopping': The Printer object is in the process of stopping the\r
+ device and will be stopped in a while. When the device is\r
+ stopped, the Printer object will change the Printer object's\r
+ state to 'stopped'. The 'stopping-warning' reason is never an\r
+ error, even for a Printer with a single output device. When an\r
+ output-device ceases accepting jobs, the Printer will have this\r
+ reason while the output device completes printing.\r
+ 'stopped-partly': When a Printer object controls more than one\r
+ output device, this reason indicates that one or more output\r
+ devices are stopped. If the reason is a report, fewer than\r
+ half of the output devices are stopped. If the reason is a\r
+ warning, fewer than all of the output devices are stopped.\r
+ 'toner-low': The device is low on toner.\r
+ 'toner-empty': The device is out of toner.\r
+ 'spool-area-full': The limit of persistent storage allocated for\r
+ spooling has been reached. The Printer is temporarily unable\r
+ to accept more jobs. The Printer will remove this value when\r
+ it is able to accept more jobs. This value SHOULD be used by a\r
+ non-spooling Printer that only accepts one or a small number\r
+ jobs at a time or a spooling Printer that has filled the spool\r
+ space.\r
+ 'cover-open': One or more covers on the device are open.\r
+ 'interlock-open': One or more interlock devices on the printer are\r
+ unlocked.\r
+ 'door-open': One or more doors on the device are open.\r
+ 'input-tray-missing': One or more input trays are not in the\r
+ device.\r
+ 'media-low': At least one input tray is low on media.\r
+ 'media-empty': At least one input tray is empty.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 133]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'output-tray-missing': One or more output trays are not in the\r
+ device\r
+ 'output-area-almost-full': One or more output area is almost full\r
+ (e.g. tray, stacker, collator).\r
+ 'output-area-full': One or more output area is full. (e.g. tray,\r
+ stacker, collator)\r
+ 'marker-supply-low': The device is low on at least one marker\r
+ supply. (e.g. toner, ink, ribbon)\r
+ 'marker-supply-empty: The device is out of at least one marker\r
+ supply. (e.g. toner, ink, ribbon)\r
+ 'marker-waste-almost-full': The device marker supply waste\r
+ receptacle is almost full.\r
+ 'marker-waste-full': The device marker supply waste receptacle is\r
+ full.\r
+ 'fuser-over-temp': The fuser temperature is above normal.\r
+ 'fuser-under-temp': The fuser temperature is below normal.\r
+ 'opc-near-eol': The optical photo conductor is near end of life.\r
+ 'opc-life-over': The optical photo conductor is no longer\r
+ functioning.\r
+ 'developer-low': The device is low on developer.\r
+ 'developer-empty: The device is out of developer.\r
+ 'interpreter-resource-unavailable': An interpreter resource is\r
+ unavailable (i.e. font, form)\r
+\r
+4.4.13 printer-state-message (text(MAX))\r
+\r
+ This Printer attribute specifies information about the "printer-\r
+ state" and "printer-state-reasons" attributes in human readable text.\r
+ If the Printer object supports this attribute, the Printer object\r
+ MUST be able to generate this message in any of the natural languages\r
+ identified by the Printer's "generated-natural-language-supported"\r
+ attribute (see the "attributes-natural-language" operation attribute\r
+ specified in Section 3.1.4.1).\r
+\r
+4.4.14 ipp-versions-supported (1setOf type2 keyword)\r
+\r
+ This REQUIRED attribute identifies the IPP protocol version(s) that\r
+ this Printer supports, including major and minor versions, i.e., the\r
+ version numbers for which this Printer implementation meets the\r
+ conformance requirements. For version number validation, the Printer\r
+ matches the (two-octet binary) "version-number" parameter supplied by\r
+ the client in each request (see sections 3.1.1 and 3.1.8) with the\r
+ (US-ASCII) keyword values of this attribute.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 134]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The following standard keyword values are defined:\r
+\r
+ '1.0': Meets the conformance requirement of IPP version 1.0 as\r
+ specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565]\r
+ including any extensions registered according to Section 6 and\r
+ any extension defined in this version or any future version of\r
+ the IPP "Model and Semantics" document or the IPP "Encoding and\r
+ Transport" document following the rules, if any, when the\r
+ "version-number" parameter is '1.0'.\r
+ '1.1': Meets the conformance requirement of IPP version 1.1 as\r
+ specified in this document and [RFC2910] including any\r
+ extensions registered according to Section 6 and any extension\r
+ defined in any future versions of the IPP "Model and Semantics"\r
+ document or the IPP Encoding and Transport document following\r
+ the rules, if any, when the "version-number" parameter is\r
+ '1.1'.\r
+\r
+4.4.15 operations-supported (1setOf type2 enum)\r
+\r
+ This REQUIRED Printer attribute specifies the set of supported\r
+ operations for this Printer object and contained Job objects.\r
+\r
+ This attribute is encoded as any other enum attribute syntax\r
+ according to [RFC2910] as 32-bits. However, all 32-bit enum values\r
+ for this attribute MUST NOT exceed 0x00008FFF, since these same\r
+ values are also passed in two octets in the "operation-id" parameter\r
+ (see section 3.1.1) in each Protocol request with the two high order\r
+ octets omitted in order to indicate the operation being performed\r
+ [RFC2910].\r
+\r
+ The following standard enum and "operation-id" (see section 3.1.2)\r
+ values are defined:\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 135]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Value Operation Name\r
+ ----------------- -------------------------------------\r
+\r
+ 0x0000 reserved, not used\r
+ 0x0001 reserved, not used\r
+ 0x0002 Print-Job\r
+ 0x0003 Print-URI\r
+ 0x0004 Validate-Job\r
+ 0x0005 Create-Job\r
+ 0x0006 Send-Document\r
+ 0x0007 Send-URI\r
+ 0x0008 Cancel-Job\r
+ 0x0009 Get-Job-Attributes\r
+ 0x000A Get-Jobs\r
+ 0x000B Get-Printer-Attributes\r
+ 0x000C Hold-Job\r
+ 0x000D Release-Job\r
+ 0x000E Restart-Job\r
+ 0x000F reserved for a future operation\r
+ 0x0010 Pause-Printer\r
+ 0x0011 Resume-Printer\r
+ 0x0012 Purge-Jobs\r
+ 0x0013-0x3FFF reserved for future IETF standards track\r
+ operations (see section 6.4)\r
+ 0x4000-0x8FFF reserved for vendor extensions (see section 6.4)\r
+\r
+4.4.16 multiple-document-jobs-supported (boolean)\r
+\r
+ This Printer attribute indicates whether or not the Printer supports\r
+ more than one document per job, i.e., more than one Send-Document or\r
+ Send-Data operation with document data. If the Printer supports the\r
+ Create-Job and Send-Document operations (see section 3.2.4 and\r
+ 3.3.1), it MUST support this attribute.\r
+\r
+4.4.17 charset-configured (charset)\r
+\r
+ This REQUIRED Printer attribute identifies the charset that the\r
+ Printer object has been configured to represent 'text' and 'name'\r
+ Printer attributes that are set by the operator, system\r
+ administrator, or manufacturer, i.e., for "printer-name" (name),\r
+ "printer-location" (text), "printer-info" (text), and "printer-make-\r
+ and-model" (text). Therefore, the value of the Printer object's\r
+ "charset-configured" attribute MUST also be among the values of the\r
+ Printer object's "charset-supported" attribute.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 136]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.4.18 charset-supported (1setOf charset)\r
+\r
+ This REQUIRED Printer attribute identifies the set of charsets that\r
+ the Printer and contained Job objects support in attributes with\r
+ attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST\r
+ be present, since IPP objects MUST support the UTF-8 [RFC2279]\r
+ charset. If a Printer object supports a charset, it means that for\r
+ all attributes of syntax 'text' and 'name' the IPP object MUST (1)\r
+ accept the charset in requests and return the charset in responses as\r
+ needed.\r
+\r
+ If more charsets than UTF-8 are supported, the IPP object MUST\r
+ perform charset conversion between the charsets as described in\r
+ Section 3.1.4.2.\r
+\r
+4.4.19 natural-language-configured (naturalLanguage)\r
+\r
+ This REQUIRED Printer attribute identifies the natural language that\r
+ the Printer object has been configured to represent 'text' and 'name'\r
+ Printer attributes that are set by the operator, system\r
+ administrator, or manufacturer, i.e., for "printer-name" (name),\r
+ "printer-location" (text), "printer-info" (text), and "printer-make-\r
+ and-model" (text). When returning these Printer attributes, the\r
+ Printer object MAY return them in the configured natural language\r
+ specified by this attribute, instead of the natural language\r
+ requested by the client in the "attributes-natural-language"\r
+ operation attribute. See Section 3.1.4.1 for the specification of\r
+ the OPTIONAL multiple natural language support. Therefore, the value\r
+ of the Printer object's "natural-language-configured" attribute MUST\r
+ also be among the values of the Printer object's "generated-natural-\r
+ language-supported" attribute.\r
+\r
+4.4.20 generated-natural-language-supported (1setOf naturalLanguage)\r
+\r
+ This REQUIRED Printer attribute identifies the natural language(s)\r
+ that the Printer object and contained Job objects support in\r
+ attributes with attribute syntax 'text' and 'name'. The natural\r
+ language(s) supported depends on implementation and/or configuration.\r
+ Unlike charsets, IPP objects MUST accept requests with any natural\r
+ language or any Natural Language Override whether the natural\r
+ language is supported or not.\r
+\r
+ If a Printer object supports a natural language, it means that for\r
+ any of the attributes for which the Printer or Job object generates\r
+ messages, i.e., for the "job-state-message" and "printer-state-\r
+ message" attributes and Operation Messages (see Section 3.1.5) in\r
+ operation responses, the Printer and Job objects MUST be able to\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 137]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ generate messages in any of the Printer's supported natural\r
+ languages. See section 3.1.4 for the definition of 'text' and 'name'\r
+ attributes in operation requests and responses.\r
+\r
+ Note: A Printer object that supports multiple natural languages,\r
+ often has separate catalogs of messages, one for each natural\r
+ language supported.\r
+\r
+4.4.21 document-format-default (mimeMediaType)\r
+\r
+ This REQUIRED Printer attribute identifies the document format that\r
+ the Printer object has been configured to assume if the client does\r
+ not supply a "document-format" operation attribute in any of the\r
+ operation requests that supply document data. The standard values\r
+ for this attribute are Internet Media types (sometimes called MIME\r
+ types). For further details see the description of the\r
+ 'mimeMediaType' attribute syntax in Section 4.1.9.\r
+\r
+4.4.22 document-format-supported (1setOf mimeMediaType)\r
+\r
+ This REQUIRED Printer attribute identifies the set of document\r
+ formats that the Printer object and contained Job objects can\r
+ support. For further details see the description of the\r
+ 'mimeMediaType' attribute syntax in Section 4.1.9.\r
+\r
+4.4.23 printer-is-accepting-jobs (boolean)\r
+\r
+ This REQUIRED Printer attribute indicates whether the printer is\r
+ currently able to accept jobs, i.e., is accepting Print-Job, Print-\r
+ URI, and Create-Job requests. If the value is 'true', the printer is\r
+ accepting jobs. If the value is 'false', the Printer object is\r
+ currently rejecting any jobs submitted to it. In this case, the\r
+ Printer object returns the 'server-error-not-accepting-jobs' status\r
+ code.\r
+\r
+ This value is independent of the "printer-state" and "printer-state-\r
+ reasons" attributes because its value does not affect the current\r
+ job; rather it affects future jobs. This attribute, when 'false',\r
+ causes the Printer to reject jobs even when the "printer-state" is\r
+ 'idle' or, when 'true', causes the Printer object to accepts jobs\r
+ even when the "printer-state" is 'stopped'.\r
+\r
+4.4.24 queued-job-count (integer(0:MAX))\r
+\r
+ This REQUIRED Printer attribute contains a count of the number of\r
+ jobs that are either 'pending', 'processing', 'pending-held', or\r
+ 'processing-stopped' and is set by the Printer object.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 138]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+4.4.25 printer-message-from-operator (text(127))\r
+\r
+ This Printer attribute provides a message from an operator, system\r
+ administrator or "intelligent" process to indicate to the end user\r
+ information or status of the printer, such as why it is unavailable\r
+ or when it is expected to be available.\r
+\r
+4.4.26 color-supported (boolean)\r
+\r
+ This Printer attribute identifies whether the device is capable of\r
+ any type of color printing at all, including highlight color. All\r
+ document instructions having to do with color are embedded within the\r
+ document PDL (none are external IPP attributes in IPP/1.1).\r
+\r
+ Note: end-users are able to determine the nature and details of the\r
+ color support by querying the "printer-more-info-manufacturer"\r
+ Printer attribute.\r
+\r
+4.4.27 reference-uri-schemes-supported (1setOf uriScheme)\r
+\r
+ This Printer attribute specifies which URI schemes are supported for\r
+ use in the "document-uri" operation attribute of the Print-URI or\r
+ Send-URI operation. If a Printer object supports these optional\r
+ operations, it MUST support the "reference-uri-schemes-supported"\r
+ Printer attribute with at least the following schemed URI value:\r
+\r
+ 'ftp': The Printer object will use an FTP 'get' operation as\r
+ defined in RFC 2228 [RFC2228] using FTP URLs as defined by\r
+ [RFC2396] and [RFC2316].\r
+\r
+ The Printer object MAY OPTIONALLY support other URI schemes (see\r
+ section 4.1.6).\r
+\r
+4.4.28 pdl-override-supported (type2 keyword)\r
+\r
+ This REQUIRED Printer attribute expresses the ability for a\r
+ particular Printer implementation to either attempt to override\r
+ document data instructions with IPP attributes or not.\r
+\r
+ This attribute takes on the following keyword values:\r
+\r
+ - 'attempted': This value indicates that the Printer object\r
+ attempts to make the IPP attribute values take precedence over\r
+ embedded instructions in the document data, however there is no\r
+ guarantee.\r
+ - 'not-attempted': This value indicates that the Printer object\r
+ makes no attempt to make the IPP attribute values take\r
+ precedence over embedded instructions in the document data.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 139]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Section 15 contains a full description of how this attribute\r
+ interacts with and affects other IPP attributes, especially the\r
+ "ipp-attribute-fidelity" attribute.\r
+\r
+4.4.29 printer-up-time (integer(1:MAX))\r
+\r
+ This REQUIRED Printer attribute indicates the amount of time (in\r
+ seconds) that this Printer instance has been up and running. The\r
+ value is a monotonically increasing value starting from 1 when the\r
+ Printer object is started-up (initialized, booted, etc.). This value\r
+ is used to populate the Event Time Job Description Job attributes\r
+ "time-at-creation", "time-at-processing", and "time-at-completed"\r
+ (see section 4.3.14).\r
+\r
+ If the Printer object goes down at some value 'n', and comes back up,\r
+ the implementation MAY:\r
+\r
+ 1. Know how long it has been down, and resume at some value\r
+ greater than 'n', or\r
+ 2. Restart from 1.\r
+\r
+ In other words, if the device or devices that the Printer object is\r
+ representing are restarted or power cycled, the Printer object MAY\r
+ continue counting this value or MAY reset this value to 1 depending\r
+ on implementation. However, if the Printer object software ceases\r
+ running, and restarts without knowing the last value for "printer-\r
+ up-time", the implementation MUST reset this value to 1. If this\r
+ value is reset and the Printer has persistent jobs, the Printer MUST\r
+ reset the "time-at-xxx(integer) Event Time Job Description attributes\r
+ according to Section 4.3.14. An implementation MAY use both\r
+ implementation alternatives, depending on warm versus cold start,\r
+ respectively.\r
+\r
+4.4.30 printer-current-time (dateTime)\r
+\r
+ This Printer attribute indicates the current date and time. This\r
+ value is used to populate the Event Time Job Description attributes:\r
+ "date-time-at-creation", "date-time-at-processing", and "date-time-\r
+ at-completed" (see Section 4.3.14).\r
+\r
+ The date and time is obtained on a "best efforts basis" and does not\r
+ have to be that precise in order to work in practice. A Printer\r
+ implementation sets the value of this attribute by obtaining the date\r
+ and time via some implementation-dependent means, such as getting the\r
+ value from a network time server, initialization at time of\r
+ manufacture, or setting by an administrator. See [IPP-IIG] for\r
+ examples. If an implementation supports this attribute and the\r
+ implementation knows that it has not yet been set, then the\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 140]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ implementation MUST return the value of this attribute using the\r
+ out-of-band 'no-value' meaning not configured. See the beginning of\r
+ section 4.1.\r
+\r
+ The time zone of this attribute NEED NOT be the time zone used by\r
+ people located near the Printer object or device. The client MUST\r
+ NOT expect that the time zone of any received 'dateTime' value to be\r
+ in the time zone of the client or in the time zone of the people\r
+ located near the printer.\r
+\r
+ The client SHOULD display any dateTime attributes to the user in\r
+ client local time by converting the 'dateTime' value returned by the\r
+ server to the time zone of the client, rather than using the time\r
+ zone returned by the Printer in attributes that use the 'dateTime'\r
+ attribute syntax.\r
+\r
+4.4.31 multiple-operation-time-out (integer(1:MAX))\r
+\r
+ This Printer attributes identifies the minimum time (in seconds) that\r
+ the Printer object waits for additional Send-Document or Send-URI\r
+ operations to follow a still-open Job object before taking any\r
+ recovery actions, such as the ones indicated in section 3.3.1. If\r
+ the Printer object supports the Create-Job and Send-Document\r
+ operations (see section 3.2.4 and 3.3.1), it MUST support this\r
+ attribute.\r
+\r
+ It is RECOMMENDED that vendors supply a value for this attribute that\r
+ is between 60 and 240 seconds. An implementation MAY allow a system\r
+ administrator to set this attribute (by means outside this IPP/1.1\r
+ document). If so, the system administrator MAY be able to set values\r
+ outside this range.\r
+\r
+4.4.32 compression-supported (1setOf type3 keyword)\r
+\r
+ This REQUIRED Printer attribute identifies the set of supported\r
+ compression algorithms for document data. Compression only applies\r
+ to the document data; compression does not apply to the encoding of\r
+ the IPP operation itself. The supported values are used to validate\r
+ the client supplied "compression" operation attributes in Print-Job,\r
+ Send-Document, and Send-URI requests.\r
+\r
+ Standard keyword values are :\r
+\r
+ 'none': no compression is used.\r
+ 'deflate': ZIP public domain inflate/deflate) compression technology\r
+ in RFC 1951 [RFC1951]\r
+ 'gzip' GNU zip compression technology described in RFC 1952\r
+ [RFC1952].\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 141]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'compress': UNIX compression technology in RFC 1977 [RFC1977]\r
+\r
+4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX))\r
+\r
+ This Printer attribute specifies the upper and lower bounds of total\r
+ sizes of jobs in K octets, i.e., in units of 1024 octets. The\r
+ supported values are used to validate the client supplied "job-k-\r
+ octets" operation attributes in create requests. The corresponding\r
+ job description attribute "job-k-octets" is defined in section\r
+ 4.3.17.1.\r
+\r
+4.4.34 job-impressions-supported (rangeOfInteger(0:MAX))\r
+\r
+ This Printer attribute specifies the upper and lower bounds for the\r
+ number of impressions per job. The supported values are used to\r
+ validate the client supplied "job-impressions" operation attributes\r
+ in create requests. The corresponding job description attribute\r
+ "job-impressions" is defined in section 4.3.17.2.\r
+\r
+4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX))\r
+\r
+ This Printer attribute specifies the upper and lower bounds for the\r
+ number of media sheets per job. The supported values are used to\r
+ validate the client supplied "job-media-sheets" operation attributes\r
+ in create requests. The corresponding Job attribute "job-media-\r
+ sheets" is defined in section 4.3.17.3.\r
+\r
+4.4.36 pages-per-minute (integer(0:MAX))\r
+\r
+ This Printer attributes specifies the nominal number of pages per\r
+ minute to the nearest whole number which may be generated by this\r
+ printer (e.g., simplex, black-and-white). This attribute is\r
+ informative, not a service guarantee. Generally, it is the value\r
+ used in the marketing literature to describe the device.\r
+\r
+ A value of 0 indicates a device that takes more than two minutes to\r
+ process a page.\r
+\r
+4.4.37 pages-per-minute-color (integer(0:MAX))\r
+\r
+ This Printer attributes specifies the nominal number of pages per\r
+ minute to the nearest whole number which may be generated by this\r
+ printer when printing color (e.g., simplex, color). For purposes of\r
+ this attribute, "color" means the same as for the "color-supported"\r
+ attribute, namely, the device is capable of any type of color\r
+ printing at all, including highlight color. This attribute is\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 142]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ informative, not a service guarantee. Generally, it is the value\r
+ used in the marketing literature to describe the color capabilities\r
+ of this device.\r
+\r
+ A value of 0 indicates a device that takes more than two minutes to\r
+ process a page.\r
+\r
+ If a color device has several color modes, it MAY use the pages-per-\r
+ minute value for this attribute that corresponds to the mode that\r
+ produces the highest number.\r
+\r
+ Black and white only printers MUST NOT support this attribute. If\r
+ this attribute is present, then the "color-supported" Printer\r
+ description attribute MUST be present and have a 'true' value.\r
+\r
+ The values of these two attributes returned by the Get-Printer-\r
+ Attributes operation MAY be affected by the "document-format"\r
+ attribute supplied by the client in the Get-Printer-Attributes\r
+ request. In other words, the implementation MAY have different\r
+ speeds depending on the document format being processed. See section\r
+ 3.2.5.1 Get-Printer-Attributes.\r
+\r
+5. Conformance\r
+\r
+ This section describes conformance issues and requirements. This\r
+ document introduces model entities such as objects, operations,\r
+ attributes, attribute syntaxes, and attribute values. These\r
+ conformance sections describe the conformance requirements which\r
+ apply to these model entities.\r
+\r
+5.1 Client Conformance Requirements\r
+\r
+ This section describes the conformance requirements for a client (see\r
+ section 2.1), whether it be:\r
+\r
+ 1. contained within software controlled by an end user, e.g.\r
+ activated by the "Print" menu item in an application that sends\r
+ IPP requests or\r
+\r
+ 2. the print server component that sends IPP requests to either an\r
+ output device or another "downstream" print server.\r
+\r
+ A conforming client MUST support all REQUIRED operations as defined\r
+ in this document. For each attribute included in an operation\r
+ request, a conforming client MUST supply a value whose type and value\r
+ syntax conforms to the requirements of the Model document as\r
+ specified in Sections 3 and 4. A conforming client MAY supply any\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 143]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ IETF standards track extensions and/or vendor extensions in an\r
+ operation request, as long as the extensions meet the requirements in\r
+ Section 6.\r
+\r
+ Otherwise, there are no conformance requirements placed on the user\r
+ interfaces provided by IPP clients or their applications. For\r
+ example, one application might not allow an end user to submit\r
+ multiple documents per job, while another does. One application\r
+ might first query a Printer object in order to supply a graphical\r
+ user interface (GUI) dialogue box with supported and default values\r
+ whereas a different implementation might not.\r
+\r
+ When sending a request, an IPP client NEED NOT supply any attributes\r
+ that are indicated as OPTIONALLY supplied by the client.\r
+\r
+ A client MUST be able to accept any of the attribute syntaxes defined\r
+ in Section 4.1, including their full range, that may be returned to\r
+ it in a response from a Printer object. In particular for each\r
+ attribute that the client supports whose attribute syntax is 'text',\r
+ the client MUST accept and process both the 'textWithoutLanguage' and\r
+ 'textWithLanguage' forms. Similarly, for each attribute that the\r
+ client supports whose attribute syntax is 'name', the client MUST\r
+ accept and process both the 'nameWithoutLanguage' and\r
+ 'nameWithLanguage' forms. For presentation purposes, truncation of\r
+ long attribute values is not recommended. A recommended approach\r
+ would be for the client implementation to allow the user to scroll\r
+ through long attribute values.\r
+\r
+ A response MAY contain attribute groups, attributes, attribute\r
+ syntaxes, values, and status codes that the client does not expect.\r
+ Therefore, a client implementation MUST gracefully handle such\r
+ responses and not refuse to inter-operate with a conforming Printer\r
+ that is returning IETF standards track extension or vendor\r
+ extensions, including attribute groups, attributes, attribute\r
+ syntaxes, attribute values, status codes, and out-of-band attribute\r
+ values that conform to Section 6. Clients may choose to ignore any\r
+ parameters, attribute groups, attributes, attribute syntaxes, or\r
+ values that they do not understand.\r
+\r
+ While a client is sending data to a printer, it SHOULD do its best to\r
+ prevent a channel from being closed by a lower layer when the channel\r
+ is blocked (i.e. flow-controlled off) for whatever reason, e.g. 'out\r
+ of paper' or 'job ahead hasn't freed up enough memory'. However, the\r
+ layer that launched the print submission (e.g. an end user) MAY close\r
+ the channel in order to cancel the job. When a client closes a\r
+ channel, a Printer MAY print all or part of the received portion of\r
+ the document. See the "Encoding and Transport" document [RFC2910]\r
+ for more details.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 144]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ A client MUST support Client Authentication as defined in the IPP/1.1\r
+ Encoding and Transport document [RFC2910]. A client SHOULD support\r
+ Operation Privacy and Server Authentication as defined in the IPP/1.1\r
+ Encoding and Transport document [RFC2910]. See also section 8 of\r
+ this document.\r
+\r
+5.2 IPP Object Conformance Requirements\r
+\r
+ This section specifies the conformance requirements for conforming\r
+ implementations of IPP objects (see section 2). These requirements\r
+ apply to an IPP object whether it is:\r
+\r
+ (1) an (embedded) device component that accepts IPP requests and\r
+ controls the device or\r
+\r
+ (2) a component of a print server that accepts IPP requests (where\r
+ the print server control one or more networked devices using IPP or\r
+ other protocols).\r
+\r
+5.2.1 Objects\r
+\r
+ Conforming implementations MUST implement all of the model objects as\r
+ defined in this document in the indicated sections:\r
+\r
+ Section 2.1 - Printer Object\r
+ Section 2.2 - Job Object\r
+\r
+5.2.2 Operations\r
+\r
+ Conforming IPP object implementations MUST implement all of the\r
+ REQUIRED model operations, including REQUIRED responses, as defined\r
+ in this document in the indicated sections:\r
+\r
+ For a Printer object:\r
+ Print-Job (section 3.2.1) REQUIRED\r
+ Print-URI (section 3.2.2) OPTIONAL\r
+ Validate-Job (section 3.2.3) REQUIRED\r
+ Create-Job (section 3.2.4) OPTIONAL\r
+ Get-Printer-Attributes (section 3.2.5) REQUIRED\r
+ Get-Jobs (section 3.2.6) REQUIRED\r
+ Pause-Printer (section 3.2.7) OPTIONAL\r
+ Resume-Printer (section 3.2.8) OPTIONAL\r
+ Purge-Jobs (section 3.2.9) OPTIONAL\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 145]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ For a Job object:\r
+ Send-Document (section 3.3.1) OPTIONAL\r
+ Send-URI (section 3.3.2) OPTIONAL\r
+ Cancel-Job (section 3.3.3) REQUIRED\r
+ Get-Job-Attributes (section 3.3.4) REQUIRED\r
+ Hold-Job (section 3.3.5) OPTIONAL\r
+ Release-Job (section 3.3.6) OPTIONAL\r
+ Restart-Job (section 3.3.7) OPTIONAL\r
+\r
+ Conforming IPP objects MUST support all REQUIRED operation attributes\r
+ and all values of such attributes if so indicated in the description.\r
+ Conforming IPP objects MUST ignore all unsupported or unknown\r
+ operation attributes or operation attribute groups received in a\r
+ request, but MUST reject a request that contains a supported\r
+ operation attribute that contains an unsupported value.\r
+\r
+ Conforming IPP objects MAY return operation responses that contain\r
+ attributes groups, attributes names, attribute syntaxes, attribute\r
+ values, and status codes that are extensions to this standard. The\r
+ additional attribute groups MAY occur in any order.\r
+\r
+ The following section on object attributes specifies the support\r
+ required for object attributes.\r
+\r
+5.2.3 IPP Object Attributes\r
+\r
+ Conforming IPP objects MUST support all of the REQUIRED object\r
+ attributes, as defined in this document in the indicated sections.\r
+\r
+ If an object supports an attribute, it MUST support only those values\r
+ specified in this document or through the extension mechanism\r
+ described in section 5.2.4. It MAY support any non-empty subset of\r
+ these values. That is, it MUST support at least one of the specified\r
+ values and at most all of them.\r
+\r
+5.2.4 Versions\r
+\r
+ IPP/1.1 clients MUST meet the conformance requirements for clients\r
+ specified in this document and [RFC2910]. IPP/1.1 clients MUST send\r
+ requests containing a "version-number" parameter with a '1.1' value.\r
+\r
+ IPP/1.1 Printer and Job objects MUST meet the conformance\r
+ requirements for IPP objects specified in this document and\r
+ [RFC2910]. IPP/1.1 objects MUST accept requests containing a\r
+ "version-number" parameter with a '1.1' value (or reject the request\r
+ if the operation is not supported).\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 146]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ It is beyond the scope of this specification to mandate conformance\r
+ with previous versions. IPP/1.1 was deliberately designed, however,\r
+ to make supporting previous versions easy. It is worth noting that,\r
+ at the time of composing this specification (1999), we would expect\r
+ IPP/1.1 Printer implementations to:\r
+\r
+ understand any valid request in the format of IPP/1.0, or 1.1;\r
+\r
+ respond appropriately with a response containing the same\r
+ "version-number" parameter value used by the client in the request.\r
+\r
+ And we would expect IPP/1.1 clients to:\r
+\r
+ understand any valid response in the format of IPP/1.0, or 1.1.\r
+\r
+ It is recommended that IPP/1.1 clients try supplying alternate\r
+ version numbers if they receive a 'server-error-version-not-\r
+ supported' error return in a response.\r
+\r
+5.2.5 Extensions\r
+\r
+ A conforming IPP object MAY support IETF standards track extensions\r
+ and vendor extensions, as long as the extensions meet the\r
+ requirements specified in Section 6.\r
+\r
+ For each attribute included in an operation response, a conforming\r
+ IPP object MUST return a value whose type and value syntax conforms\r
+ to the requirement of the Model document as specified in Sections 3\r
+ and 4.\r
+\r
+5.2.6 Attribute Syntaxes\r
+\r
+ An IPP object MUST be able to accept any of the attribute syntaxes\r
+ defined in Section 4.1, including their full range, in any operation\r
+ in which a client may supply attributes or the system administrator\r
+ may configure attributes (by means outside the scope of this IPP/1.1\r
+ document). In particular for each attribute that the IPP object\r
+ supports whose attribute syntax is 'text', the IPP object MUST accept\r
+ and process both the 'textWithoutLanguage' and 'textWithLanguage'\r
+ forms. Similarly, for each attribute that the IPP object supports\r
+ whose attribute syntax is 'name', the IPP object MUST accept and\r
+ process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms.\r
+ Furthermore, an IPP object MUST return attributes to the client in\r
+ operation responses that conform to the syntax specified in Section\r
+ 4.1, including their full range if supplied previously by a client.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 147]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+5.2.7 Security\r
+\r
+ An IPP Printer implementation SHOULD contain support for Client\r
+ Authentication as defined in the IPP/1.1 Encoding and Transport\r
+ document [RFC2910]. A Printer implementation MAY allow an\r
+ administrator to configure the Printer so that all, some, or none of\r
+ the users are authenticated. See also section 8 of this document.\r
+\r
+ An IPP Printer implementation SHOULD contain support for Operation\r
+ Privacy and Server Authentication as defined in the IPP/1.1 Encoding\r
+ and Transport document [RFC2910]. A Printer implementation MAY allow\r
+ an administrator to configure the degree of support for Operation\r
+ Privacy and Server Authentication. See also section 8 of this\r
+ document.\r
+\r
+ Security MUST NOT be compromised when a client supplies a lower\r
+ "version-number" parameter in a request. For example, if an IPP/1.1\r
+ conforming Printer object accepts version '1.0' requests and is\r
+ configured to enforce Digest Authentication, it MUST do the same for\r
+ a version '1.0' request.\r
+\r
+5.3 Charset and Natural Language Requirements\r
+\r
+ All clients and IPP objects MUST support the 'utf-8' charset as\r
+ defined in section 4.1.7.\r
+\r
+ IPP objects MUST be able to accept any client request which correctly\r
+ uses the "attributes-natural-language" operation attribute or the\r
+ Natural Language Override mechanism on any individual attribute\r
+ whether or not the natural language is supported by the IPP object.\r
+ If an IPP object supports a natural language, then it MUST be able to\r
+ translate (perhaps by table lookup) all generated 'text' or 'name'\r
+ attribute values into one of the supported languages (see section\r
+ 3.1.4). That is, the IPP object that supports a natural language\r
+ NEED NOT be a general purpose translator of any arbitrary 'text' or\r
+ 'name' value supplied by the client into that natural language.\r
+ However, the object MUST be able to translate (automatically\r
+ generate) any of its own attribute values and messages into that\r
+ natural language.\r
+\r
+6. IANA Considerations\r
+\r
+ This section describes the procedures for defining semantics for the\r
+ following IETF standards track extensions and vendor extensions to\r
+ the IPP/1.1 Model and Semantics document:\r
+\r
+ 1. keyword attribute values\r
+ 2. enum attribute values\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 148]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 3. attributes\r
+ 4. attribute syntaxes\r
+ 5. operations\r
+ 6. attribute groups\r
+ 7. status codes\r
+ 8. out-of-band attribute values\r
+\r
+ Extensions registered for use with IPP/1.1 are OPTIONAL for client\r
+ and IPP object conformance to the IPP/1.1 "Model and Semantics"\r
+ document (this document).\r
+\r
+ These extension procedures are aligned with the guidelines as set\r
+ forth by the IESG [IANA-CON]. Section 11 describes how to propose\r
+ new registrations for consideration. IANA will reject registration\r
+ proposals that leave out required information or do not follow the\r
+ appropriate format described in Section 11. The IPP/1.1 Model and\r
+ Semantics document may also be extended by an appropriate RFC that\r
+ specifies any of the above extensions.\r
+\r
+6.1 Typed 'keyword' and 'enum' Extensions\r
+\r
+ IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3\r
+ and 4.1.4). This document uses prefixes to the 'keyword' and 'enum'\r
+ basic attribute syntax type in order to communicate extra information\r
+ to the reader through its name. This extra information is not\r
+ represented in the protocol because it is unimportant to a client or\r
+ Printer object. The list below describes the prefixes and their\r
+ meaning.\r
+\r
+ "type1": This IPP specification document must be revised (or\r
+ another IETF standards track document which augments this\r
+ document) to add a new keyword or a new enum. No vendor\r
+ defined keywords or enums are allowed.\r
+\r
+ "type2": Implementers can, at any time, add new keyword or enum\r
+ values by proposing the complete specification to IANA:\r
+\r
+ iana@iana.org\r
+\r
+ IANA will forward the registration proposal to the IPP\r
+ Designated Expert who will review the proposal with a mailing\r
+ list that the Designated Expert keeps for this purpose.\r
+ Initially, that list will be the mailing list used by the IPP\r
+ WG:\r
+\r
+ ipp@pwg.org\r
+\r
+ even after the IPP WG is disbanded as permitted by [IANA-CON].\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 149]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The IPP Designated Expert is appointed by the IESG Area\r
+ Director responsible for IPP, according to [IANA-CON].\r
+\r
+ When a type2 keyword or enum is approved, the IPP Designated\r
+ Expert becomes the point of contact for any future maintenance\r
+ that might be required for that registration.\r
+\r
+ "type3": Implementers can, at any time, add new keyword and enum\r
+ values by submitting the complete specification to IANA as for\r
+ type2 who will forward the proposal to the IPP Designated\r
+ Expert. While no additional technical review is required, the\r
+ IPP Designated Expert may, at his/her discretion, forward the\r
+ proposal to the same mailing list as for type2 registrations\r
+ for advice and comment.\r
+\r
+ When a type3 keyword or enum is approved by the IPP Designated\r
+ Expert, the original proposer becomes the point of contact for\r
+ any future maintenance that might be required for that\r
+ registration.\r
+\r
+ For type2 and type3 keywords, the proposer includes the name of the\r
+ keyword in the registration proposal and the name is part of the\r
+ technical review.\r
+\r
+ After type2 and type3 enums specifications are approved, the IPP\r
+ Designated Expert in consultation with IANA assigns the next\r
+ available enum number for each enum value.\r
+\r
+ IANA will publish approved type2 and type3 keyword and enum\r
+ attributes value registration specifications in:\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt\r
+\r
+ where xxx is the attribute name that specifies the initial values and\r
+ yyy.txt is a descriptive file name that contains one or more enums or\r
+ keywords approved at the same time. For example, if several\r
+ additional enums for stapling are approved for use with the\r
+ "finishings" attribute (and "finishings-default" and "finishings-\r
+ supported" attributes), IANA will publish the additional values in\r
+ the file:\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/attribute-\r
+ values/finishings/stapling.txt\r
+\r
+ Note: Some attributes are defined to be: 'type3 keywords' | 'name'\r
+ which allows for attribute values to be extended by a site\r
+ administrator with administrator defined names. Such names are not\r
+ registered with IANA.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 150]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ By definition, each of the three types above assert some sort of\r
+ registry or review process in order for extensions to be considered\r
+ valid. Each higher numbered level (1, 2, 3) tends to be decreasingly\r
+ less stringent than the previous level. Therefore, any typeN value\r
+ MAY be registered using a process for some typeM where M is less than\r
+ N, however such registration is NOT REQUIRED. For example, a type3\r
+ value MAY be registered in a type 1 manner (by being included in a\r
+ future version of an IPP specification), however, it is NOT REQUIRED.\r
+\r
+ This document defines keyword and enum values for all of the above\r
+ types, including type3 keywords.\r
+\r
+ For vendor keyword extensions, implementers SHOULD use keywords with\r
+ a suitable distinguishing prefix, such as "xxx-" where xxx follows\r
+ the syntax rules for keywords (see section 4.1.3) and is the\r
+ (lowercase) fully qualified company name registered with IANA for use\r
+ in domain names [RFC1035]. For example, if the company XYZ Corp. had\r
+ obtained the domain name "XYZ.com", then a vendor keyword 'abc' would\r
+ be: 'xyz.com-abc'.\r
+\r
+ Note: RFC 1035 [RFC1035] indicates that while upper and lower case\r
+ letters are allowed in domain names, no significance is attached to\r
+ the case. That is, two names with the same spelling but different\r
+ case are to be treated as if identical. Also, the labels in a domain\r
+ name must follow the rules for ARPANET host names: They must start\r
+ with a letter, end with a letter or digit, and have as interior\r
+ characters only letters, digits, and hyphen. Labels must be 63\r
+ characters or less. Labels are separated by the "." character.\r
+\r
+ For vendor enum extensions, implementers MUST use values in the\r
+ reserved integer range which is 2**30 to 2**31-1.\r
+\r
+6.2 Attribute Extensibility\r
+\r
+ Attribute names (see section 4.1.3) are type2 keywords. Therefore,\r
+ new attributes may be registered and have the same status as\r
+ attributes in this document by following the type2 extension rules.\r
+ For vendor attribute extensions, implementers SHOULD use keywords\r
+ with a suitable distinguishing prefix as described in Section 6.1.\r
+\r
+ IANA will publish approved attribute registration specifications as\r
+ separate files:\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt\r
+\r
+ where "xxx-yyy" is the new attribute name.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 151]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ If a new Printer object attribute is defined and its values can be\r
+ affected by a specific document format, its specification needs to\r
+ contain the following sentence:\r
+\r
+ "The value of this attribute returned in a Get-Printer-\r
+ Attributes response MAY depend on the "document-format"\r
+ attribute supplied (see Section 3.2.5.1)."\r
+\r
+ If the specification does not, then its value in the Get-Printer-\r
+ Attributes response MUST NOT depend on the "document-format" supplied\r
+ in the request. When a new Job Template attribute is registered, the\r
+ value of the Printer attributes MAY vary with "document-format"\r
+ supplied in the request without the specification having to indicate\r
+ so.\r
+\r
+6.3 Attribute Syntax Extensibility\r
+\r
+ Attribute syntaxes (see section 4.1) are like type2 enums.\r
+ Therefore, new attribute syntaxes may be registered and have the same\r
+ status as attribute syntaxes in this document by following the type2\r
+ extension rules described in Section 6.1. The initial set of value\r
+ codes that identify each of the attribute syntaxes have been assigned\r
+ in the "Encoding and Transport" document [RFC2910], including a\r
+ designated range for vendor extension.\r
+\r
+ For attribute syntaxes, the IPP Designated Expert in consultation\r
+ with IANA assigns the next attribute syntax code in the appropriate\r
+ range as specified in [RFC2910]. IANA will publish approved\r
+ attribute syntax registration specifications as separate files:\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt\r
+\r
+ where 'xxx-yyy' is the new attribute syntax name.\r
+\r
+6.4 Operation Extensibility\r
+\r
+ Operations (see section 3) may also be registered following the type2\r
+ procedures described in Section 6.1, though major new operations will\r
+ usually be done by a new standards track RFC that augments this\r
+ document. For vendor operation extensions, implementers MUST use the\r
+ range for the "operation-id" in requests specified in Section 4.4.15\r
+ "operations-supported" Printer attribute.\r
+\r
+ For operations, the IPP Designated Expert in consultation with IANA\r
+ assigns the next operation-id code as specified in Section 4.4.15.\r
+ IANA will publish approved operation registration specifications as\r
+ separate files:\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 152]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt\r
+\r
+ where "Xxx-Yyy" is the new operation name.\r
+\r
+6.5 Attribute Group Extensibility\r
+\r
+ Attribute groups (see section 3.1.3) passed in requests and responses\r
+ may be registered following the type2 procedures described in Section\r
+ 6.1. The initial set of attribute group tags have been assigned in\r
+ the "Encoding and Transport" document [RFC2910], including a\r
+ designated range for vendor extension.\r
+\r
+ For attribute groups, the IPP Designated Expert in consultation with\r
+ IANA assigns the next attribute group tag code in the appropriate\r
+ range as specified in [RFC2910]. IANA will publish approved\r
+ attribute group registration specifications as separate files:\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-\r
+ tag.txt\r
+\r
+ where 'xxx-yyy-tag' is the new attribute group tag name.\r
+\r
+6.6 Status Code Extensibility\r
+\r
+ Operation status codes (see section 3.1.6.1) may also be registered\r
+ following the type2 procedures described in Section 6.1. The values\r
+ for status codes are allocated in ranges as specified in Section 14\r
+ for each status code class:\r
+\r
+ "informational" - Request received, continuing process\r
+ "successful" - The action was successfully received, understood, and\r
+ accepted\r
+ "redirection" - Further action must be taken in order to complete the\r
+ request\r
+ "client-error" - The request contains bad syntax or cannot be\r
+ fulfilled\r
+ "server-error" - The IPP object failed to fulfill an apparently\r
+ valid request\r
+\r
+ For vendor operation status code extensions, implementers MUST use\r
+ the top of each range as specified in Section 13.\r
+\r
+ For operation status codes, the IPP Designated Expert in consultation\r
+ with IANA assigns the next status code in the appropriate class range\r
+ as specified in Section 13. IANA will publish approved status code\r
+ registration specifications as separate files:\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 153]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ where "xxx-yyy" is the new operation status code keyword.\r
+\r
+6.7 Out-of-band Attribute Value Extensibility\r
+\r
+ Out-of-band attribute values (see the beginning of section 4.1)\r
+ passed in requests and responses may be registered following the\r
+ type2 procedures described in Section 6.1. The initial set of out-\r
+ of-band attribute value tags have been assigned in the "Encoding and\r
+ Transport" document [RFC2910].\r
+\r
+ For out-of-band attribute value tags, the IPP Designated Expert in\r
+ consultation with IANA assigns the next out-of-band attribute value\r
+ tag code in the appropriate range as specified in [RFC2910]. IANA\r
+ will publish approved out-of-band attribute value tags registration\r
+ specifications as separate files:\r
+\r
+ ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-\r
+ tags/xxx-yyy-tag.txt\r
+\r
+ where 'xxx-yyy-tag' is the new out-of-band attribute value tag name.\r
+\r
+6.8 Registration of MIME types/sub-types for document-formats\r
+\r
+ The "document-format" attribute's syntax is 'mimeMediaType'. This\r
+ means that valid values are Internet Media Types (see Section 4.1.9).\r
+ RFC 2045 [RFC2045] defines the syntax for valid Internet media types.\r
+ IANA is the registry for all Internet media types.\r
+\r
+6.9 Registration of charsets for use in 'charset' attribute values\r
+\r
+ The "attributes-charset" attribute's syntax is 'charset'. This means\r
+ that valid values are charsets names. When a charset in the IANA\r
+ registry has more than one name (alias), the name labeled as\r
+ "(preferred MIME name)", if present, MUST be used (see Section\r
+ 4.1.7). IANA is the registry for charsets following the procedures\r
+ of [RFC2278].\r
+\r
+7. Internationalization Considerations\r
+\r
+ Some of the attributes have values that are text strings and names\r
+ which are intended for human understanding rather than machine\r
+ understanding (see the 'text' and 'name' attribute syntaxes in\r
+ Sections 4.1.1 and 4.1.2).\r
+\r
+ In each operation request, the client\r
+\r
+ - identifies the charset and natural language of the request which\r
+ affects each supplied 'text' and 'name' attribute value, and\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 154]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - requests the charset and natural language for attributes\r
+ returned by the IPP object in operation responses (as described\r
+ in Section 3.1.4.1).\r
+\r
+ In addition, the client MAY separately and individually identify the\r
+ Natural Language Override of a supplied 'text' or 'name' attribute\r
+ using the 'textWithLanguage' and 'nameWithLanguage' technique\r
+ described section 4.1.1.2 and 4.1.2.2 respectively.\r
+\r
+ All IPP objects MUST support the UTF-8 [RFC2279] charset in all\r
+ 'text' and 'name' attributes supported. If an IPP object supports\r
+ more than the UTF-8 charset, the object MUST convert between them in\r
+ order to return the requested charset to the client according to\r
+ Section 3.1.4.2. If an IPP object supports more than one natural\r
+ language, the object SHOULD return 'text' and 'name' values in the\r
+ natural language requested where those values are generated by the\r
+ Printer (see Section 3.1.4.1).\r
+\r
+ For Printers that support multiple charsets and/or multiple natural\r
+ languages in 'text' and 'name' attributes, different jobs may have\r
+ been submitted in differing charsets and/or natural languages. All\r
+ responses MUST be returned in the charset requested by the client.\r
+ However, the Get-Jobs operation uses the 'textWithLanguage' and\r
+ 'nameWithLanguage' mechanism to identify the differing natural\r
+ languages with each job attribute returned.\r
+\r
+ The Printer object also has configured charset and natural language\r
+ attributes. The client can query the Printer object to determine\r
+ the list of charsets and natural languages supported by the Printer\r
+ object and what the Printer object's configured values are. See the\r
+ "charset-configured", "charset-supported", "natural-language-\r
+ configured", and "generated-natural-language-supported" Printer\r
+ description attributes for more details.\r
+\r
+ The "charset-supported" attributed identifies the supported charsets.\r
+ If a charset is supported, the IPP object MUST be capable of\r
+ converting to and from that charset into any other supported charset.\r
+ In many cases, an IPP object will support only one charset and it\r
+ MUST be the UTF-8 charset.\r
+\r
+ The "charset-configured" attribute identifies the one supported\r
+ charset which is the native charset given the current configuration\r
+ of the IPP object (administrator defined).\r
+\r
+ The "generated-natural-language-supported" attribute identifies the\r
+ set of supported natural languages for generated messages; it is not\r
+ related to the set of natural languages that must be accepted for\r
+ client supplied 'text' and 'name' attributes. For client supplied\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 155]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'text' and 'name' attributes, an IPP object MUST accept ALL supplied\r
+ natural languages. Just because a Printer object is currently\r
+ configured to support 'en-us' natural language does not mean that the\r
+ Printer object should reject a job if the client supplies a job name\r
+ that is in 'fr-ca'.\r
+\r
+ The "natural-language-configured" attribute identifies the one\r
+ supported natural language for generated messages which is the native\r
+ natural language given the current configuration of the IPP object\r
+ (administrator defined).\r
+\r
+ Attributes of type 'text' and 'name' are populated from different\r
+ sources. These attributes can be categorized into following groups\r
+ (depending on the source of the attribute):\r
+\r
+ 1. Some attributes are supplied by the client (e.g., the client\r
+ supplied "job-name", "document-name", and "requesting-user-\r
+ name" operation attributes along with the corresponding Job\r
+ object's "job-name" and "job-originating-user-name"\r
+ attributes). The IPP object MUST accept these attributes in\r
+ any natural language no matter what the set of supported\r
+ languages for generated messages\r
+ 2. Some attributes are supplied by the system administrator (e.g.,\r
+ the Printer object's "printer-name" and "printer-location"\r
+ attributes). These too can be in any natural language. If the\r
+ natural language for these attributes is different than what a\r
+ client requests, then they must be reported using the Natural\r
+ Language Override mechanism.\r
+ 3. Some attributes are supplied by the device manufacturer (e.g.,\r
+ the Printer object's "printer-make-and-model" attribute).\r
+ These too can be in any natural language. If the natural\r
+ language for these attributes is different than what a client\r
+ requests, then they must be reported using the Natural Language\r
+ Override mechanism.\r
+ 4. Some attributes are supplied by the operator (e.g., the Job\r
+ object's "job-message-from-operator" attribute). These too can\r
+ be in any natural language. If the natural language for these\r
+ attributes is different than what a client requests, then they\r
+ must be reported using the Natural Language Override mechanism.\r
+ 5. Some attributes are generated by the IPP object (e.g., the Job\r
+ object's "job-state-message" attribute, the Printer object's\r
+ "printer-state-message" attribute, and the "status-message"\r
+ operation attribute). These attributes can only be in one of\r
+ the "generated-natural-language-supported" natural languages.\r
+ If a client requests some natural language for these attributes\r
+ other than one of the supported values, the IPP object SHOULD\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 156]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ respond using the value of the "natural-language-configured"\r
+ attribute (using the Natural Language Override mechanism if\r
+ needed).\r
+\r
+ The 'text' and 'name' attributes specified in this version of this\r
+ document (additional ones will be registered according to the\r
+ procedures in Section 6) are:\r
+\r
+ Attributes Source\r
+\r
+ Operation Attributes:\r
+ job-name (name) client\r
+ document-name (name) client\r
+ requesting-user-name (name) client\r
+ status-message (text) Job or Printer object\r
+ detailed-status-message (text) Job or Printer object -\r
+ see rule 1\r
+ document-access-error (text) Job or Printer object -\r
+ see rule 1\r
+\r
+ Job Template Attributes:\r
+ job-hold-until (keyword | name) client matches\r
+ administrator-configured\r
+ job-hold-until-default (keyword | name) client matches\r
+ administrator-configured\r
+ job-hold-until-supported (keyword | client matches\r
+ name) administrator-configured\r
+ job-sheets (keyword | name) client matches\r
+ administrator-configured\r
+ job-sheets-default (keyword | name) client matches\r
+ administrator-configured\r
+ job-sheets-supported (keyword | name) client matches\r
+ administrator-configured\r
+ media (keyword | name) client matches\r
+ administrator-configured\r
+ media-default (keyword | name) client matches\r
+ administrator-configured\r
+ media-supported (keyword | name) client matches\r
+ administrator-configured\r
+ media-ready (keyword | name) client matches\r
+ administrator-configured\r
+\r
+ Job Description Attributes:\r
+ job-name (name) client or Printer object\r
+ job-originating-user-name (name) Printer object\r
+ job-state-message (text) Job or Printer object\r
+ output-device-assigned (name(127)) administrator\r
+ job-message-from-operator (text(127)) operator\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 157]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ job-detailed-status-messages (1setOf Job or Printer object -\r
+ text) see rule 1\r
+ job-document-access-errors (1setOf Job or Printer object -\r
+ text) see rule 1\r
+\r
+ Printer Description Attributes:\r
+ printer-name (name(127)) administrator\r
+ printer-location (text(127)) administrator\r
+ printer-info (text(127)) administrator\r
+ printer-make-and-model (text(127)) administrator or\r
+ manufacturer\r
+ printer-state-message (text) Printer object\r
+ printer-message-from-operator operator\r
+ (text(127))\r
+\r
+ Rule 1 - Neither the Printer nor the client localizes these message\r
+ attributes, since they are intended for use by the system\r
+ administrator or other experienced technical persons.\r
+\r
+8. Security Considerations\r
+\r
+ It is difficult to anticipate the security risks that might exist in\r
+ any given IPP environment. For example, if IPP is used within a given\r
+ corporation over a private network, the risks of exposing document\r
+ data may be low enough that the corporation will choose not to use\r
+ encryption on that data. However, if the connection between the\r
+ client and the IPP object is over a public network, the client may\r
+ wish to protect the content of the information during transmission\r
+ through the network with encryption.\r
+\r
+ Furthermore, the value of the information being printed may vary from\r
+ one IPP environment to the next. Printing payroll checks, for\r
+ example, would have a different value than printing public\r
+ information from a file. There is also the possibly of denial-of-\r
+ service attacks, but denial-of-service attacks against printing\r
+ resources are not well understood and there is no published\r
+ precedents regarding this scenario.\r
+\r
+ Once the authenticated identity of the requester has been supplied to\r
+ the IPP object, the object uses that identity to enforce any\r
+ authorization policy that might be in place. For example, one site's\r
+ policy might be that only the job owner is allowed to cancel a job.\r
+ The details and mechanisms to set up a particular access control\r
+ policy are not part of IPP/1.1, and must be established via some\r
+ other type of administrative or access control framework. However,\r
+ there are operation status codes that allow an IPP server to return\r
+ information back to a client about any potential access control\r
+ violations for an IPP object.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 158]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ During a create operation, the client's identity is recorded in the\r
+ Job object in an implementation-defined attribute. This information\r
+ can be used to verify a client's identity for subsequent operations\r
+ on that Job object in order to enforce any access control policy that\r
+ might be in effect. See section 8.3 below for more details.\r
+\r
+ Since the security levels or the specific threats that an IPP system\r
+ administrator may be concerned with cannot be anticipated, IPP MUST\r
+ be capable of operating with different security mechanisms and\r
+ security policies as required by the individual installation.\r
+ Security policies might vary from very strong, to very weak, to none\r
+ at all, and corresponding security mechanisms will be required.\r
+\r
+8.1 Security Scenarios\r
+\r
+ The following sections describe specific security attacks for IPP\r
+ environments. Where examples are provided they should be considered\r
+ illustrative of the environment and not an exhaustive set. Not all of\r
+ these environments will necessarily be addressed in initial\r
+ implementations of IPP.\r
+\r
+8.1.1 Client and Server in the Same Security Domain\r
+\r
+ This environment is typical of internal networks where traditional\r
+ office workers print the output of personal productivity applications\r
+ on shared work-group printers, or where batch applications print\r
+ their output on large production printers. Although the identity of\r
+ the user may be trusted in this environment, a user might want to\r
+ protect the content of a document against such attacks as\r
+ eavesdropping, replaying or tampering.\r
+\r
+8.1.2 Client and Server in Different Security Domains\r
+\r
+ Examples of this environment include printing a document created by\r
+ the client on a publicly available printer, such as at a commercial\r
+ print shop; or printing a document remotely on a business associate's\r
+ printer. This latter operation is functionally equivalent to sending\r
+ the document to the business associate as a facsimile. Printing\r
+ sensitive information on a Printer in a different security domain\r
+ requires strong security measures. In this environment authentication\r
+ of the printer is required as well as protection against unauthorized\r
+ use of print resources. Since the document crosses security domains,\r
+ protection against eavesdropping and document tampering are also\r
+ required. It will also be important in this environment to protect\r
+ Printers against "spamming" and malicious document content.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 159]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+8.1.3 Print by Reference\r
+\r
+ When the document is not stored on the client, printing can be done\r
+ by reference. That is, the print request can contain a reference, or\r
+ pointer, to the document instead of the actual document itself (see\r
+ sections 3.2.2 and 3.3.2). Standard methods currently do not exist\r
+ for remote entities to "assume" the credentials of a client for\r
+ forwarding requests to a 3rd party. It is anticipated that Print-By-\r
+ Reference will be used to access "public" documents and that\r
+ sophisticated methods for authenticating "proxies" is not specified\r
+ in this document.\r
+\r
+8.2 URIs in Operation, Job, and Printer attributes\r
+\r
+ The "printer-uri-supported" attribute contains the Printer object's\r
+ URI(s). Its companion attribute, "uri-security-supported",\r
+ identifies the security mechanism used for each URI listed in the\r
+ "printer-uri-supported" attribute. For each Printer operation\r
+ request, a client MUST supply only one URI in the "printer-uri"\r
+ operation attribute. In other words, even though the Printer\r
+ supports more than one URI, the client only interacts with the\r
+ Printer object using one if its URIs. This duality is not needed for\r
+ Job objects, since the Printer objects is the factory for Job\r
+ objects, and the Printer object will generate the correct URI for new\r
+ Job objects depending on the Printer object's security configuration.\r
+\r
+8.3 URIs for each authentication mechanisms\r
+\r
+ Each URI has an authentication mechanism associated with it. If the\r
+ URI is the i'th element of "printer-uri-supported", then\r
+ authentication mechanism is the "i th" element of "uri-\r
+ authentication-supported". For a list of possible authentication\r
+ mechanisms, see section 4.4.2.\r
+\r
+ The Printer object uses an authentication mechanism to determine the\r
+ name of the user performing an operation. This user is called the\r
+ "authenticated user". The credibility of authentication depends on\r
+ the mechanism that the Printer uses to obtain the user's name. When\r
+ the authentication mechanism is 'none', all authenticated users are\r
+ "anonymous".\r
+\r
+ During job creation operations, the Printer initializes the value of\r
+ the "job-originating-user-name" attribute (see section 4.3.6) to be\r
+ the authenticated user. The authenticated user is this case is called\r
+ the "job owner".\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 160]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ If an implementation can be configured to support more than one\r
+ authentication mechanism (see section 4.4.2), then it MUST implement\r
+ rules for determining equality of authenticated user names which have\r
+ been authenticated via different authentication mechanisms. One\r
+ possible policy is that identical names that are authenticated via\r
+ different mechanisms are different. For example, a user can cancel\r
+ his job only if he uses the same authentication mechanism for both\r
+ Cancel-Job and Print-Job. Another policy is that identical names\r
+ that are authenticated via different mechanism are the same if the\r
+ authentication mechanism for the later operation is not less strong\r
+ than the authentication mechanism for the earlier job creation\r
+ operation. For example, a user can cancel his job only if he uses\r
+ the same or stronger authentication mechanism for Cancel-Job and\r
+ Print-Job. With this second policy a job submitted via 'requesting-\r
+ user-name' authentication could be canceled via 'digest'\r
+ authentication. With the first policy, the job could not be canceled\r
+ in this way.\r
+\r
+ A client is able to determine the authentication mechanism used to\r
+ create a job. It is the i'th value of the Printer's "uri-\r
+ authentication-supported" attribute (see section 4.4.2), where i is\r
+ the index of the element of the Printer's "printer-uri-supported"\r
+ attribute (see section 4.4.1) equal to the job's "job-printer-uri"\r
+ attribute (see section 4.3.3).\r
+\r
+8.4 Restricted Queries\r
+\r
+ In many IPP operations, a client supplies a list of attributes to be\r
+ returned in the response. For security reasons, an IPP object may be\r
+ configured not to return all attributes (or all values) that a client\r
+ requests. The job attributes returned MAY depend on whether the\r
+ requesting user is the same as the user that submitted the job. The\r
+ IPP object MAY even return none of the requested attributes. In such\r
+ cases, the status returned is the same as if the object had returned\r
+ all requested attributes. The client cannot tell by such a response\r
+ whether the requested attribute was present or absent on the object.\r
+\r
+8.5 Operations performed by operators and system administrators\r
+\r
+ For the three printer operations Pause-Printer, Resume-Printer, and\r
+ Purge-Jobs (see sections 3.2.7, 3.2.8 and 3.2.9), the requesting user\r
+ is intended to be an operator or administrator of the Printer object\r
+ (see section 1). Otherwise, the IPP Printer MUST reject the\r
+ operation and return: 'client-error-forbidden', 'client-error-not-\r
+ authenticated', or 'client-error-not-authorized' as appropriate. For\r
+ operations on jobs, the requesting user is intended to be the job\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 161]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ owner or may be an operator or administrator of the Printer object.\r
+ The means for authorizing an operator or administrator of the Printer\r
+ object are not specified in this document.\r
+\r
+8.6 Queries on jobs submitted using non-IPP protocols\r
+\r
+ If the device that an IPP Printer is representing is able to accept\r
+ jobs using other job submission protocols in addition to IPP, it is\r
+ RECOMMENDED that such an implementation at least allow such "foreign"\r
+ jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as\r
+ 'unknown'. Such an implementation NEED NOT support all of the same\r
+ IPP job attributes as for IPP jobs. The IPP object returns the\r
+ 'unknown' out-of-band value for any requested attribute of a foreign\r
+ job that is supported for IPP jobs, but not for foreign jobs.\r
+\r
+ It is further RECOMMENDED, that the IPP Printer generate "job-id" and\r
+ "job-uri" values for such "foreign jobs", if possible, so that they\r
+ may be targets of other IPP operations, such as Get-Job-Attributes\r
+ and Cancel-Job. Such an implementation also needs to deal with the\r
+ problem of authentication of such foreign jobs. One approach would\r
+ be to treat all such foreign jobs as belonging to users other than\r
+ the user of the IPP client. Another approach would be for the\r
+ foreign job to belong to 'anonymous'. Only if the IPP client has\r
+ been authenticated as an operator or administrator of the IPP Printer\r
+ object, could the foreign jobs be queried by an IPP request.\r
+ Alternatively, if the security policy is to allow users to query\r
+ other users' jobs, then the foreign jobs would also be visible to an\r
+ end-user IPP client using Get-Jobs and Get-Job-Attributes.\r
+\r
+9. References\r
+\r
+ [ASME-Y14.1M] Metric Drawing Sheet Size and Format, ASME Y14.1M-1995.\r
+ This standard defines metric sheet sizes and formats\r
+ for engineering drawings.\r
+\r
+ [ASCII] Coded Character Set - 7-bit American Standard Code for\r
+ Information Interchange (ASCII), ANSI X3.4-1986. This\r
+ standard is the specification of the US-ASCII charset.\r
+\r
+ [BCP-11] Bradner S. and R. Hovey, "The Organizations Involved in\r
+ the IETF Standards Process", BCP 11, RFC 2028, October\r
+ 1996.\r
+\r
+ [HTPP] J. Barnett, K. Carter, R. DeBry, "Initial Draft -\r
+ Hypertext Printing Protocol - HTPP/1.0", October 1996,\r
+ ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 162]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ [IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing\r
+ an IANA Considerations Section in RFCs", BCP 26, RFC\r
+ 2434, October 1998.\r
+\r
+ [IANA-CS] IANA Registry of Coded Character Sets:\r
+ ftp://ftp.isi.edu/in-notes/iana/assignments/character-\r
+ sets\r
+\r
+ [IANA-MT] IANA Registry of Media Types: ftp://ftp.isi.edu/in-\r
+ notes/iana/assignments/media-types/\r
+\r
+ [IPP-IIG] Hastings, T., Manros, C., Kugler, C., Holst, H., and P.\r
+ Zehler, "Internet Printing Protocol/1.1: draft-ietf-\r
+ ipp-implementers-guide-v11-01.txt, work in progress,\r
+ May 30, 2000.\r
+\r
+ [ISO10646-1] ISO/IEC 10646-1:1993, "Information technology --\r
+ Universal Multiple-Octet Coded Character Set (UCS) -\r
+ Part 1: Architecture and Basic Multilingual Plane,\r
+ JTC1/SC2."\r
+\r
+ [ISO8859-1] ISO/IEC 8859-1:1987, "Information technology -- 8-bit\r
+ One-Byte Coded Character Set - Part 1: Latin Alphabet\r
+ Nr 1", 1987, JTC1/SC2.\r
+\r
+ [ISO10175] ISO/IEC 10175 Document Printing Application (DPA), June\r
+ 1996.\r
+\r
+ [LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D.\r
+ Taylor, P. Zehler, "LDPA - Lightweight Document\r
+ Printing Application", October 1996,\r
+ ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz\r
+\r
+ [P1387.4] Kirk, M. (editor), POSIX System Administration - Part\r
+ 4: Printing Interfaces, POSIX 1387.4 D8, 1994.\r
+\r
+ [PSIS] Herriot, R. (editor), X/Open A Printing System\r
+ Interoperability Specification (PSIS), August 1995.\r
+\r
+ [PWG] Printer Working Group, http://www.pwg.org.\r
+\r
+ [RFC1035] Mockapetris, P., "Domain Names - Implementation and\r
+ Specification", STD 13, RFC 1035, November 1987.\r
+\r
+ [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC\r
+ 1179, August 1990.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 163]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.\r
+ Gyllenskog, "Printer MIB", RFC 1759, March 1995.\r
+\r
+ [RFC1766] Alvestrand, H., "Tags for the Identification of\r
+ Languages", RFC 1766, March 1995.\r
+\r
+ [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format\r
+ Specification version 1.3 ", RFC 1951, May 1996.\r
+\r
+ [RFC1952] Deutsch, P., "GZIP file format specification version\r
+ 4.3", RFC 1952, May 1996.\r
+\r
+ [RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,\r
+ August 1996.\r
+\r
+ [RFC2026] Bradner, S., "The Internet Standards Process --\r
+ Revision 3", BCP 9, RFC 2026, October 1996.\r
+\r
+ [RFC2045] Freed, N. and N. Borenstein, ", Multipurpose Internet\r
+ Mail Extensions (MIME) Part One: Format of Internet\r
+ Message Bodies", RFC 2045, November 1996.\r
+\r
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet\r
+ Mail Extensions (MIME) Part Two: Media Types", RFC\r
+ 2046, November 1996.\r
+\r
+ [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose\r
+ Internet Mail Extension (MIME) Part Four: Registration\r
+ Procedures", RFC 2048, November 1996.\r
+\r
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions",\r
+ RFC 2228, October 1997.\r
+\r
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version\r
+ 1.0", RFC 2246, January 1999.\r
+\r
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and\r
+ Languages" BCP 18, RFC 2277, January 1998.\r
+\r
+ [RFC2278] Freed, N. and J. Postel: "IANA CharSet Registration\r
+ Procedures", BCP 19, RFC 2278, January 1998.\r
+\r
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO\r
+ 10646", RFC 2279, January 1998.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 164]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ [RFC2316] Bellovin, S., "Report of the IAB Security Architecture\r
+ Workshop", RFC 2316, April 1998.\r
+\r
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform\r
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,\r
+ August 1998.\r
+\r
+ [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,\r
+ "Internet Printing Protocol/1.0: Encoding and\r
+ Transport", RFC 2565, April 1999.\r
+\r
+ [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and\r
+ P. Powell, "Internet Printing Protocol/1.0: Model and\r
+ Semantics", RFC 2566, April 1999.\r
+\r
+ [RFC2567] Wright, D., "Design Goals for an Internet Printing\r
+ Protocol", RFC 2567, April 1999.\r
+\r
+ [RFC2568] Zilles, S., "Rationale for the Structure and Model and\r
+ Protocol for the Internet Printing Protocol", RFC 2568,\r
+ April 1999.\r
+\r
+ [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,\r
+ "Mapping between LPD and IPP Protocols", RFC 2569,\r
+ April 1999.\r
+\r
+ [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,\r
+ "Textual Conventions for SMIv2", STD 58, RFC 2579,\r
+ April 1999.\r
+\r
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,\r
+ Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext\r
+ Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.\r
+\r
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,\r
+ S., Leach, P., Luotonen, A. and L. Stewart, "HTTP\r
+ Authentication: Basic and Digest Access\r
+ Authentication", RFC 2617, June 1999.\r
+\r
+ [RFC2639] Hastings, T. and C. Manros, "Internet Printing\r
+ Protocol/1.0: Encoding and Transport", RFC 2639, July\r
+ 1999.\r
+\r
+ [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.\r
+ Wenn, "Internet Printing Protocol/1.1: Encoding and\r
+ Transport", RFC 2910, September 2000.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 165]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ [SSL] Netscape, The SSL Protocol, Version 3, (Text version\r
+ 3.02), November 1996.\r
+\r
+ [SWP] P. Moore, B. Jahromi, S. Butler, "Simple Web Printing\r
+ SWP/1.0", May 7, 1997,\r
+ ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf\r
+\r
+10. Authors' Addresses\r
+\r
+ Scott A. Isaacson, Editor\r
+ Novell, Inc.\r
+ 122 E 1700 S\r
+ Provo, UT 84606\r
+\r
+ Phone: 801-861-7366\r
+ Fax: 801-861-2517\r
+ EMail: sisaacson@novell.com\r
+\r
+\r
+ Tom Hastings\r
+ Xerox Corporation\r
+ 737 Hawaii St. ESAE 231\r
+ El Segundo, CA 90245\r
+\r
+ Phone: 310-333-6413\r
+ Fax: 310-333-5514\r
+ EMail: hastings@cp10.es.xerox.com\r
+\r
+\r
+ Robert Herriot\r
+ Xerox Corp.\r
+ 3400 Hill View Ave, Building 1\r
+ Palo Alto, CA 94304\r
+\r
+ Phone: 650-813-7696\r
+ Fax: 650-813-6860\r
+ EMail: robert.herriot@pahv.xerox.com\r
+\r
+\r
+ Roger deBry\r
+ Utah Valley State College\r
+ Orem, UT 84058\r
+\r
+ Phone: (801) 222-8000\r
+ EMail: debryro@uvsc.edu\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 166]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Patrick Powell\r
+ Astart Technologies\r
+ 9475 Chesapeake Dr., Suite D\r
+ San Diego, CA 95123\r
+\r
+ Phone: (619) 874-6543\r
+ Fax: (619) 279-8424\r
+ EMail: papowell@astart.com\r
+\r
+ IPP Web Page: http://www.pwg.org/ipp/\r
+ IPP Mailing List: ipp@pwg.org\r
+\r
+ To subscribe to the ipp mailing list, send the following email:\r
+ 1) send it to majordomo@pwg.org\r
+ 2) leave the subject line blank\r
+ 3) put the following two lines in the message body:\r
+ subscribe ipp\r
+ end\r
+\r
+ Implementers of this specification document are encouraged to join\r
+ IPP Mailing List in order to participate in any discussions of\r
+ clarification issues and review of registration proposals for\r
+ additional attributes and values.\r
+\r
+ Other Participants:\r
+\r
+ Chuck Adams - Tektronix Shivaun Albright - HP\r
+ Stefan Andersson - Axis Jeff Barnett - IBM\r
+ Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM\r
+ Systems\r
+ Keith Carter - IBM Angelo Caruso - Xerox\r
+ Rajesh Chawla - TR Computing Nancy Chen - Okidata\r
+ Solutions\r
+ Josh Cohen - Microsoft Jeff Copeland - QMS\r
+ Andy Davidson - Tektronix Roger deBry - IBM\r
+ Maulik Desai - Auco Mabry Dozier - QMS\r
+ Lee Farrell - Canon Information Satoshi Fujitami - Ricoh\r
+ Systems\r
+ Steve Gebert - IBM Sue Gleeson - Digital\r
+ Charles Gordon - Osicom Brian Grimshaw - Apple\r
+ Jerry Hadsell - IBM Richard Hart - Digital\r
+ Tom Hastings - Xerox Henrik Holst - I-data\r
+ Stephen Holmstead Zhi-Hong Huang - Zenographics\r
+ Scott Isaacson - Novell Babek Jahromi - Microsoft\r
+ Swen Johnson - Xerox David Kellerman - Northlake\r
+ Software\r
+ Robert Kline - TrueSpectra Charles Kong - Panasonic\r
+ Carl Kugler - IBM Dave Kuntz - Hewlett-Packard\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 167]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Takami Kurono - Brother Rick Landau - Digital\r
+ Scott Lawrence - Agranot Systems Greg LeClair - Epson\r
+ Dwight Lewis - Lexmark Harry Lewis - IBM\r
+ Tony Liao - Vivid Image Roy Lomicka - Digital\r
+ Pete Loya - HP Ray Lutz - Cognisys\r
+ Mike MacKay - Novell, Inc. David Manchala - Xerox\r
+ Carl-Uno Manros - Xerox Jay Martin - Underscore\r
+ Stan McConnell - Xerox Larry Masinter - Xerox\r
+ Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft\r
+ Ira McDonald - High North Inc. Mike Moldovan - G3 Nova\r
+ Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh\r
+ Pat Nogay - IBM Ron Norton - Printronics\r
+ Hugo Parra, Novell Bob Pentecost - Hewlett-Packard\r
+ Patrick Powell - Astart Jeff Rackowitz - Intermec\r
+ Technologies\r
+ Eric Random - Peerless Rob Rhoads - Intel\r
+ Xavier Riley - Xerox Gary Roberts - Ricoh\r
+ David Roach - Unisys Stuart Rowley - Kyocera\r
+ Yuji Sasaki - Japan Computer Richard Schneider - Epson\r
+ Industry\r
+ Kris Schoff - HP Katsuaki Sekiguchi - Canon\r
+ Bob Setterbo - Adobe Gail Songer - Peerless\r
+ Hideki Tanaka - Cannon Devon Taylor - Novell\r
+ Mike Timperman - Lexmark Atsushi Uchino - Epson\r
+ Shigeru Ueda - Canon Bob Von Andel - Allegro Software\r
+ William Wagner - NetSilicon/DPI Jim Walker - DAZEL\r
+ Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard\r
+ Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.\r
+ Jasper Wong - Xionics Don Wright - Lexmark\r
+ Michael Wu - Heidelberg Digital Rick Yardumian - Xerox\r
+ Michael Yeung - Toshiba Lloyd Young - Lexmark\r
+ Atsushi Yuki - Kyocera Peter Zehler - Xerox\r
+ William Zhang- Canon Information Frank Zhao - Panasonic\r
+ Systems\r
+ Steve Zilles - Adobe Rob Zirnstein - Canon Information\r
+ Systems\r
+\r
+11. Formats for IPP Registration Proposals\r
+\r
+ In order to propose an IPP extension for registration, the proposer\r
+ must submit an application to IANA by email to "iana@iana.org" or by\r
+ filling out the appropriate form on the IANA web pages\r
+ (http://www.iana.org). This section specifies the required\r
+ information and the formats for proposing registrations of extensions\r
+ to IPP as provided in Section 6 for:\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 168]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 1. type2 'keyword' attribute values\r
+ 2. type3 'keyword' attribute values\r
+ 3. type2 'enum' attribute values\r
+ 4. type3 'enum' attribute values\r
+ 5. attributes\r
+ 6. attribute syntaxes\r
+ 7. operations\r
+ 8. status codes\r
+ 9. out-of-band attribute values\r
+\r
+11.1 Type2 keyword attribute values registration,\r
+\r
+ Type of registration: type2 keyword attribute value\r
+ Name of attribute to which this keyword specification is to be added:\r
+ Proposed keyword name of this keyword value:\r
+ Specification of this keyword value (follow the style of IPP Model\r
+ Section 4.1.2.3):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For type2 keywords, the Designated Expert will be the point of\r
+ contact for the approved registration specification, if any\r
+ maintenance of the registration specification is needed.\r
+\r
+11.2 Type3 keyword attribute values registration\r
+\r
+ Type of registration: type3 keyword attribute value\r
+ Name of attribute to which this keyword specification is to be added:\r
+ Proposed keyword name of this keyword value:\r
+ Specification of this keyword value (follow the style of IPP Model\r
+ Section 4.1.2.3):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For type3 keywords, the proposer will be the point of contact\r
+ for the approved registration specification, if any maintenance of\r
+ the registration specification is needed.\r
+\r
+11.3 Type2 enum attribute values registration\r
+\r
+ Type of registration: type2 enum attribute value\r
+ Name of attribute to which this enum specification is to be added:\r
+ Keyword symbolic name of this enum value:\r
+ Numeric value (to be assigned by the IPP Designated Expert in\r
+ consultation with IANA):\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 169]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Specification of this enum value (follow the style of IPP Model\r
+ Section 4.1.4):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For type2 enums, the Designated Expert will be the point of\r
+ contact for the approved registration specification, if any\r
+ maintenance of the registration specification is needed.\r
+\r
+11.4 Type3 enum attribute values registration\r
+\r
+ Type of registration: type3 enum attribute value\r
+ Name of attribute to which this enum specification is to be added:\r
+ Keyword symbolic name of this enum value:\r
+ Numeric value (to be assigned by the IPP Designated Expert in\r
+ consultation with IANA):\r
+ Specification of this enum value (follow the style of IPP Model\r
+ Section 4.1.4):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For type3 enums, the proposer will be the point of contact for\r
+ the approved registration specification, if any maintenance of the\r
+ registration specification is needed.\r
+\r
+11.5 Attribute registration\r
+\r
+ Type of registration: attribute\r
+ Proposed keyword name of this attribute:\r
+ Types of attribute (Operation, Job Template, Job Description, Printer\r
+ Description):\r
+ Operations to be used with if the attribute is an operation attribute:\r
+ Object (Job, Printer, etc. if bound to an object):\r
+ Attribute syntax(es) (include 1setOf and range as in Section 4.2):\r
+ If attribute syntax is 'keyword' or 'enum', is it type2 or type3:\r
+ If this is a Printer attribute, MAY the value returned depend on\r
+ "document-format" (See Section 6.2):\r
+ If this is a Job Template attribute, how does its specification depend\r
+ on the value of the "multiple-document-handling" attribute:\r
+ Specification of this attribute (follow the style of IPP Model Section\r
+ 4.2):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 170]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Note: For attributes, the IPP Designated Expert will be the point of\r
+ contact for the approved registration specification, if any\r
+ maintenance of the registration specification is needed.\r
+\r
+11.6 Attribute Syntax registration\r
+\r
+ Type of registration: attribute syntax\r
+ Proposed name of this attribute syntax:\r
+ Type of attribute syntax (integer, octetString, character-string, see\r
+ [RFC2910]):\r
+ Numeric tag according to [RFC2910] (to be assigned by the IPP\r
+ Designated Expert in consultation with IANA):\r
+ Specification of this attribute (follow the style of IPP Model Section\r
+ 4.1):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For attribute syntaxes, the IPP Designated Expert will be the\r
+ point of contact for the approved registration specification, if any\r
+ maintenance of the registration specification is needed.\r
+\r
+11.7 Operation registration\r
+\r
+ Type of registration: operation\r
+ Proposed name of this operation:\r
+ Numeric operation-id value according to section 4.4.15 (to be assigned\r
+ by the IPP Designated Expert in consultation with IANA):\r
+ Object Target (Job, Printer, etc. that operation is upon):\r
+ Specification of this operation (follow the style of IPP Model Section\r
+ 3):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For operations, the IPP Designated Expert will be the point of\r
+ contact for the approved registration specification, if any\r
+ maintenance of the registration specification is needed.\r
+\r
+11.8 Attribute Group registration\r
+\r
+ Type of registration: attribute group\r
+ Proposed name of this attribute group:\r
+ Numeric tag according to [RFC2910] (to be assigned by the IPP\r
+ Designated Expert in consultation with IANA):\r
+ Operation requests and group number for each operation in which the\r
+ attribute group occurs:\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 171]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Operation responses and group number for each operation in which the\r
+ attribute group occurs:\r
+ Specification of this attribute group (follow the style of IPP Model\r
+ Section 3):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For attribute groups, the IPP Designated Expert will be the\r
+ point of contact for the approved registration specification, if any\r
+ maintenance of the registration specification is needed.\r
+\r
+11.9 Status code registration\r
+\r
+ Type of registration: status code\r
+ Keyword symbolic name of this status code value:\r
+ Numeric value (to be assigned by the IPP Designated Expert in\r
+ consultation with IANA):\r
+ Operations that this status code may be used with:\r
+ Specification of this status code (follow the style of IPP Model\r
+ Section 13 APPENDIX B: Status Codes and Suggested Status Code\r
+ Messages):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For status codes, the Designated Expert will be the point of\r
+ contact for the approved registration specification, if any\r
+ maintenance of the registration specification is needed.\r
+\r
+11.10 Out-of-band Attribute Value registration\r
+\r
+ Type of registration: out-of-band attribute value\r
+ Proposed name of this out-of-band attribute value:\r
+ Numeric tag according to [RFC2910] (to be assigned by the IPP Designated\r
+ Expert in consultation with IANA):\r
+ Operations that this out-of-band attribute value may be used with:\r
+ Attributes that this out-of-band attribute value may be used with:\r
+ Specification of this out-of-band attribute value (follow the style of\r
+ the beginning of IPP Model Section 4.1):\r
+ Name of proposer:\r
+ Address of proposer:\r
+ Email address of proposer:\r
+\r
+ Note: For out-of-band attribute values, the IPP Designated Expert\r
+ will be the point of contact for the approved registration\r
+ specification, if any maintenance of the registration specification\r
+ is needed.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 172]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+12. APPENDIX A: Terminology\r
+\r
+ This specification document uses the terminology defined in this\r
+ section.\r
+\r
+12.1 Conformance Terminology\r
+\r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",\r
+ "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be\r
+ interpreted as described in RFC 2119 [RFC2119].\r
+\r
+12.1.1 NEED NOT\r
+\r
+ This term is not included in RFC 2119. The verb "NEED NOT" indicates\r
+ an action that the subject of the sentence does not have to implement\r
+ in order to claim conformance to the standard. The verb "NEED NOT"\r
+ is used instead of "MAY NOT" since "MAY NOT" sounds like a\r
+ prohibition.\r
+\r
+12.2 Model Terminology\r
+\r
+12.2.1 Keyword\r
+\r
+ Keywords are used within this document as identifiers of semantic\r
+ entities within the abstract model (see section 4.1.2.3). Attribute\r
+ names, some attribute values, attribute syntaxes, and attribute group\r
+ names are represented as keywords.\r
+\r
+12.2.2 Attributes\r
+\r
+ An attribute is an item of information that is associated with an\r
+ instance of an IPP object. An attribute consists of an attribute\r
+ name and one or more attribute values. Each attribute has a specific\r
+ attribute syntax. All object attributes are defined in section 4 and\r
+ all operation attributes are defined in section 3.\r
+\r
+ Job Template Attributes are described in section 4.2. The client\r
+ optionally supplies Job Template attributes in a create request\r
+ (operation requests that create Job objects). The Printer object has\r
+ associated attributes which define supported and default values for\r
+ the Printer.\r
+\r
+12.2.2.1 Attribute Name\r
+\r
+ Each attribute is uniquely identified in this document by its\r
+ attribute name. An attribute name is a keyword. The keyword\r
+ attribute name is given in the section header describing that\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 173]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ attribute. In running text in this document, attribute names are\r
+ indicated inside double quotation marks (") where the quotation marks\r
+ are not part of the keyword itself.\r
+\r
+12.2.2.2 Attribute Group Name\r
+\r
+ Related attributes are grouped into named groups. The name of the\r
+ group is a keyword. The group name may be used in place of naming\r
+ all the attributes in the group explicitly. Attribute groups are\r
+ defined in section 3.\r
+\r
+12.2.2.3 Attribute Value\r
+\r
+ Each attribute has one or more values. Attribute values are\r
+ represented in the syntax type specified for that attribute. In\r
+ running text in this document, attribute values are indicated inside\r
+ single quotation marks ('), whether their attribute syntax is\r
+ keyword, integer, text, etc. where the quotation marks are not part\r
+ of the value itself.\r
+\r
+12.2.2.4 Attribute Syntax\r
+\r
+ Each attribute is defined using an explicit syntax type. In this\r
+ document, each syntax type is defined as a keyword with specific\r
+ meaning. The "Encoding and Transport" document [RFC2910] indicates\r
+ the actual "on-the-wire" encoding rules for each syntax type.\r
+ Attribute syntax types are defined in section 4.1.\r
+\r
+12.2.3 Supports\r
+\r
+ By definition, a Printer object supports an attribute only if that\r
+ Printer object responds with the corresponding attribute populated\r
+ with some value(s) in a response to a query for that attribute. A\r
+ Printer object supports an attribute value if the value is one of the\r
+ Printer object's "supported values" attributes. The device behind a\r
+ Printer object may exhibit a behavior that corresponds to some IPP\r
+ attribute, but if the Printer object, when queried for that\r
+ attribute, doesn't respond with the attribute, then as far as IPP is\r
+ concerned, that implementation does not support that feature. If the\r
+ Printer object's "xxx-supported" attribute is not populated with a\r
+ particular value (even if that value is a legal value for that\r
+ attribute), then that Printer object does not support that particular\r
+ value.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 174]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ A conforming implementation MUST support all REQUIRED attributes.\r
+ However, even for REQUIRED attributes, conformance to IPP does not\r
+ mandate that all implementations support all possible values\r
+ representing all possible job processing behaviors and features. For\r
+ example, if a given instance of a Printer supports only certain\r
+ document formats, then that Printer responds with the "document-\r
+ format-supported" attribute populated with a set of values, possibly\r
+ only one, taken from the entire set of possible values defined for\r
+ that attribute. This limited set of values represents the Printer's\r
+ set of supported document formats. Supporting an attribute and some\r
+ set of values for that attribute enables IPP end users to be aware of\r
+ and make use of those features associated with that attribute and\r
+ those values. If an implementation chooses to not support an\r
+ attribute or some specific value, then IPP end users would have no\r
+ ability to make use of that feature within the context of IPP itself.\r
+ However, due to existing practice and legacy systems which are not\r
+ IPP aware, there might be some other mechanism outside the scope of\r
+ IPP to control or request the "unsupported" feature (such as embedded\r
+ instructions within the document data itself).\r
+\r
+ For example, consider the "finishings-supported" attribute.\r
+\r
+ 1) If a Printer object is not physically capable of stapling, the\r
+ "finishings-supported" attribute MUST NOT be populated with the\r
+ value of 'staple'.\r
+ 2) A Printer object is physically capable of stapling, however an\r
+ implementation chooses not to support stapling in the IPP\r
+ "finishings" attribute. In this case, 'staple' MUST NOT be a\r
+ value in the "finishings-supported" Printer object attribute.\r
+ Without support for the value 'staple', an IPP end user would\r
+ have no means within the protocol itself to request that a Job\r
+ be stapled. However, an existing document data formatter might\r
+ be able to request that the document be stapled directly with\r
+ an embedded instruction within the document data. In this\r
+ case, the IPP implementation does not "support" stapling,\r
+ however the end user is still able to have some control over\r
+ the stapling of the completed job.\r
+ 3) A Printer object is physically capable of stapling, and an\r
+ implementation chooses to support stapling in the IPP\r
+ "finishings" attribute. In this case, 'staple' MUST be a value\r
+ in the "finishings-supported" Printer object attribute. Doing\r
+ so, would enable end users to be aware of and make use of the\r
+ stapling feature using IPP attributes.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 175]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Even though support for Job Template attributes by a Printer object\r
+ is OPTIONAL, it is RECOMMENDED that if the device behind a Printer\r
+ object is capable of realizing any feature or function that\r
+ corresponds to an IPP attribute and some associated value, then that\r
+ implementation SHOULD support that IPP attribute and value.\r
+\r
+ The set of values in any of the supported value attributes is set\r
+ (populated) by some administrative process or automatic sensing\r
+ mechanism that is outside the scope of this IPP/1.1 document. For\r
+ administrative policy and control reasons, an administrator may\r
+ choose to make only a subset of possible values visible to the end\r
+ user. In this case, the real output device behind the IPP Printer\r
+ abstraction may be capable of a certain feature, however an\r
+ administrator is specifying that access to that feature not be\r
+ exposed to the end user through the IPP protocol. Also, since a\r
+ Printer object may represent a logical print device (not just a\r
+ physical device) the actual process for supporting a value is\r
+ undefined and left up to the implementation. However, if a Printer\r
+ object supports a value, some manual human action may be needed to\r
+ realize the semantic action associated with the value, but no end\r
+ user action is required.\r
+\r
+ For example, if one of the values in the "finishings-supported"\r
+ attribute is 'staple', the actual process might be an automatic\r
+ staple action by a physical device controlled by some command sent to\r
+ the device. Or, the actual process of stapling might be a manual\r
+ action by an operator at an operator attended Printer object.\r
+\r
+ For another example of how supported attributes function, consider a\r
+ system administrator who desires to control all print jobs so that no\r
+ job sheets are printed in order to conserve paper. To force no job\r
+ sheets, the system administrator sets the only supported value for\r
+ the "job-sheets-supported" attribute to 'none'. In this case, if a\r
+ client requests anything except 'none', the create request is\r
+ rejected or the "job-sheets" value is ignored (depending on the value\r
+ of "ipp-attribute-fidelity"). To force the use of job start/end\r
+ sheets on all jobs, the administrator does not include the value\r
+ 'none' in the "job-sheets- supported" attribute. In this case, if a\r
+ client requests 'none', the create request is rejected or the "job-\r
+ sheets" value is ignored (again depending on the value of "ipp-\r
+ attribute-fidelity").\r
+\r
+12.2.4 print-stream page\r
+\r
+ A "print-stream page" is a page according to the definition of pages\r
+ in the language used to express the document data.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 176]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+12.2.5 impression\r
+\r
+ An "impression" is the image (possibly many print-stream pages in\r
+ different configurations) imposed onto a single media page.\r
+\r
+13. APPENDIX B: Status Codes and Suggested Status Code Messages\r
+\r
+ This section defines status code enum keywords and values that are\r
+ used to provide semantic information on the results of an operation\r
+ request. Each operation response MUST include a status code. The\r
+ response MAY also contain a status message that provides a short\r
+ textual description of the status. The status code is intended for\r
+ use by automata, and the status message is intended for the human end\r
+ user. Since the status message is an OPTIONAL component of the\r
+ operation response, an IPP application (i.e., a browser, GUI, print\r
+ driver or gateway) is NOT REQUIRED to examine or display the status\r
+ message, since it MAY not be returned to the application.\r
+\r
+ The prefix of the status keyword defines the class of response as\r
+ follows:\r
+\r
+ "informational" - Request received, continuing process\r
+ "successful" - The action was successfully received, understood,\r
+ and accepted\r
+ "redirection" - Further action must be taken in order to complete\r
+ the request\r
+ "client-error" - The request contains bad syntax or cannot be\r
+ fulfilled\r
+ "server-error" - The IPP object failed to fulfill an apparently\r
+ valid request\r
+\r
+ As with type2 enums, IPP status codes are extensible. IPP clients\r
+ are NOT REQUIRED to understand the meaning of all registered status\r
+ codes, though such understanding is obviously desirable. However,\r
+ IPP clients MUST understand the class of any status code, as\r
+ indicated by the prefix, and treat any unrecognized response as being\r
+ equivalent to the first status code of that class, with the exception\r
+ that an unrecognized response MUST NOT be cached. For example, if an\r
+ unrecognized status code of "client-error-xxx-yyy" is received by the\r
+ client, it can safely assume that there was something wrong with its\r
+ request and treat the response as if it had received a "client-\r
+ error-bad-request" status code. In such cases, IPP applications\r
+ SHOULD present the OPTIONAL message (if present) to the end user\r
+ since the message is likely to contain human readable information\r
+ which will help to explain the unusual status. The name of the enum\r
+ is the suggested status message for US English.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 177]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The status code values range from 0x0000 to 0x7FFF. The value ranges\r
+ for each status code class are as follows:\r
+\r
+ "successful" - 0x0000 to 0x00FF\r
+ "informational" - 0x0100 to 0x01FF\r
+ "redirection" - 0x0200 to 0x02FF\r
+ "client-error" - 0x0400 to 0x04FF\r
+ "server-error" - 0x0500 to 0x05FF\r
+\r
+ The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0\r
+ to 5) is reserved for vendor use within each status code class.\r
+ Values 0x0600 to 0x7FFF are reserved for future assignment by IETF\r
+ standards track documents and MUST NOT be used.\r
+\r
+13.1 Status Codes\r
+\r
+ Each status code is described below. Section 13.1.5.9 contains a\r
+ table that indicates which status codes apply to which operations.\r
+ The Implementer's Guide [IPP-IIG] describe the suggested steps for\r
+ processing IPP attributes for all operations, including returning\r
+ status codes.\r
+\r
+13.1.1 Informational\r
+\r
+ This class of status code indicates a provisional response and is to\r
+ be used for informational purposes only.\r
+\r
+ There are no status codes defined in IPP/1.1 for this class of status\r
+ code.\r
+\r
+13.1.2 Successful Status Codes\r
+\r
+ This class of status code indicates that the client's request was\r
+ successfully received, understood, and accepted.\r
+\r
+13.1.2.1 successful-ok (0x0000)\r
+\r
+ The request has succeeded and no request attributes were substituted\r
+ or ignored. In the case of a response to a create request, the\r
+ 'successful-ok' status code indicates that the request was\r
+ successfully received and validated, and that the Job object has been\r
+ created; it does not indicate that the job has been processed. The\r
+ transition of the Job object into the 'completed' state is the only\r
+ indicator that the job has been printed.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 178]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)\r
+\r
+ The request has succeeded, but some supplied (1) attributes were\r
+ ignored or (2) unsupported values were substituted with supported\r
+ values or were ignored in order to perform the operation without\r
+ rejecting it. Unsupported attributes, attribute syntaxes, or values\r
+ MUST be returned in the Unsupported Attributes group of the response\r
+ for all operations. There is an exception to this rule for the query\r
+ operations: Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes\r
+ for the "requested-attributes" operation attribute only. When the\r
+ supplied values of the "requested-attributes" operation attribute are\r
+ requesting attributes that are not supported, the IPP object MAY, but\r
+ is NOT REQUIRED to, return the "requested-attributes" attribute in\r
+ the Unsupported Attribute response group (with the unsupported values\r
+ only). See sections 3.1.7 and 3.2.1.2.\r
+\r
+13.1.2.3 successful-ok-conflicting-attributes (0x0002)\r
+\r
+ The request has succeeded, but some supplied attribute values\r
+ conflicted with the values of other supplied attributes. These\r
+ conflicting values were either (1) substituted with (supported)\r
+ values or (2) the attributes were removed in order to process the job\r
+ without rejecting it. Attributes or values which conflict with other\r
+ attributes and have been substituted or ignored MUST be returned in\r
+ the Unsupported Attributes group of the response for all operations\r
+ as supplied by the client. See sections 3.1.7 and 3.2.1.2.\r
+\r
+13.1.3 Redirection Status Codes\r
+\r
+ This class of status code indicates that further action needs to be\r
+ taken to fulfill the request.\r
+\r
+ There are no status codes defined in IPP/1.1 for this class of status\r
+ code.\r
+\r
+13.1.4 Client Error Status Codes\r
+\r
+ This class of status code is intended for cases in which the client\r
+ seems to have erred. The IPP object SHOULD return a message\r
+ containing an explanation of the error situation and whether it is a\r
+ temporary or permanent condition.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 179]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.4.1 client-error-bad-request (0x0400)\r
+\r
+ The request could not be understood by the IPP object due to\r
+ malformed syntax (such as the value of a fixed length attribute whose\r
+ length does not match the prescribed length for that attribute - see\r
+ the Implementer's Guide [IPP-IIG] ). The IPP application SHOULD NOT\r
+ repeat the request without modifications.\r
+\r
+13.1.4.2 client-error-forbidden (0x0401)\r
+\r
+ The IPP object understood the request, but is refusing to fulfill it.\r
+ Additional authentication information or authorization credentials\r
+ will not help and the request SHOULD NOT be repeated. This status\r
+ code is commonly used when the IPP object does not wish to reveal\r
+ exactly why the request has been refused or when no other response is\r
+ applicable.\r
+\r
+13.1.4.3 client-error-not-authenticated (0x0402)\r
+\r
+ The request requires user authentication. The IPP client may repeat\r
+ the request with suitable authentication information. If the request\r
+ already included authentication information, then this status code\r
+ indicates that authorization has been refused for those credentials.\r
+ If this response contains the same challenge as the prior response,\r
+ and the user agent has already attempted authentication at least\r
+ once, then the response message may contain relevant diagnostic\r
+ information. This status codes reveals more information than\r
+ "client-error-forbidden".\r
+\r
+13.1.4.4 client-error-not-authorized (0x0403)\r
+\r
+ The requester is not authorized to perform the request. Additional\r
+ authentication information or authorization credentials will not help\r
+ and the request SHOULD NOT be repeated. This status code is used\r
+ when the IPP object wishes to reveal that the authentication\r
+ information is understandable, however, the requester is explicitly\r
+ not authorized to perform the request. This status codes reveals\r
+ more information than "client-error-forbidden" and "client-error-\r
+ not-authenticated".\r
+\r
+13.1.4.5 client-error-not-possible (0x0404)\r
+\r
+ This status code is used when the request is for something that can\r
+ not happen. For example, there might be a request to cancel a job\r
+ that has already been canceled or aborted by the system. The IPP\r
+ client SHOULD NOT repeat the request.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 180]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.4.6 client-error-timeout (0x0405)\r
+\r
+ The client did not produce a request within the time that the IPP\r
+ object was prepared to wait. For example, a client issued a Create-\r
+ Job operation and then, after a long period of time, issued a Send-\r
+ Document operation and this error status code was returned in\r
+ response to the Send-Document request (see section 3.3.1). The IPP\r
+ object might have been forced to clean up resources that had been\r
+ held for the waiting additional Documents. The IPP object was forced\r
+ to close the Job since the client took too long. The client SHOULD\r
+ NOT repeat the request without modifications.\r
+\r
+13.1.4.7 client-error-not-found (0x0406)\r
+\r
+ The IPP object has not found anything matching the request URI. No\r
+ indication is given of whether the condition is temporary or\r
+ permanent. For example, a client with an old reference to a Job (a\r
+ URI) tries to cancel the Job, however in the mean time the Job might\r
+ have been completed and all record of it at the Printer has been\r
+ deleted. This status code, 'client-error-not-found' is returned\r
+ indicating that the referenced Job can not be found. This error\r
+ status code is also used when a client supplies a URI as a reference\r
+ to the document data in either a Print-URI or Send-URI operation, but\r
+ the document can not be found.\r
+\r
+ In practice, an IPP application should avoid a not found situation by\r
+ first querying and presenting a list of valid Printer URIs and Job\r
+ URIs to the end-user.\r
+\r
+13.1.4.8 client-error-gone (0x0407)\r
+\r
+ The requested object is no longer available and no forwarding address\r
+ is known. This condition should be considered permanent. Clients\r
+ with link editing capabilities should delete references to the\r
+ request URI after user approval. If the IPP object does not know or\r
+ has no facility to determine, whether or not the condition is\r
+ permanent, the status code "client-error-not-found" should be used\r
+ instead.\r
+\r
+ This response is primarily intended to assist the task of maintenance\r
+ by notifying the recipient that the resource is intentionally\r
+ unavailable and that the IPP object administrator desires that remote\r
+ links to that resource be removed. It is not necessary to mark all\r
+ permanently unavailable resources as "gone" or to keep the mark for\r
+ any length of time -- that is left to the discretion of the IPP\r
+ object administrator and/or Printer implementation.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 181]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.4.9 client-error-request-entity-too-large (0x0408)\r
+\r
+ The IPP object is refusing to process a request because the request\r
+ entity is larger than the IPP object is willing or able to process.\r
+ An IPP Printer returns this status code when it limits the size of\r
+ print jobs and it receives a print job that exceeds that limit or\r
+ when the attributes are so many that their encoding causes the\r
+ request entity to exceed IPP object capacity.\r
+\r
+13.1.4.10 client-error-request-value-too-long (0x0409)\r
+\r
+ The IPP object is refusing to service the request because one or more\r
+ of the client-supplied attributes has a variable length value that is\r
+ longer than the maximum length specified for that attribute. The IPP\r
+ object might not have sufficient resources (memory, buffers, etc.) to\r
+ process (even temporarily), interpret, and/or ignore a value larger\r
+ than the maximum length. Another use of this error code is when the\r
+ IPP object supports the processing of a large value that is less than\r
+ the maximum length, but during the processing of the request as a\r
+ whole, the object may pass the value onto some other system component\r
+ which is not able to accept the large value. For more details, see\r
+ the Implementer's Guide [IPP-IIG] .\r
+\r
+ Note: For attribute values that are URIs, this rare condition is\r
+ only likely to occur when a client has improperly submitted a request\r
+ with long query information (e.g. an IPP application allows an end-\r
+ user to enter an invalid URI), when the client has descended into a\r
+ URI "black hole" of redirection (e.g., a redirected URI prefix that\r
+ points to a suffix of itself), or when the IPP object is under attack\r
+ by a client attempting to exploit security holes present in some IPP\r
+ objects using fixed-length buffers for reading or manipulating the\r
+ Request-URI.\r
+\r
+13.1.4.11 client-error-document-format-not-supported (0x040A)\r
+\r
+ The IPP object is refusing to service the request because the\r
+ document data is in a format, as specified in the "document-format"\r
+ operation attribute, that is not supported by the Printer object.\r
+ This error is returned independent of the client-supplied "ipp-\r
+ attribute-fidelity". The Printer object MUST return this status\r
+ code, even if there are other Job Template attributes that are not\r
+ supported as well, since this error is a bigger problem than with Job\r
+ Template attributes. See sections 3.1.6.1, 3.1.7, and 3.2.1.1.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 182]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)\r
+\r
+ In a create request, if the Printer object does not support one or\r
+ more attributes, attribute syntaxes, or attribute values supplied in\r
+ the request and the client supplied the "ipp-attribute-fidelity"\r
+ operation attribute with the 'true' value, the Printer object MUST\r
+ return this status code. The Printer object MUST also return in the\r
+ Unsupported Attributes Group all the attributes and/or values\r
+ supplied by the client that are not supported. See section 3.1.7.\r
+ For example, if the request indicates 'iso-a4' media, but that media\r
+ type is not supported by the Printer object. Or, if the client\r
+ supplies a Job Template attribute and the attribute itself is not\r
+ even supported by the Printer. If the "ipp-attribute-fidelity"\r
+ attribute is 'false', the Printer MUST ignore or substitute values\r
+ for unsupported Job Template attributes and values rather than reject\r
+ the request and return this status code.\r
+\r
+ For any operation where a client requests attributes (such as a Get-\r
+ Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if\r
+ the IPP object does not support one or more of the requested\r
+ attributes, the IPP object simply ignores the unsupported requested\r
+ attributes and processes the request as if they had not been\r
+ supplied, rather than returning this status code. In this case, the\r
+ IPP object MUST return the 'successful-ok-ignored-or-substituted-\r
+ attributes' status code and MAY return the unsupported attributes as\r
+ values of the "requested-attributes" in the Unsupported Attributes\r
+ Group (see section 13.1.2.2).\r
+\r
+13.1.4.13 client-error-uri-scheme-not-supported (0x040C)\r
+\r
+ The scheme of the client-supplied URI in a Print-URI or a Send-URI\r
+ operation is not supported. See sections 3.1.6.1 and 3.1.7.\r
+\r
+13.1.4.14 client-error-charset-not-supported (0x040D)\r
+\r
+ For any operation, if the IPP Printer does not support the charset\r
+ supplied by the client in the "attributes-charset" operation\r
+ attribute, the Printer MUST reject the operation and return this\r
+ status and any 'text' or 'name' attributes using the 'utf-8' charset\r
+ (see Section 3.1.4.1). See sections 3.1.6.1 and 3.1.7.\r
+\r
+13.1.4.15 client-error-conflicting-attributes (0x040E)\r
+\r
+ The request is rejected because some attribute values conflicted with\r
+ the values of other attributes which this document does not permit to\r
+ be substituted or ignored. The Printer object MUST also return in\r
+ the Unsupported Attributes Group the conflicting attributes supplied\r
+ by the client. See sections 3.1.7 and 3.2.1.2.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 183]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.4.16 client-error-compression-not-supported (0x040F)\r
+\r
+ The IPP object is refusing to service the request because the\r
+ document data, as specified in the "compression" operation attribute,\r
+ is compressed in a way that is not supported by the Printer object.\r
+ This error is returned independent of the client-supplied "ipp-\r
+ attribute-fidelity". The Printer object MUST return this status\r
+ code, even if there are other Job Template attributes that are not\r
+ supported as well, since this error is a bigger problem than with Job\r
+ Template attributes. See sections 3.1.6.1, 3.1.7, and 3.2.1.1.\r
+\r
+13.1.4.17 client-error-compression-error (0x0410)\r
+\r
+ The IPP object is refusing to service the request because the\r
+ document data cannot be decompressed when using the algorithm\r
+ specified by the "compression" operation attribute. This error is\r
+ returned independent of the client-supplied "ipp-attribute-fidelity".\r
+ The Printer object MUST return this status code, even if there are\r
+ Job Template attributes that are not supported as well, since this\r
+ error is a bigger problem than with Job Template attributes. See\r
+ sections 3.1.7 and 3.2.1.1.\r
+\r
+13.1.4.18 client-error-document-format-error (0x0411)\r
+\r
+ The IPP object is refusing to service the request because Printer\r
+ encountered an error in the document data while interpreting it.\r
+ This error is returned independent of the client-supplied "ipp-\r
+ attribute-fidelity". The Printer object MUST return this status\r
+ code, even if there are Job Template attributes that are not\r
+ supported as well, since this error is a bigger problem than with Job\r
+ Template attributes. See sections 3.1.7 and 3.2.1.1.\r
+\r
+13.1.4.19 client-error-document-access-error (0x0412)\r
+\r
+ The IPP object is refusing to service the Print-URI or Send-URI\r
+ request because Printer encountered an access error while attempting\r
+ to validate the accessibility or access the document data specified\r
+ in the "document-uri" operation attribute. The Printer MAY also\r
+ return a specific document access error code using the "document-\r
+ access-error" operation attribute (see section 3.1.6.4). This error\r
+ is returned independent of the client-supplied "ipp-attribute-\r
+ fidelity". The Printer object MUST return this status code, even if\r
+ there are Job Template attributes that are not supported as well,\r
+ since this error is a bigger problem than with Job Template\r
+ attributes. See sections 3.1.6.1 and 3.1.7.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 184]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.5 Server Error Status Codes\r
+\r
+ This class of status codes indicates cases in which the IPP object is\r
+ aware that it has erred or is incapable of performing the request.\r
+ The IPP object SHOULD include a message containing an explanation of\r
+ the error situation, and whether it is a temporary or permanent\r
+ condition.\r
+\r
+13.1.5.1 server-error-internal-error (0x0500)\r
+\r
+ The IPP object encountered an unexpected condition that prevented it\r
+ from fulfilling the request. This error status code differs from\r
+ "server-error-temporary-error" in that it implies a more permanent\r
+ type of internal error. It also differs from "server-error-device-\r
+ error" in that it implies an unexpected condition (unlike a paper-jam\r
+ or out-of-toner problem which is undesirable but expected). This\r
+ error status code indicates that probably some knowledgeable human\r
+ intervention is required.\r
+\r
+13.1.5.2 server-error-operation-not-supported (0x0501)\r
+\r
+ The IPP object does not support the functionality required to fulfill\r
+ the request. This is the appropriate response when the IPP object\r
+ does not recognize an operation or is not capable of supporting it.\r
+ See sections 3.1.6.1 and 3.1.7.\r
+\r
+13.1.5.3 server-error-service-unavailable (0x0502)\r
+\r
+ The IPP object is currently unable to handle the request due to a\r
+ temporary overloading or maintenance of the IPP object. The\r
+ implication is that this is a temporary condition which will be\r
+ alleviated after some delay. If known, the length of the delay may be\r
+ indicated in the message. If no delay is given, the IPP application\r
+ should handle the response as it would for a "server-error-\r
+ temporary-error" response. If the condition is more permanent, the\r
+ error status codes "client-error-gone" or "client-error-not-found"\r
+ could be used.\r
+\r
+13.1.5.4 server-error-version-not-supported (0x0503)\r
+\r
+ The IPP object does not support, or refuses to support, the IPP\r
+ protocol version that was supplied as the value of the "version-\r
+ number" operation parameter in the request. The IPP object is\r
+ indicating that it is unable or unwilling to complete the request\r
+ using the same major and minor version number as supplied in the\r
+ request other than with this error message. The error response SHOULD\r
+ contain a "status-message" attribute (see section 3.1.6.2) describing\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 185]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ why that version is not supported and what other versions are\r
+ supported by that IPP object. See sections 3.1.6.1, 3.1.7, and\r
+ 3.1.8.\r
+\r
+ The error response MUST identify in the "version-number" operation\r
+ parameter the closest version number that the IPP object does\r
+ support. For example, if a client supplies version '1.0' and an\r
+ IPP/1.1 object supports version '1.0', then it responds with version\r
+ '1.0' in all responses to such a request. If the IPP/1.1 object does\r
+ not support version '1.0', then it should accept the request and\r
+ respond with version '1.1' or may reject the request and respond with\r
+ this error code and version\r
+ '1.1'. If a client supplies a version '1.2', the IPP/1.1 object\r
+ should accept the request and return version '1.1' or may reject the\r
+ request and respond with this error code and version '1.1'. See\r
+ sections 3.1.8 and 4.4.14.\r
+\r
+13.1.5.5 server-error-device-error (0x0504)\r
+\r
+ A printer error, such as a paper jam, occurs while the IPP object\r
+ processes a Print or Send operation. The response contains the true\r
+ Job Status (the values of the "job-state" and "job-state-reasons"\r
+ attributes). Additional information can be returned in the OPTIONAL\r
+ "job-state-message" attribute value or in the OPTIONAL status message\r
+ that describes the error in more detail. This error status code is\r
+ only returned in situations where the Printer is unable to accept the\r
+ create request because of such a device error. For example, if the\r
+ Printer is unable to spool, and can only accept one job at a time,\r
+ the reason it might reject a create request is that the printer\r
+ currently has a paper jam. In many cases however, where the Printer\r
+ object can accept the request even though the Printer has some error\r
+ condition, the 'successful-ok' status code will be returned. In such\r
+ a case, the client would look at the returned Job Object Attributes\r
+ or later query the Printer to determine its state and state reasons.\r
+\r
+13.1.5.6 server-error-temporary-error (0x0505)\r
+\r
+ A temporary error such as a buffer full write error, a memory\r
+ overflow (i.e. the document data exceeds the memory of the Printer),\r
+ or a disk full condition, occurs while the IPP Printer processes an\r
+ operation. The client MAY try the unmodified request again at some\r
+ later point in time with an expectation that the temporary internal\r
+ error condition may have been cleared. Alternatively, as an\r
+ implementation option, a Printer object MAY delay the response until\r
+ the temporary condition is cleared so that no error is returned.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 186]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+13.1.5.7 server-error-not-accepting-jobs (0x0506)\r
+\r
+ A temporary error indicating that the Printer is not currently\r
+ accepting jobs, because the administrator has set the value of the\r
+ Printer's "printer-is-accepting-jobs" attribute to 'false' (by means\r
+ outside the scope of this IPP/1.1 document).\r
+\r
+13.1.5.8 server-error-busy (0x0507)\r
+\r
+ A temporary error indicating that the Printer is too busy processing\r
+ jobs and/or other requests. The client SHOULD try the unmodified\r
+ request again at some later point in time with an expectation that\r
+ the temporary busy condition will have been cleared.\r
+\r
+13.1.5.9 server-error-job-canceled (0x0508)\r
+\r
+ An error indicating that the job has been canceled by an operator or\r
+ the system while the client was transmitting the data to the IPP\r
+ Printer. If a job-id and job-uri had been created, then they are\r
+ returned in the Print-Job, Send-Document, or Send-URI response as\r
+ usual; otherwise, no job-id and job-uri are returned in the response.\r
+\r
+13.1.5.10 server-error-multiple-document-jobs-not-supported (0x0509)\r
+\r
+ The IPP object does not support multiple documents per job and a\r
+ client attempted to supply document data with a second Send-Document\r
+ or Send-URI operation.\r
+\r
+13.2 Status Codes for IPP Operations\r
+\r
+ PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document\r
+ SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and\r
+ Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 187]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ IPP Operations\r
+ IPP Status Keyword PJ PU CJ SD SU V GA GJ C\r
+ ------------------ -- -- -- -- -- - -- -- -\r
+ successful-ok x x x x x x x x x\r
+ successful-ok-ignored-or-substituted- x x x x x x x x x\r
+ attributes\r
+ successful-ok-conflicting-attributes x x x x x x x x x\r
+ client-error-bad-request x x x x x x x x x\r
+ client-error-forbidden x x x x x x x x x\r
+ client-error-not-authenticated x x x x x x x x x\r
+ client-error-not-authorized x x x x x x x x x\r
+ client-error-not-possible x x x x x x x x x\r
+ client-error-timeout x x\r
+ client-error-not-found x x x x x x x x x\r
+ client-error-gone x x x x x x x x x\r
+ client-error-request-entity-too-large x x x x x x x x x\r
+ client-error-request-value-too-long x x x x x x x x x\r
+ client-error-document-format-not- x x x x x x\r
+ supported\r
+ client-error-attributes-or-values-not- x x x x x x x x x\r
+ supported\r
+ client-error-uri-scheme-not-supported x x\r
+ client-error-charset-not-supported x x x x x x x x x\r
+ client-error-conflicting-attributes x x x x x x x x x\r
+ client-error-compression-not-supported x x x x x\r
+ client-error-compression-error x x x x\r
+ client-error-document-format-error x x x x\r
+ client-error-document-access-error x x\r
+ server-error-internal-error x x x x x x x x x\r
+ server-error-operation-not-supported x x x x\r
+ server-error-service-unavailable x x x x x x x x x\r
+ server-error-version-not-supported x x x x x x x x x\r
+ server-error-device-error x x x x x\r
+ server-error-temporary-error x x x x x\r
+ server-error-not-accepting-jobs x x x x\r
+ server-error-busy x x x x x x x x x\r
+ server-error-job-canceled x x x\r
+ server-error-multiple-document-jobs- x x\r
+ not-supported\r
+\r
+ HJ = Hold-Job, RJ = Release-Job, RS = Restart-Job\r
+ PP = Pause-Printer, RP = Resume-Printer, PJ = Purge-Jobs\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 188]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ IPP Operations (cont.)\r
+ IPP Status Keyword HJ RJ RS PP RP PJ\r
+ ------------------ -- -- -- -- -- --\r
+ successful-ok x x x x x x\r
+ successful-ok-ignored-or-substituted- x x x x x x\r
+ attributes\r
+ successful-ok-conflicting-attributes x x x x x x\r
+ client-error-bad-request x x x x x x\r
+ client-error-forbidden x x x x x x\r
+ client-error-not-authenticated x x x x x x\r
+ client-error-not-authorized x x x x x x\r
+ client-error-not-possible x x x x x x\r
+ client-error-timeout\r
+ client-error-not-found x x x x x x\r
+ client-error-gone x x x x x x\r
+ client-error-request-entity-too-large x x x x x x\r
+ client-error-request-value-too-long x x x x x x\r
+ client-error-document-format-not-\r
+ supported\r
+ client-error-attributes-or-values-not- x x x x x x\r
+ supported\r
+ client-error-uri-scheme-not-supported\r
+ client-error-charset-not-supported x x x x x x\r
+ client-error-conflicting-attributes x x x x x x\r
+ client-error-compression-not-supported\r
+ client-error-compression-error\r
+ client-error-document-format-error\r
+ client-error-document-access-error\r
+ server-error-internal-error x x x x x x\r
+ server-error-operation-not-supported x x x x x x\r
+ server-error-service-unavailable x x x x x x\r
+ server-error-version-not-supported x x x x x x\r
+ server-error-device-error\r
+ server-error-temporary-error x x x x x x\r
+ server-error-not-accepting-jobs\r
+ server-error-busy x x x x x x\r
+ server-error-job-canceled\r
+ server-error-multiple-document-jobs-\r
+ not-supported\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 189]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+14. APPENDIX C: "media" keyword values\r
+\r
+ Standard keyword values are taken from several sources.\r
+\r
+ Standard values are defined (taken from DPA[ISO10175] and the Printer\r
+ MIB[RFC1759]):\r
+\r
+ 'default': The default medium for the output device\r
+ 'iso-a4-white': Specifies the ISO A4 white medium: 210 mm x 297 mm\r
+ 'iso-a4-colored': Specifies the ISO A4 colored medium: 210 mm x 297\r
+ mm\r
+ 'iso-a4-transparent' Specifies the ISO A4 transparent medium: 210 mm\r
+ x 297 mm\r
+ 'iso-a3-white': Specifies the ISO A3 white medium: 297 mm x 420 mm\r
+ 'iso-a3-colored': Specifies the ISO A3 colored medium: 297 mm x 420\r
+ mm\r
+ 'iso-a5-white': Specifies the ISO A5 white medium: 148 mm x 210 mm\r
+ 'iso-a5-colored': Specifies the ISO A5 colored medium: 148 mm x 210\r
+ mm\r
+ 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm\r
+ 'iso-b4-colored': Specifies the ISO B4 colored medium: 250 mm x 353\r
+ mm\r
+ 'iso-b5-white': Specifies the ISO B5 white medium: 176 mm x 250 mm\r
+ 'iso-b5-colored': Specifies the ISO B5 colored medium: 176 mm x 250\r
+ mm\r
+ 'jis-b4-white': Specifies the JIS B4 white medium: 257 mm x 364 mm\r
+ 'jis-b4-colored': Specifies the JIS B4 colored medium: 257 mm x 364\r
+ mm\r
+ 'jis-b5-white': Specifies the JIS B5 white medium: 182 mm x 257 mm\r
+ 'jis-b5-colored': Specifies the JIS B5 colored medium: 182 mm x 257\r
+ mm\r
+\r
+ The following standard values are defined for North American media:\r
+\r
+ 'na-letter-white': Specifies the North American letter white medium\r
+ 'na-letter-colored': Specifies the North American letter colored\r
+ medium\r
+ 'na-letter-transparent': Specifies the North American letter\r
+ transparent medium\r
+ 'na-legal-white': Specifies the North American legal white medium\r
+ 'na-legal-colored': Specifies the North American legal colored\r
+ medium\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 190]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The following standard values are defined for envelopes:\r
+\r
+ 'iso-b4-envelope': Specifies the ISO B4 envelope medium\r
+ 'iso-b5-envelope': Specifies the ISO B5 envelope medium\r
+ 'iso-c3-envelope': Specifies the ISO C3 envelope medium\r
+ 'iso-c4-envelope': Specifies the ISO C4 envelope medium\r
+ 'iso-c5-envelope': Specifies the ISO C5 envelope medium\r
+ 'iso-c6-envelope': Specifies the ISO C6 envelope medium\r
+ 'iso-designated-long-envelope': Specifies the ISO Designated Long\r
+ envelope medium\r
+ 'na-10x13-envelope': Specifies the North American 10x13 envelope\r
+ medium\r
+ 'na-9x12-envelope': Specifies the North American 9x12 envelope\r
+ medium\r
+ 'monarch-envelope': Specifies the Monarch envelope\r
+ 'na-number-10-envelope': Specifies the North American number 10\r
+ business envelope medium\r
+ 'na-7x9-envelope': Specifies the North American 7x9 inch envelope\r
+ 'na-9x11-envelope': Specifies the North American 9x11 inch\r
+ envelope\r
+ 'na-10x14-envelope': Specifies the North American 10x14 inch\r
+ envelope\r
+ 'na-number-9-envelope': Specifies the North American number 9\r
+ business envelope\r
+ 'na-6x9-envelope': Specifies the North American 6x9 inch envelope\r
+ 'na-10x15-envelope': Specifies the North American 10x15 inch\r
+ envelope\r
+\r
+ The following standard values are defined for the less commonly used\r
+ media:\r
+\r
+ 'executive-white': Specifies the white executive medium\r
+ 'folio-white': Specifies the folio white medium\r
+ 'invoice-white': Specifies the white invoice medium\r
+ 'ledger-white': Specifies the white ledger medium\r
+ 'quarto-white': Specified the white quarto medium\r
+ 'iso-a0-white': Specifies the ISO A0 white medium: 841 mm x 1189 mm\r
+ 'iso-a0-transparent': Specifies the ISO A0 transparent medium: 841 mm\r
+ x 1189 mm\r
+ 'iso-a0-translucent': Specifies the ISO A0 translucent medium: 841 mm\r
+ x 1189 mm\r
+ 'iso-a1-white': Specifies the ISO A1 white medium: 594 mm x 841 mm\r
+ 'iso-a1-transparent': Specifies the ISO A1 transparent medium: 594 mm\r
+ x 841 mm\r
+ 'iso-a1-translucent': Specifies the ISO A1 translucent medium: 594 mm\r
+ x 841 mm\r
+ 'iso-a2-white': Specifies the ISO A2 white medium: 420 mm x 594 mm\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 191]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'iso-a2-transparent': Specifies the ISO A2 transparent medium: 420 mm\r
+ x 594 mm\r
+ 'iso-a2-translucent': Specifies the ISO A2 translucent medium: 420 mm\r
+ x 594 mm\r
+ 'iso-a3-transparent': Specifies the ISO A3 transparent medium: 297 mm\r
+ x 420 mm\r
+ 'iso-a3-translucent': Specifies the ISO A3 translucent medium: 297 mm\r
+ x 420 mm\r
+ 'iso-a4-translucent': Specifies the ISO A4 translucent medium: 210 mm\r
+ x 297 mm\r
+ 'iso-a5-transparent': Specifies the ISO A5 transparent medium: 148 mm\r
+ x 210 mm\r
+ 'iso-a5-translucent': Specifies the ISO A5 translucent medium: 148 mm\r
+ x 210 mm\r
+ 'iso-a6-white': Specifies the ISO A6 white medium: 105 mm x 148 mm\r
+ 'iso-a7-white': Specifies the ISO A7 white medium: 74 mm x 105 mm\r
+ 'iso-a8-white': Specifies the ISO A8 white medium: 52 mm x 74 mm\r
+ 'iso-a9-white': Specifies the ISO A9 white medium: 37 mm x 52 mm\r
+ 'iso-a10-white': Specifies the ISO A10 white medium: 26 mm x 37 mm\r
+ 'iso-b0-white': Specifies the ISO B0 white medium: 1000 mm x 1414 mm\r
+ 'iso-b1-white': Specifies the ISO B1 white medium: 707 mm x 1000 mm\r
+ 'iso-b2-white': Specifies the ISO B2 white medium: 500 mm x 707 mm\r
+ 'iso-b3-white': Specifies the ISO B3 white medium: 353 mm x 500 mm\r
+ 'iso-b6-white': Specifies the ISO B6 white medium: 125 mm x 176 mm\r
+ 'iso-b7-white': Specifies the ISO B7 white medium: 88 mm x 125 mm\r
+ 'iso-b8-white': Specifies the ISO B8 white medium: 62 mm x 88 mm\r
+ 'iso-b9-white': Specifies the ISO B9 white medium: 44 mm x 62 mm\r
+ 'iso-b10-white': Specifies the ISO B10 white medium: 31 mm x 44 mm\r
+ 'jis-b0-white': Specifies the JIS B0 white medium: 1030 mm x 1456 mm\r
+ 'jis-b0-transparent': Specifies the JIS B0 transparent medium: 1030\r
+ mm x 1456 mm\r
+ 'jis-b0-translucent': Specifies the JIS B0 translucent medium: 1030\r
+ mm x 1456 mm\r
+ 'jis-b1-white': Specifies the JIS B1 white medium: 728 mm x 1030 mm\r
+ 'jis-b1-transparent': Specifies the JIS B1 transparent medium: 728 mm\r
+ x 1030 mm\r
+ 'jis-b1-translucent': Specifies the JIS B1 translucent medium: 728 mm\r
+ x 1030 mm\r
+ 'jis-b2-white': Specifies the JIS B2 white medium: 515 mm x 728 mm\r
+ 'jis-b2-transparent': Specifies the JIS B2 transparent medium: 515 mm\r
+ x 728 mm\r
+ 'jis-b2-translucent': Specifies the JIS B2 translucent medium: 515 mm\r
+ x 728 mm\r
+ 'jis-b3-white': Specifies the JIS B3 white medium: 364 mm x 515 mm\r
+ 'jis-b3-transparent': Specifies the JIS B3 transparent medium: 364 mm\r
+ x 515 mm\r
+ 'jis-b3-translucent': Specifies the JIS B3 translucent medium: 364 mm\r
+ x 515 mm\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 192]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'jis-b4-transparent': Specifies the JIS B4 transparent medium: 257 mm\r
+ x 364 mm\r
+ 'jis-b4-translucent': Specifies the JIS B4 translucent medium: 257 mm\r
+ x 364 mm\r
+ 'jis-b5-transparent': Specifies the JIS B5 transparent medium: 182 mm\r
+ x 257 mm\r
+ 'jis-b5-translucent': Specifies the JIS B5 translucent medium: 182 mm\r
+ x 257 mm\r
+ 'jis-b6-white': Specifies the JIS B6 white medium: 128 mm x 182 mm\r
+ 'jis-b7-white': Specifies the JIS B7 white medium: 91 mm x 128 mm\r
+ 'jis-b8-white': Specifies the JIS B8 white medium: 64 mm x 91 mm\r
+ 'jis-b9-white': Specifies the JIS B9 white medium: 45 mm x 64 mm\r
+ 'jis-b10-white': Specifies the JIS B10 white medium: 32 mm x 45 mm\r
+\r
+ The following standard values are defined for American Standard (i.e.\r
+ ANSI) engineering media:\r
+\r
+ 'a-white': Specifies the engineering ANSI A size white medium: 8.5\r
+ inches x 11 inches\r
+ 'a-transparent': Specifies the engineering ANSI A size transparent\r
+ medium: 8.5 inches x 11 inches\r
+ 'a-translucent': Specifies the engineering ANSI A size translucent\r
+ medium: 8.5 inches x 11 inches\r
+ 'b-white': Specifies the engineering ANSI B size white medium: 11\r
+ inches x 17 inches\r
+ 'b-transparent': Specifies the engineering ANSI B size transparent\r
+ medium: 11 inches x 17 inches)\r
+ 'b-translucent': Specifies the engineering ANSI B size translucent\r
+ medium: 11 inches x 17 inches\r
+ 'c-white': Specifies the engineering ANSI C size white medium: 17\r
+ inches x 22 inches\r
+ 'c-transparent': Specifies the engineering ANSI C size transparent\r
+ medium: 17 inches x 22 inches\r
+ 'c-translucent': Specifies the engineering ANSI C size translucent\r
+ medium: 17 inches x 22 inches\r
+ 'd-white': Specifies the engineering ANSI D size white medium: 22\r
+ inches x 34 inches\r
+ 'd-transparent': Specifies the engineering ANSI D size transparent\r
+ medium: 22 inches x 34 inches\r
+ 'd-translucent': Specifies the engineering ANSI D size translucent\r
+ medium: 22 inches x 34 inches\r
+ 'e-white': Specifies the engineering ANSI E size white medium: 34\r
+ inches x 44 inches\r
+ 'e-transparent': Specifies the engineering ANSI E size transparent\r
+ medium: 34 inches x 44 inches\r
+ 'e-translucent': Specifies the engineering ANSI E size translucent\r
+ medium: 34 inches x 44 inches\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 193]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The following standard values are defined for American Standard (i.e.\r
+ ANSI) engineering media for devices that provide the "synchro-cut"\r
+ feature (see section 14.1):\r
+\r
+ 'axsynchro-white': Specifies the roll paper having the width of the\r
+ longer edge (11 inches) of the engineering ANSI A size white medium\r
+ and cuts synchronizing with data.\r
+ 'axsynchro-transparent': Specifies the roll paper having the width of\r
+ the longer edge (11 inches) of the engineering ANSI A size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'axsynchro-translucent': Specifies the roll paper having the width of\r
+ the longer edge (11 inches) of the engineering ANSI A size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'bxsynchro-white': Specifies the roll paper having the width of the\r
+ longer edge (17 inches) of the engineering ANSI B size white medium\r
+ and cuts synchronizing with data.\r
+ 'bxsynchro-transparent': Specifies the roll paper having the width of\r
+ the longer edge (17 inches) of the engineering ANSI B size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'bxsynchro-translucent': Specifies the roll paper having the width of\r
+ the longer edge (17 inches) of the engineering ANSI B size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'cxsynchro-white': Specifies the roll paper having the width of the\r
+ longer edge (22 inches) of the engineering ANSI C size white medium\r
+ and cuts synchronizing with data.\r
+ 'cxsynchro-transparent': Specifies the roll paper having the width of\r
+ the longer edge (22 inches) of the engineering ANSI C size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'cxsynchro-translucent': Specifies the roll paper having the width of\r
+ the longer edge (22 inches) of the engineering ANSI C size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'dxsynchro-white': Specifies the roll paper having the width of the\r
+ longer edge (34 inches) of the engineering ANSI D size white medium\r
+ and cuts synchronizing with data.\r
+ 'dxsynchro-transparent': Specifies the roll paper having the width of\r
+ the longer edge (34 inches) of the engineering ANSI D size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'dxsynchro-translucent': Specifies the roll paper having the width of\r
+ the longer edge (34 inches) of the engineering ANSI D size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'exsynchro-white': Specifies the roll paper having the width of the\r
+ longer edge (44 inches) of the engineering ANSI E size white medium\r
+ and cuts synchronizing with data.\r
+ 'exsynchro-transparent': Specifies the roll paper having the width of\r
+ the longer edge (44 inches) of the engineering ANSI E size\r
+ transparent medium and cuts synchronizing with data.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 194]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'exsynchro-translucent': Specifies the roll paper having the width of\r
+ the longer edge (44 inches) of the engineering ANSI E size\r
+ translucent medium and cuts synchronizing with data.\r
+\r
+ The following standard values are defined for American Architectural\r
+ engineering media:\r
+\r
+ 'arch-a-white': Specifies the Architectural A size white medium: 9\r
+ inches x 12 inches\r
+ 'arch-a-transparent': Specifies the Architectural A size transparent\r
+ medium: 9 inches x 12 inches\r
+ 'arch-a-translucent': Specifies the Architectural A size translucent\r
+ medium: 9 inches x 12 inches\r
+ 'arch-b-white': Specifies the Architectural B size white medium: 12\r
+ inches x 18 inches\r
+ 'arch-b-transparent': Specifies the Architectural B size transparent\r
+ medium: 12 inches x 18 inches\r
+ 'arch-b-translucent': Specifies the Architectural B size translucent\r
+ medium: 12 inches x 18 inches\r
+ 'arch-c-white': Specifies the Architectural C size white medium: 18\r
+ inches x 24 inches\r
+ 'arch-c-transparent': Specifies the Architectural C size transparent\r
+ medium: 18 inches x 24 inches\r
+ 'arch-c-translucent': Specifies the Architectural C size translucent\r
+ medium: 18 inches x 24 inches\r
+ 'arch-d-white': Specifies the Architectural D size white medium: 24\r
+ inches x 36 inches\r
+ 'arch-d-transparent': Specifies the Architectural D size transparent\r
+ medium: 24 inches x 36 inches\r
+ 'arch-d-translucent': Specifies the Architectural D size translucent\r
+ medium: 24 inches x 36 inches\r
+ 'arch-e-white': Specifies the Architectural E size white medium: 36\r
+ inches x 48 inches\r
+ 'arch-e-transparent': Specifies the Architectural E size transparent\r
+ medium: 36 inches x 48 inches\r
+ 'arch-e-translucent': Specifies the Architectural E size translucent\r
+ medium: 36 inches x 48 inches\r
+\r
+ The following standard values are defined for American Architectural\r
+ engineering media for devices that provide the "synchro-cut" feature\r
+ (see section 14.1):\r
+\r
+ 'arch-axsynchro-white': Specifies the roll paper having the width of\r
+ the longer edge (12 inches) of the Architectural A size white\r
+ medium and cuts synchronizing with data.\r
+ 'arch-axsynchro-transparent': Specifies the roll paper having the\r
+ width of the longer edge (12 inches) of the Architectural A size\r
+ transparent medium and cuts synchronizing with data.\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 195]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'arch-axsynchro-translucent': Specifies the roll paper having the\r
+ width of the longer edge (12 inches) of the Architectural A size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'arch-bxsynchro-white': Specifies the roll paper having the width of\r
+ the longer edge (18 inches) of the Architectural B size white\r
+ medium and cuts synchronizing with data.\r
+ 'arch-bxsynchro-transparent': Specifies the roll paper having the\r
+ width of the longer edge (18 inches) of the Architectural B size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'arch-bxsynchro-translucent': Specifies the roll paper having the\r
+ width of the longer edge (18 inches) of the Architectural B size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'arch-cxsynchro-white': Specifies the roll paper having the width of\r
+ the longer edge (24 inches) of the Architectural C size white\r
+ medium and cuts synchronizing with data.\r
+ 'arch-cxsynchro-transparent': Specifies the roll paper having the\r
+ width of the longer edge (24 inches) of the Architectural C size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'arch-cxsynchro-translucent': Specifies the roll paper having the\r
+ width of the longer edge (24 inches) of the Architectural C size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'arch-dxsynchro-white': Specifies the roll paper having the width of\r
+ the longer edge (36 inches) of the Architectural D size white\r
+ medium and cuts synchronizing with data.\r
+ 'arch-dxsynchro-transparent': Specifies the roll paper having the\r
+ width of the longer edge (36 inches) of the Architectural D size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'arch-dxsynchro-translucent': Specifies the roll paper having the\r
+ width of the longer edge (36 inches) of the Architectural D size\r
+ translucent medium and cuts synchronizing with data.\r
+ 'arch-exsynchro-white': Specifies the roll paper having the width of\r
+ the longer edge (48 inches) of the Architectural E size white\r
+ medium and cuts synchronizing with data.\r
+ 'arch-exsynchro-transparent': Specifies the roll paper having the\r
+ width of the longer edge (48 inches) of the Architectural E size\r
+ transparent medium and cuts synchronizing with data.\r
+ 'arch-exsynchro-translucent': Specifies the roll paper having the\r
+ width of the longer edge (48 inches) of the Architectural E size\r
+ translucent medium and cuts synchronizing with data.\r
+\r
+ The following standard values are defined for Japanese and European\r
+ Standard (i.e. ISO) engineering media, which are of a long fixed size\r
+ [ASME-Y14.1M]:\r
+\r
+ 'iso-a1x3-white': Specifies the ISO A1X3 white medium having the\r
+ width of the longer edge (841 mm) of the ISO A1 medium\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 196]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'iso-a1x3-transparent': Specifies the ISO A1X3 transparent medium\r
+ having the width of the longer edge (841 mm) of the ISO A1\r
+ medium\r
+ 'iso-a1x3-translucent': Specifies the ISO A1X3 translucent medium\r
+ having the width of the longer edge (841 mm) of the ISO A1\r
+ medium\r
+ 'iso-a1x4-white': Specifies the ISO A1X4 white medium having the\r
+ width of the longer edge (841 mm) of the ISO A1 medium\r
+ 'iso-a1x4-transparent': Specifies the ISO A1X4 transparent medium\r
+ having the width of the longer edge (841 mm) of the ISO A1\r
+ medium\r
+ 'iso-a1x4- translucent': Specifies the ISO A1X4 translucent medium\r
+ having the width of the longer edge (841 mm) of the ISO A1\r
+ medium\r
+ 'iso-a2x3-white': Specifies the ISO A2X3 white medium having the\r
+ width of the longer edge (594 mm) of the ISO A2 medium\r
+ 'iso-a2x3-transparent': Specifies the ISO A2X3 transparent medium\r
+ having the width of the longer edge (594 mm) of the ISO A2\r
+ medium\r
+ 'iso-a2x3-translucent': Specifies the ISO A2X3 translucent medium\r
+ having the width of the longer edge (594 mm) of the ISO A2\r
+ medium\r
+ 'iso-a2x4-white': Specifies the ISO A2X4 white medium having the\r
+ width of the longer edge (594 mm) of the ISO A2 medium\r
+ 'iso-a2x4-transparent': Specifies the ISO A2X4 transparent medium\r
+ having the width of the longer edge (594 mm) of the ISO A2\r
+ medium\r
+ 'iso-a2x4-translucent': Specifies the ISO A2X4 translucent medium\r
+ having the width of the longer edge (594 mm) of the ISO A2\r
+ medium\r
+ 'iso-a2x5-white': Specifies the ISO A2X5 white medium having the\r
+ width of the longer edge (594 mm) of the ISO A2 medium\r
+ 'iso-a2x5-transparent': Specifies the ISO A2X5 transparent medium\r
+ having the width of the longer edge (594 mm) of the ISO A2\r
+ medium\r
+ 'iso-a2x5-translucent': Specifies the ISO A2X5 translucent medium\r
+ having the width of the longer edge (594 mm) of the ISO A2\r
+ medium\r
+ 'iso-a3x3-white': Specifies the ISO A3X3 white medium having the\r
+ width of the longer edge (420 mm) of the ISO A3 medium\r
+ 'iso-a3x3-transparent': Specifies the ISO A3X3 transparent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x3-translucent': Specifies the ISO A3X3 translucent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x4-white': Specifies the ISO A3X4 white medium having the\r
+ width of the longer edge (420 mm) of the ISO A3 medium\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 197]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'iso-a3x4-transparent': Specifies the ISO A3X4 transparent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x4-translucent': Specifies the ISO A3X4 translucent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x5-white': Specifies the ISO A3X5 white medium having the\r
+ width of the longer edge (420 mm) of the ISO A3 medium\r
+ 'iso-a3x5-transparent': Specifies the ISO A3X5 transparent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x5-translucent': Specifies the ISO A3X5 translucent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x6-white': Specifies the ISO A3X6 white medium having the\r
+ width of the longer edge (420 mm) of the ISO A3 medium\r
+ 'iso-a3x6-transparent': Specifies the ISO A3X6 transparent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x6-translucent': Specifies the ISO A3X6 translucent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x7-white': Specifies the ISO A3X7 white medium having the\r
+ width of the longer edge (420 mm) of the ISO A3 medium\r
+ 'iso-a3x7-transparent': Specifies the ISO A3X7 transparent medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a3x7-translucent'': Specifies the ISO A3X7 translucent' medium\r
+ having the width of the longer edge (420 mm) of the ISO A3\r
+ medium\r
+ 'iso-a4x3-white': Specifies the ISO A4X3 white medium having the\r
+ width of the longer edge (297 mm) of the ISO A4 medium\r
+ 'iso-a4x3-transparent': Specifies the ISO A4X3 transparent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x3-translucent'': Specifies the ISO A4X3 translucent' medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x4-white': Specifies the ISO A4X4 white medium having the\r
+ width of the longer edge (297 mm) of the ISO A4 medium\r
+ 'iso-a4x4-transparent': Specifies the ISO A4X4 transparent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x4-translucent': Specifies the ISO A4X4 translucent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x5-white': Specifies the ISO A4X5 white medium having the\r
+ width of the longer edge (297 mm) of the ISO A4 medium\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 198]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'iso-a4x5-transparent': Specifies the ISO A4X5 transparent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x5-translucent': Specifies the ISO A4X5 translucent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x6-white': Specifies the ISO A4X6 white medium having the\r
+ width of the longer edge (297 mm) of the ISO A4 medium\r
+ 'iso-a4x6-transparent': Specifies the ISO A4X6 transparent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x6-translucent': Specifies the ISO A4X6 translucent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x7-white': Specifies the ISO A4X7 white medium having the\r
+ width of the longer edge (297 mm) of the ISO A4 medium\r
+ 'iso-a4x7-transparent': Specifies the ISO A4X7 transparent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x7-translucent': Specifies the ISO A4X7 translucent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x8-white': Specifies the ISO A4X8 white medium having the\r
+ width of the longer edge (297 mm) of the ISO A4 medium\r
+ 'iso-a4x8-transparent': Specifies the ISO A4X8 transparent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x8-translucent': Specifies the ISO A4X8 translucent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x9-white': Specifies the ISO A4X9 white medium having the\r
+ width of the longer edge (297 mm) of the ISO A4 medium\r
+ 'iso-a4x9-transparent': Specifies the ISO A4X9 transparent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+ 'iso-a4x9-translucent': Specifies the ISO A4X9 translucent medium\r
+ having the width of the longer edge (297 mm) of the ISO A4\r
+ medium\r
+\r
+ The following standard values are defined for Japanese and European\r
+ Standard (i.e. ISO) engineering media, which are either a long fixed\r
+ size [ASME-Y14.1M] or roll feed, for devices that provide the\r
+ "synchro-cut" feature (see section 14.1):\r
+\r
+ 'iso-a0xsynchro-white': Specifies the paper having the width of the\r
+ longer edge (1189 mm) of the ISO A0 white medium and cuts\r
+ synchronizing with data.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 199]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'iso-a0xsynchro-transparent': Specifies the paper having the width of\r
+ the longer edge (1189 mm) of the ISO A0 transparent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a0xsynchro-translucent': Specifies the paper having the width of\r
+ the longer edge (1189 mm) of the ISO A0 translucent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a1xsynchro-white': Specifies the paper having the width of the\r
+ longer edge (841 mm) of the ISO A1 white medium and cuts\r
+ synchronizing with data.\r
+ 'iso-a1xsynchro-transparent': Specifies the paper having the width of\r
+ the longer edge (841 mm) of the ISO A1 transparent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a1xsynchro-translucent': Specifies the paper having the width of\r
+ the longer edge (841 mm) of the ISO A1 translucent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a2xsynchro-white': Specifies the paper having the width of the\r
+ longer edge (594 mm) of the ISO A2 white medium and cuts\r
+ synchronizing with data.\r
+ 'iso-a2xsynchro-transparent': Specifies the paper having the width of\r
+ the longer edge (594 mm) of the ISO A2 transparent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a2xsynchro-translucent': Specifies the paper having the width of\r
+ the longer edge (594 mm) of the ISO A2 translucent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a3xsynchro-white': Specifies the paper having the width of the\r
+ longer edge (420 mm) of the ISO A3 white medium and cuts\r
+ synchronizing with data.\r
+ 'iso-a3xsynchro-transparent': Specifies the paper having the width of\r
+ the longer edge (420 mm) of the ISO A3 transparent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a3xsynchro-translucent': Specifies the paper having the width of\r
+ the longer edge (420 mm) of the ISO A3 translucent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a4xsynchro-white': Specifies the paper having the width of the\r
+ longer edge (297 mm) of the ISO A4 white medium and cuts\r
+ synchronizing with data.\r
+ 'iso-a4xsynchro-transparent': Specifies the paper having the width of\r
+ the longer edge (297 mm) of the ISO A4 transparent medium and\r
+ cuts synchronizing with data.\r
+ 'iso-a4xsynchro-translucent': Specifies the paper having the width of\r
+ the longer edge (297 mm) of the ISO A4 transparent medium and\r
+ cuts synchronizing with data.\r
+\r
+ The following standard values are defined for American Standard (i.e.\r
+ ANSI) engineering media, American Architectural engineering media,\r
+ and Japanese and European Standard (i.e. ISO) engineering media,\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 200]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ which are either a long fixed size [ASME-Y14.1M] or roll feed, for\r
+ devices that provide the "synchro-cut" feature and/or the "auto-\r
+ select" feature (see section 14.1):\r
+\r
+ 'auto-white': Specifies that the printer selects the white medium\r
+ with the appropriate fixed size (e.g. a1, a2, etc.) or data-\r
+ synchro size, and the selection is implementation-defined.\r
+ 'auto-transparent': Specifies that the printer selects the\r
+ transparent medium with the appropriate fixed size (e.g. a1, a2,\r
+ etc.) or data-synchro size, and the selection is implementation-\r
+ defined.\r
+ 'auto-translucent': Specifies that the printer selects the\r
+ translucent medium with the appropriate fixed size (e.g. a1, a2,\r
+ etc.) or data-synchro size, and the selection is implementation-\r
+ defined.\r
+ 'auto-fixed-size-white': Specifies that the printer selects the white\r
+ medium with the appropriate fixed size (e.g. a1, a2, etc.) or\r
+ the appropriate long fixed size listed above.\r
+ 'auto-fixed-size-transparent': Specifies that the printer selects the\r
+ transparent medium with the appropriate fixed size (e.g. a1, a2,\r
+ etc.) or the appropriate long fixed size listed above.\r
+ 'auto-fixed-size-translucent': Specifies that the printer selects the\r
+ translucent medium with the appropriate fixed size (e.g. a1, a2,\r
+ etc.) or the appropriate long fixed size listed above.\r
+ 'auto-synchro-white': Specifies that the printer selects the white\r
+ paper with the appropriate width and cuts it synchronizing with\r
+ data.\r
+ 'auto-synchro-transparent': Specifies that the printer selects the\r
+ transparent paper with the appropriate width and cuts it\r
+ synchronizing with data.\r
+ 'auto-synchro-translucent': Specifies that the printer selects the\r
+ translucent paper with the appropriate width and cuts it\r
+ synchronizing with data.\r
+\r
+ The following standard values are defined for input-trays (from ISO\r
+ DPA and the Printer MIB):\r
+\r
+ 'top': The top input tray in the printer.\r
+ 'middle': The middle input tray in the printer.\r
+ 'bottom': The bottom input tray in the printer.\r
+ 'envelope': The envelope input tray in the printer.\r
+ 'manual': The manual feed input tray in the printer.\r
+ 'large-capacity': The large capacity input tray in the printer.\r
+ 'main': The main input tray\r
+ 'side': The side input tray\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 201]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The following standard values are defined for media sizes (from ISO\r
+ DPA):\r
+\r
+ 'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined in\r
+ ISO 216\r
+ 'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in\r
+ ISO 216\r
+ 'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in\r
+ ISO 216\r
+ 'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in\r
+ ISO 216\r
+ 'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in\r
+ ISO 216\r
+ 'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in\r
+ ISO 216\r
+ 'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in\r
+ ISO 216\r
+ 'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in\r
+ ISO 216\r
+ 'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in ISO\r
+ 216\r
+ 'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in ISO\r
+ 216\r
+ 'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in\r
+ ISO 216\r
+ 'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined in\r
+ ISO 216\r
+ 'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined in\r
+ ISO 216\r
+ 'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in\r
+ ISO 216\r
+ 'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in\r
+ ISO 216\r
+ 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in\r
+ ISO 216\r
+ 'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in\r
+ ISO 216\r
+ 'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in\r
+ ISO 216\r
+ 'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in\r
+ ISO 216\r
+ 'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in ISO\r
+ 216\r
+ 'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in ISO\r
+ 216\r
+ 'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in\r
+ ISO 216\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 202]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'na-letter': Specifies the North American letter size: 8.5 inches by\r
+ 11 inches\r
+ 'na-legal': Specifies the North American legal size: 8.5 inches by 14\r
+ inches\r
+ 'na-8x10': Specifies the North American 8 inches by 10 inches\r
+ 'na-5x7': Specifies the North American 5 inches by 7 inches\r
+ 'executive': Specifies the executive size (7.25 X 10.5 in)\r
+ 'folio': Specifies the folio size (8.5 X 13 in)\r
+ 'invoice': Specifies the invoice size (5.5 X 8.5 in)\r
+ 'ledger': Specifies the ledger size (11 X 17 in)\r
+ 'quarto': Specifies the quarto size (8.5 X 10.83 in)\r
+ 'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in\r
+ ISO 269\r
+ 'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in\r
+ ISO 269\r
+ 'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in\r
+ ISO 269\r
+ 'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in\r
+ ISO 269\r
+ 'iso-designated-long': Specifies the ISO Designated Long size: 110 mm\r
+ by 220 mm as defined in ISO 269\r
+ 'na-10x13-envelope': Specifies the North American 10x13 size: 10\r
+ inches by 13 inches\r
+ 'na-9x12-envelope': Specifies the North American 9x12 size: 9 inches\r
+ by 12 inches\r
+ 'na-number-10-envelope': Specifies the North American number 10\r
+ business envelope size: 4.125 inches by 9.5 inches\r
+ 'na-7x9-envelope': Specifies the North American 7x9 inch envelope\r
+ size\r
+ 'na-9x11-envelope': Specifies the North American 9x11 inch envelope\r
+ size\r
+ 'na-10x14-envelope': Specifies the North American 10x14 inch envelope\r
+ size\r
+ 'na-number-9-envelope': Specifies the North American number 9\r
+ business envelope size\r
+ 'na-6x9-envelope': Specifies the North American 6x9 envelope size\r
+ 'na-10x15-envelope': Specifies the North American 10x15 envelope size\r
+ 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5\r
+ in)\r
+ 'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm\r
+ 'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm\r
+ 'jis-b2': Specifies the JIS B2 size: 515mm x 728mm\r
+ 'jis-b3': Specifies the JIS B3 size: 364mm x 515mm\r
+ 'jis-b4': Specifies the JIS B4 size: 257mm x 364mm\r
+ 'jis-b5': Specifies the JIS B5 size: 182mm x 257mm\r
+ 'jis-b6': Specifies the JIS B6 size: 128mm x 182mm\r
+ 'jis-b7': Specifies the JIS B7 size: 91mm x 128mm\r
+ 'jis-b8': Specifies the JIS B8 size: 64mm x 91mm\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 203]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 'jis-b9': Specifies the JIS B9 size: 45mm x 64mm\r
+ 'jis-b10': Specifies the JIS B10 size: 32mm x 45mm\r
+\r
+ The following standard values are defined for American Standard (i.e.\r
+ ANSI) engineering media sizes:\r
+\r
+ 'a': Specifies the engineering ANSI A size medium: 8.5 inches x 11\r
+ inches\r
+ 'b': Specifies the engineering ANSI B size medium: 11 inches x 17\r
+ inches\r
+ 'c': Specifies the engineering ANSI C size medium: 17 inches x 22\r
+ inches\r
+ 'd': Specifies the engineering ANSI D size medium: 22 inches x 34\r
+ inches\r
+ 'e': Specifies the engineering ANSI E size medium: 34 inches x 44\r
+ inches\r
+\r
+ The following standard values are defined for American Architectural\r
+ engineering media sizes:\r
+\r
+ 'arch-a': Specifies the Architectural A size medium: 9 inches x 12\r
+ inches\r
+ 'arch-b': Specifies the Architectural B size medium: 12 inches x 18\r
+ inches\r
+ 'arch-c': Specifies the Architectural C size medium: 18 inches x 24\r
+ inches\r
+ 'arch-d': Specifies the Architectural D size medium: 24 inches x 36\r
+ inches\r
+ 'arch-e': Specifies the Architectural E size medium: 36 inches x 48\r
+ inches\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 204]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+14.1. Examples\r
+\r
+ Below are examples to supplement the engineering media value\r
+ definitions.\r
+\r
+ Example 1: "Synchro-Cut", a device cutting the roll paper in\r
+ synchronization with the data\r
+\r
+ data height: A1 height\r
+ data width (shaded): A1 width < data width < (A1 width) x 2\r
+ specified value: 'iso-a1xsynchro-white'\r
+\r
+ | |\r
+ |<--- data width --->|\r
+ | |\r
+ | | | |\r
+ |<- A1 width ->|<- A1 width ->|\r
+ | | | |\r
+ cross ^ | | | |\r
+ feed | +--------------------------------------------/\r
+ direction | |//////////////|/////| | ^ /\r
+ | |//////////////|/////| | | /\r
+ | |//////////////|/////| | | /\r
+ | |//////////////|/////| | | \\r
+<-----------+- |//////////////|/////| | A1 \ roll\r
+feed | |//////////////|/////| | height \ paper\r
+direction |//////////////|/////| | | \\r
+ |//////////////|/////| | | /\r
+ |//////////////|/////| | v /\r
+ +------------------------------------------/\r
+ |\r
+ |\r
+ |<------ CUT HERE (to synchronize\r
+ | with data width)\r
+ |\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 205]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Example 2: "Auto-Cut", a device cutting the roll paper at multiples\r
+ of fixed-size media width\r
+\r
+ data height: A1 height\r
+ data width (shaded): A1 width < data width < (A1 width) x 2\r
+ specified value: 'auto-fixed-size-white'\r
+\r
+ | |\r
+ |<--- data width --->|\r
+ | |\r
+ | | | |\r
+ |<- A1 width ->|<- A1 width ->|\r
+ | | | |\r
+ cross ^ | | | |\r
+ feed | +--------------------------------------------/\r
+ direction | |//////////////|/////| | ^ /\r
+ | |//////////////|/////| | | /\r
+ | |//////////////|/////| | | /\r
+ | |//////////////|/////| | | \\r
+<-----------+- |//////////////|/////| | A1 \ roll\r
+feed | |//////////////|/////| | height \ paper\r
+direction |//////////////|/////| | | \\r
+ |//////////////|/////| | | /\r
+ |//////////////|/////| | v /\r
+ +------------------------------------------/\r
+ |\r
+ |\r
+ |<--- CUT HERE\r
+ | (to synchronize\r
+ | with data width)\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 206]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Example 3: the 'iso-a4x4-white' fixed size paper\r
+\r
+ paper height: A4 height\r
+ paper width: (A4 width) x 4\r
+ specified value: 'iso-a4x4-white'\r
+\r
+ | | | | |\r
+ |<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->|\r
+ | | | | |\r
+ | | | | |\r
+ +-----------------------------------------------------------+\r
+ | ^ | | | |\r
+ | | | | | |\r
+ | | | | | |\r
+ | A4 | | | |\r
+ | height | | | |\r
+ | | | | | |\r
+ | | | | | |\r
+ | | | | | |\r
+ | v | | | |\r
+ +-----------------------------------------------------------+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 207]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Example 4: "Synchro-Cut", a device cutting the fixed size paper in\r
+ synchronization with the data\r
+\r
+ data height: A4 height\r
+ data width (shaded): (A4 width) x 2 < data width < (A4 width) x 3\r
+ specified value: 'iso-a4xsynchro-white'\r
+\r
+ | |\r
+ |<---------- data width ----------->|\r
+ | |\r
+ | | | | |\r
+ |<- A4 width ->|<- A4 width ->|<- A4 width ->|\r
+ | | | | |\r
+ cross ^ | | | | |\r
+ feed | +--------------------------------------------+\r
+ direction | |//////////////|//////////////|/////| ^ |\r
+ | |//////////////|//////////////|/////| | |\r
+ | |//////////////|//////////////|/////| | |\r
+ | |//////////////|//////////////|/////| | |\r
+ <-----------+- |//////////////|//////////////|/////| A4 |\r
+ feed | |//////////////|//////////////|/////| height |\r
+ direction |//////////////|//////////////|/////| | |\r
+ |//////////////|//////////////|/////| | |\r
+ |//////////////|//////////////|/////| v |\r
+ +--------------------------------------------+\r
+ |\r
+ CUT HERE ---->|\r
+ (to synchronize |\r
+ with data width) |\r
+\r
+15. APPENDIX D: Processing IPP Attributes\r
+\r
+ When submitting a print job to a Printer object, the IPP model allows\r
+ a client to supply operation and Job Template attributes along with\r
+ the document data. These Job Template attributes in the create\r
+ request affect the rendering, production and finishing of the\r
+ documents in the job. Similar types of instructions may also be\r
+ contained in the document to be printed, that is, embedded within the\r
+ print data itself. In addition, the Printer has a set of attributes\r
+ that describe what rendering and finishing options which are\r
+ supported by that Printer. This model, which allows for flexibility\r
+ and power, also introduces the potential that at job submission time,\r
+ these client-supplied attributes may conflict with either:\r
+\r
+ - what the implementation is capable of realizing (i.e., what the\r
+ Printer supports), as well as\r
+ - the instructions embedded within the print data itself.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 208]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The following sections describe how these two types of conflicts are\r
+ handled in the IPP model.\r
+\r
+15.1 Fidelity\r
+\r
+ If there is a conflict between what the client requests and what a\r
+ Printer object supports, the client may request one of two possible\r
+ conflict handling mechanisms:\r
+\r
+ 1) either reject the job since the job can not be processed\r
+ exactly as specified, or\r
+ 2) allow the Printer to make any changes necessary to proceed with\r
+ processing the Job the best it can.\r
+\r
+ In the first case the client is indicating to the Printer object:\r
+ "Print the job exactly as specified with no exceptions, and if that\r
+ can't be done, don't even bother printing the job at all." In the\r
+ second case, the client is indicating to the Printer object: "It is\r
+ more important to make sure the job is printed rather than be\r
+ processed exactly as specified; just make sure the job is printed\r
+ even if some client-supplied attributes need to be changed or\r
+ ignored."\r
+\r
+ The IPP model accounts for this situation by introducing an "ipp-\r
+ attribute-fidelity" attribute.\r
+\r
+ In a create request, "ipp-attribute-fidelity" is a boolean operation\r
+ attribute that is OPTIONALLY supplied by the client. The value\r
+ 'true' indicates that total fidelity to client supplied Job Template\r
+ attributes and values is required. The client is requesting that the\r
+ Job be printed exactly as specified, and if that is not possible then\r
+ the job MUST be rejected rather than processed incorrectly. The\r
+ value 'false' indicates that a reasonable attempt to print the Job is\r
+ acceptable. If a Printer does not support some of the client\r
+ supplied Job Template attributes or values, the Printer MUST ignore\r
+ them or substitute any supported value for unsupported values,\r
+ respectively. The Printer may choose to substitute the default value\r
+ associated with that attribute, or use some other supported value\r
+ that is similar to the unsupported requested value. For example, if\r
+ a client supplies a "media" value of 'na-letter', the Printer may\r
+ choose to substitute 'iso-a4' rather than a default value of\r
+ 'envelope'. If the client does not supply the "ipp-attribute-\r
+ fidelity" attribute, the Printer assumes a value of 'false'.\r
+\r
+ Each Printer implementation MUST support both types of "fidelity"\r
+ printing (that is whether the client supplies a value of 'true' or\r
+ 'false'):\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 209]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ - If the client supplies 'false' or does not supply the attribute,\r
+ the Printer object MUST always accept the request by ignoring\r
+ unsupported Job Template attributes and by substituting\r
+ unsupported values of supported Job Template attributes with\r
+ supported values.\r
+ - If the client supplies 'true', the Printer object MUST reject\r
+ the request if the client supplies unsupported Job Template\r
+ attributes.\r
+\r
+ Since a client can always query a Printer to find out exactly what is\r
+ and is not supported, "ipp-attribute-fidelity" set to 'false' is\r
+ useful when:\r
+\r
+ 1) The End-User uses a command line interface to request\r
+ attributes that might not be supported.\r
+ 2) In a GUI context, if the End User expects the job might be\r
+ moved to another printer and prefers a sub-optimal result to\r
+ nothing at all.\r
+ 3) The End User just wants something reasonable in lieu of nothing\r
+ at all.\r
+\r
+15.2 Page Description Language (PDL) Override\r
+\r
+ If there is a conflict between the value of an IPP Job Template\r
+ attribute and a corresponding instruction in the document data, the\r
+ value of the IPP attribute SHOULD take precedence over the document\r
+ instruction. Consider the case where a previously formatted file of\r
+ document data is sent to an IPP Printer. In this case, if the client\r
+ supplies any attributes at job submission time, the client desires\r
+ that those attributes override the embedded instructions. Consider\r
+ the case were a previously formatted document has embedded in it\r
+ commands to load 'iso-a4' media. However, the document is passed to\r
+ an end user that only has access to a printer with 'na-letter' media\r
+ loaded. That end user most likely wants to submit that document to\r
+ an IPP Printer with the "media" Job Template attribute set to 'na-\r
+ letter'. The job submission attribute should take precedence over\r
+ the embedded PDL instruction. However, until companies that supply\r
+ document data interpreters allow a way for external IPP attributes to\r
+ take precedence over embedded job production instructions, a Printer\r
+ might not be able to support the semantics that IPP attributes\r
+ override the embedded instructions.\r
+\r
+ The IPP model accounts for this situation by introducing a "pdl-\r
+ override-supported" attribute that describes the Printer objects\r
+ capabilities to override instructions embedded in the PDL data\r
+ stream. The value of the "pdl-override-supported" attribute is\r
+ configured by means outside the scope of this IPP/1.1 document.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 210]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ This REQUIRED Printer attribute takes on the following values:\r
+\r
+ - 'attempted': This value indicates that the Printer object\r
+ attempts to make the IPP attribute values take precedence over\r
+ embedded instructions in the document data, however there is no\r
+ guarantee.\r
+ - 'not-attempted': This value indicates that the Printer object\r
+ makes no attempt to make the IPP attribute values take\r
+ precedence over embedded instructions in the document data.\r
+\r
+ At job processing time, an implementation that supports the value of\r
+ 'attempted' might do one of several different actions:\r
+\r
+ 1) Generate an output device specific command sequence to realize\r
+ the feature represented by the IPP attribute value.\r
+ 2) Parse the document data itself and replace the conflicting\r
+ embedded instruction with a new embedded instruction that\r
+ matches the intent of the IPP attribute value.\r
+ 3) Indicate to the Printer that external supplied attributes take\r
+ precedence over embedded instructions and then pass the\r
+ external IPP attribute values to the document data interpreter.\r
+ 4) Anything else that allows for the semantics that IPP attributes\r
+ override embedded document data instructions.\r
+\r
+ Since 'attempted' does not offer any type of guarantee, even though a\r
+ given Printer object might not do a very "good" job of attempting to\r
+ ensure that IPP attributes take a higher precedence over instructions\r
+ embedded in the document data, it would still be a conforming\r
+ implementation.\r
+\r
+ At job processing time, an implementation that supports the value of\r
+ 'not-attempted' might do one of the following actions:\r
+\r
+ 1) Simply pre-pend the document data with the PDL instruction that\r
+ corresponds to the client-supplied PDL attribute, such that if\r
+ the document data also has the same PDL instruction, it will\r
+ override what the Printer object pre-pended. In other words,\r
+ this implementation is using the same implementation semantics\r
+ for the client-supplied IPP attributes as for the Printer\r
+ object defaults.\r
+\r
+ 2) Parse the document data and replace the conflicting embedded\r
+ instruction with a new embedded instruction that approximates,\r
+ but does not match, the semantic intent of the IPP attribute\r
+ value.\r
+\r
+ Note: The "ipp-attribute-fidelity" attribute applies to the\r
+ Printer's ability to either accept or reject other unsupported Job\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 211]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ Template attributes. In other words, if "ipp-attribute-fidelity" is\r
+ set to 'true', a Job is accepted if and only if the client supplied\r
+ Job Template attributes and values are supported by the Printer.\r
+ Whether these attributes actually affect the processing of the Job\r
+ when the document data contains embedded instructions depends on the\r
+ ability of the Printer to override the instructions embedded in the\r
+ document data with the semantics of the IPP attributes. If the\r
+ document data attributes can be overridden ("pdl-override-supported"\r
+ set to 'attempted'), the Printer makes an attempt to use the IPP\r
+ attributes when processing the Job. If the document data attributes\r
+ can not be overridden ("pdl-override-supported" set to 'not-\r
+ attempted'), the Printer makes no attempt to override the embedded\r
+ document data instructions with the IPP attributes when processing\r
+ the Job, and hence, the IPP attributes may fail to affect the Job\r
+ processing and output when the corresponding instruction is embedded\r
+ in the document data.\r
+\r
+15.3 Using Job Template Attributes During Document Processing.\r
+\r
+ The Printer object uses some of the Job object's Job Template\r
+ attributes during the processing of the document data associated with\r
+ that job. These include, but are not limited to, "orientation-\r
+ requested", "number-up", "sides", "media", and "copies". The\r
+ processing of each document in a Job Object MUST follow the steps\r
+ below. These steps are intended only to identify when and how\r
+ attributes are to be used in processing document data and any\r
+ alternative steps that accomplishes the same effect can be used to\r
+ implement this specification document.\r
+\r
+ 1. Using the client supplied "document-format" attribute or some\r
+ form of document format detection algorithm (if the value of\r
+ "document-format" is not specific enough), determine whether or\r
+ not the document data has already been formatted for printing.\r
+ If the document data has been formatted, then go to step 2.\r
+ Otherwise, the document data MUST be formatted. The formatting\r
+ detection algorithm is implementation defined and is not\r
+ specified by this document. The formatting of the document\r
+ data uses the "orientation-requested" attribute to determine\r
+ how the formatted print data should be placed on a print-stream\r
+ page, see section 4.2.10 for the details.\r
+\r
+ 2. The document data is in the form of a print-stream in a known\r
+ media type. The "page-ranges" attribute is used to select, as\r
+ specified in section 4.2.7, a sub-sequence of the pages in the\r
+ print-stream that are to be processed and images.\r
+\r
+ 3. The input to this step is a sequence of print-stream pages.\r
+ This step is controlled by the "number-up" attribute. If the\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 212]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ value of "number-up" is N, then during the processing of the\r
+ print-stream pages, each N print-stream pages are positioned,\r
+ as specified in section 4.2.9, to create a single impression.\r
+ If a given document does not have N more print-stream pages,\r
+ then the completion of the impression is controlled by the\r
+ "multiple-document-handling" attribute as described in section\r
+ 4.2.4; when the value of this attribute is 'single-document' or\r
+ 'single-document-new-sheet', the print-stream pages of document\r
+ data from subsequent documents is used to complete the\r
+ impression.\r
+\r
+ The size(scaling), position(translation) and rotation of the\r
+ print-stream pages on the impression is implementation defined.\r
+ Note that during this process the print-stream pages may be\r
+ rendered to a form suitable for placing on the impression; this\r
+ rendering is controlled by the values of the "printer-\r
+ resolution" and "print-quality" attributes as described in\r
+ sections 4.2.12 and 4.2.13. In the case N=1, the impression is\r
+ nearly the same as the print-stream page; the differences would\r
+ only be in the size, position and rotation of the print-stream\r
+ page and/or any decoration, such as a frame to the page, that\r
+ is added by the implementation.\r
+\r
+ 4. The collection of impressions is placed, in sequence, onto\r
+ sides of the media sheets. This placement is controlled by the\r
+ "sides" attribute and the orientation of the print-stream page,\r
+ as described in section 4.2.8. The orientation of the print-\r
+ stream pages affects the orientation of the impression; for\r
+ example, if "number-up" equals 2, then, typically, two portrait\r
+ print-stream pages become one landscape impression. Note that\r
+ the placement of impressions onto media sheets is also\r
+ controlled by the "multiple-document-handling" attribute as\r
+ described in section 4.2.4.\r
+\r
+ 5. The "copies" and "multiple-document-handling" attributes are\r
+ used to determine how many copies of each media instance are\r
+ created and in what order. See sections 4.2.5 and 4.2.4 for the\r
+ details.\r
+\r
+ 6. When the correct number of copies are created, the media\r
+ instances are finished according to the values of the\r
+ "finishings" attribute as described in 4.2.6. Note that\r
+ sometimes finishing operations may require manual intervention\r
+ to perform the finishing operations on the copies, especially\r
+ uncollated copies. This document allows any or all of the\r
+ processing steps to be performed automatically or manually at\r
+ the discretion of the Printer object.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 213]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+16. APPENDIX E: Generic Directory Schema\r
+\r
+ This section defines a generic schema for an entry in a directory\r
+ service. A directory service is a means by which service users can\r
+ locate service providers. In IPP environments, this means that IPP\r
+ Printers can be registered (either automatically or with the help of\r
+ an administrator) as entries of type printer in the directory using\r
+ an implementation specific mechanism such as entry attributes, entry\r
+ type fields, specific branches, etc. Directory clients can search or\r
+ browse for entries of type printer. Clients use the directory\r
+ service to find entries based on naming, organizational contexts, or\r
+ filtered searches on attribute values of entries. For example, a\r
+ client can find all printers in the "Local Department" context.\r
+ Authentication and authorization are also often part of a directory\r
+ service so that an administrator can place limits on end users so\r
+ that they are only allowed to find entries to which they have certain\r
+ access rights. IPP itself does not require any specific directory\r
+ service protocol or provider.\r
+\r
+ Note: Some directory implementations allow for the notion of\r
+ "aliasing". That is, one directory entry object can appear as\r
+ multiple directory entry object with different names for each object.\r
+ In each case, each alias refers to the same directory entry object\r
+ which refers to a single IPP Printer object.\r
+\r
+ The generic schema is a subset of IPP Printer Job Template and\r
+ Printer Description attributes (sections 4.2 and 4.4). These\r
+ attributes are identified as either RECOMMENDED or OPTIONAL for the\r
+ directory entry itself. This conformance labeling is NOT the same\r
+ conformance labeling applied to the attributes of IPP Printers\r
+ objects. The conformance labeling in this Appendix is intended to\r
+ apply to directory templates and to IPP Printer implementations that\r
+ subscribe by adding one or more entries to a directory. RECOMMENDED\r
+ attributes SHOULD be associated with each directory entry. OPTIONAL\r
+ attributes MAY be associated with the directory entry (if known or\r
+ supported). In addition, all directory entry attributes SHOULD\r
+ reflect the current attribute values for the corresponding Printer\r
+ object.\r
+\r
+ The names of attributes in directory schema and entries SHOULD be the\r
+ same as the IPP Printer attribute names as shown, as much as\r
+ possible.\r
+\r
+ In order to bridge between the directory service and the IPP Printer\r
+ object, one of the RECOMMENDED directory entry attributes is the\r
+ Printer object's "printer-uri-supported" attribute. The directory\r
+ client queries the "printer-uri-supported" attribute (or its\r
+ equivalent) in the directory entry and then the IPP client addresses\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 214]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ the IPP Printer object using one of its URIs. The "uri-security-\r
+ supported" attribute identifies the protocol (if any) used to secure\r
+ a channel.\r
+\r
+ The following attributes define the generic schema for directory\r
+ entries of type PRINTER:\r
+\r
+ printer-uri-supported RECOMMENDED Section 4.4.1\r
+ uri-authentication-supported RECOMMENDED Section 4.4.2\r
+ uri-security-supported RECOMMENDED Section 4.4.3\r
+ printer-name RECOMMENDED Section 4.4.4\r
+ printer-location RECOMMENDED Section 4.4.5\r
+ printer-info OPTIONAL Section 4.4.6\r
+ printer-more-info OPTIONAL Section 4.4.7\r
+ printer-make-and-model RECOMMENDED Section 4.4.9\r
+ ipp-versions-supported RECOMMENDED Section 4.4.14\r
+ multiple-document-jobs-supported OPTIONAL Section 4.4.16\r
+ charset-supported OPTIONAL Section 4.4.18\r
+\r
+ generated-natural-language-\r
+ supported OPTIONAL Section 4.4.20\r
+ document-format-supported RECOMMENDED Section 4.4.22\r
+ color-supported RECOMMENDED Section 4.4.26\r
+ compression-supported RECOMMENDED Section 4.4.32\r
+ pages-per-minute OPTIONAL Section 4.4.36\r
+ pages-per-minute-color OPTIONAL Section 4.4.37\r
+\r
+ finishings-supported OPTIONAL Section 4.2.6\r
+ number-up-supported OPTIONAL Section 4.2.7\r
+ sides-supported RECOMMENDED Section 4.2.8\r
+ media-supported RECOMMENDED Section 4.2.11\r
+ printer-resolution-supported OPTIONAL Section 4.2.12\r
+ print-quality-supported OPTIONAL Section 4.2.13\r
+\r
+17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1 "Model and\r
+ Semantics" Documents\r
+\r
+ This Appendix is divided into two lists that summarize the\r
+ differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566].\r
+ The section numbers refer to the numbers in this document which in\r
+ some cases have changed from RFC 2566. When a change affects\r
+ multiple sections, the item is listed once in the order of the first\r
+ section affected and the remaining affected section numbers are\r
+ indicated.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 215]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ The first list contains extensions and clarifications and the second\r
+ list contains changes in semantics or conformance. However, client\r
+ and IPP object implementations of IPP/1.0 MAY implement any of the\r
+ extensions and clarifications in this document.\r
+\r
+ The following extensions and clarifications have been incorporated\r
+ into this document:\r
+\r
+ 1. Section 2.1 - clarified that the term "client" can be either\r
+ contained in software controlled by an end user or a part of a\r
+ print server that controls devices.\r
+ 2. Section 2 - clarified that the term "IPP object" and "Printer\r
+ object" can either be embedded in a device object or part of a\r
+ print server that accepts IPP requests.\r
+ 3. Section 2.4 - added the description of the new "uri-\r
+ authentication-supported" Printer Description attribute.\r
+ 4. Section 3.1.3, 3.1.6, 3.2.5.2, and 3.2.6.2 - clarified the\r
+ error handling for operation attributes that have their own\r
+ status code.\r
+ 5. Section 3.1.3 - clarified that multiple occurrences of the\r
+ same attribute in an attribute group is mal-formed. An IPP\r
+ Printer MAY reject the request or choose one of the\r
+ attributes.\r
+ 6. Section 3.1.6 - reorganized this section into sub-sections to\r
+ separately describe "status-code", "status-message",\r
+ "detailed-status-message", and "document-access-error"\r
+ attributes.\r
+ 7. Section 3.1.6.1 - clarified the error status codes and their\r
+ relationship to operation attributes.\r
+ 8. Section 3.1.6.3 - Added the OPTIONAL "detailed-status-message\r
+ (text(MAX))" operation attribute to provide additional more\r
+ detailed information about a response.\r
+ 9. Section 3.1.6.4 and 3.2.2 - Added the OPTIONAL "document-\r
+ access-error (text(MAX))" operation attribute for use with\r
+ Print-URI and Send-URI responses.\r
+ 10. Sections 3.1.7 - Added this new section to clarify returning\r
+ Unsupported Attributes for all operations, including only\r
+ returning attributes that were in the request. Moved the text\r
+ from section 3.2.1.2 Unsupported Attributes to this section.\r
+ 11. Sections 3.1.7 and 4.1 - clarified the encoding of the "out-\r
+ of-band" 'unsupported' and 'unknown' values.\r
+ 12. Section 3.1.8 - clarified that only the version number\r
+ parameter will be carried forward into future major or minor\r
+ versions of the protocol.\r
+ 13. Section 3.1.8 - relaxed the requirements to increment the\r
+ major version number in future versions of the Model and\r
+ Semantics document.\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 216]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 14. Section 3.1.9, and 3.2.5 - added the 'processing' state to the\r
+ list of job states that a job can be in after a Create-Job\r
+ operation.\r
+ 15. Section 3.1.9 - clarified that a non-spooling Printer MAY\r
+ accept zero or more subsequent jobs while processing a job and\r
+ flow control them down. Subsequent create requests are\r
+ rejected with the 'server-error-busy' error status.\r
+ 16. Section 3.2.1.1 - clarified the validation of the\r
+ "compression" operation attribute and its relationship to the\r
+ validation of the "document-format" attribute and returning\r
+ Unsupported Attributes.\r
+ 17. Sections 3.2.1.1, 4.3.8, 13.1.4.16, and 13.1.4.17 - added the\r
+ 'client-error-compression-not-supported', 'client-error-\r
+ compression-error' status codes and the 'unsupported-\r
+ compression' and 'compression-error' job-state-reasons.\r
+ 18. Sections 3.2.1.1 and 4.3.8 - added 'unsupported-document-\r
+ format' and 'document-format-error' job-state-reasons.\r
+ 19. Sections 3.2.2, 4.3.8 and 13.1.4.19 - added 'client-error-\r
+ document-access-error' status code and 'document-access-error'\r
+ job state reason.\r
+ 20. Section 3.2.5.2 and 3.2.6.2 - clarified that the Unsupported\r
+ Attributes group MUST NOT include attributes not requested in\r
+ the Get-Printer-Attributes request.\r
+ 21. Section 3.2.6 - clarified that "limit" takes precedence over\r
+ "which-jobs" and "my-jobs'.\r
+ 22. Section 3.2.6.2 - clarified that Get-Jobs returns\r
+ 'successful-ok' when no jobs to return.\r
+ 23. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause-\r
+ Printer, Resume-Printer, and Purge-Jobs operations\r
+ 24. Section 3.3.1 - clarified that the authorization required for\r
+ a Send-Document request MUST be the same user as the Create-\r
+ Job or an operator.\r
+ 25. Section 3.3.1.1 - clarified that a Create-Job Send-Document\r
+ with "last-document" = 'true' and no data is not an error; its\r
+ a job with no documents.\r
+ 26. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold-\r
+ Job, Release-Job, and Restart-Job operations. Clarified the\r
+ Restart-Job operation so that the Printer MUST re-fetch any\r
+ documents passed by-reference (Print-URI or Send-URI).\r
+ 27. Section 4.1 - clarified that the encoding of the out-of-band\r
+ values are specified in the Encoding and Transport" document.\r
+ 28. Section 4.1 - Clarified that the requirement that clients MUST\r
+ NOT send "out-of-band" values in requests applies only to\r
+ operations defined in this document. Other operations are\r
+ allowed to define "out-of-band" values that clients can\r
+ supply.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 217]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 29. Sections 4.1.1 and 4.1.2 - clarified that the maximum 'text'\r
+ and 'name' values of 1023 and 255 are for the\r
+ 'textWithoutLanguage' portion of the 'textWithLanguage' form,\r
+ so that the maximum number of octets for the actual text and\r
+ name data is the same for the without and with language forms;\r
+ the 'naturalLanguage' part is in addition.\r
+ 30. Section 4.1.9 - clarified that 'mimeMediaType' values can\r
+ include any parameters from the IANA Registry, not just\r
+ charset parameters.\r
+ 31. Section 4.1.9.1 - clarified that 'application/octet-stream'\r
+ auto-sensing can happen at create request time and/or\r
+ job/document processing time.\r
+ 32. Section 4.1.9.1 - clarified that auto-sensing involves the\r
+ Printer examining some number of octets of document data using\r
+ an implementation-dependent method.\r
+ 33. Section 4.1.14 - clarified that the localization of dateTime\r
+ by the client includes the time zone.\r
+ 34. Section 4.2 - clarified that xxx-supported have multiple\r
+ keywords and/or names by adding parentheses to the table to\r
+ give: (1setOf (type3 keyword | name))\r
+ 35. Section 4.2.2 - added the 'indefinite' keyword value to the\r
+ "job-hold-until" attribute for use with the create operations\r
+ and Hold-Job and Restart-Job operations.\r
+ 36. Section 4.2.6 - added more enum values to the "finishings" Job\r
+ Template attribute.\r
+ 37. Section 4.2.6 - clarified that the landscape definition is a\r
+ rotation of the image with respect to the medium.\r
+ 38. Section 4.3.7 - added that a forwarding server that cannot get\r
+ any job state MAY return the job's state as 'completed',\r
+ provided that it also return the new 'queued-in-device' job\r
+ state reason.\r
+ 39. Section 4.3.7.2 - added the Partitioning of Job States section\r
+ to clarify the concepts of Job Retention, Job History, and Job\r
+ Removal.\r
+ 40. Section 4.3.8 - added 'job-data-insufficient' job state reason\r
+ to indicate whether sufficient data has arrived for the\r
+ document to start to be processed.\r
+ 41. Section 4.3.8 - added 'document-access-error' job state reason\r
+ to indicate an access error of any kind.\r
+ 42. Section 4.3.8 - added 'job-queued-for-marker' job state reason\r
+ to indicate whether the job has completed some processing and\r
+ is waiting for the marker.\r
+ 43. Section 4.3.8 - added 'unsupported-compression' and\r
+ 'compression-error' job state reasons to indicate compression\r
+ not supported or compression processing error after the create\r
+ has been accepted.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 218]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 44. Section 4.3.8 - added 'unsupported-document-format' and\r
+ 'document-format-error' job state reasons to indicate document\r
+ not supported or document format processing error after the\r
+ create has been accepted.\r
+ 45. Section 4.3.8 - added 'queued-in-device' job state reason to\r
+ indicate that a job as been forwarded to a print system or\r
+ device that does not provide any job status.\r
+ 46. Section 4.3.10 - added "job-detailed-status-messages (1setOf\r
+ text(MAX)) for returning detailed error messages.\r
+ 47. Section 4.3.11 - added the "job-document-access-errors (1setOf\r
+ text(MAX))\r
+ 48. Section 4.3.14.2 - clarified that the time recorded is the\r
+ first time processing since the create operation or the\r
+ Restart-Job operation.\r
+ 49. Section 4.3.14.2 and 4.3.14.3 - clarified that the out-of-band\r
+ value 'no-value' is returned if the job has not started\r
+ processing or has not completed, respectively.\r
+ 50. Section 4.3.14 - Added the OPTIONAL "date-time-at-creation",\r
+ "date-time-at-processing", and "date-time-at-completed" Event\r
+ Time Job Description attributes\r
+ 51. Section 4.4.3 - added the 'tls' value to "uri-security-\r
+ supported" attribute.\r
+ 52. Section 4.4.3 - clarified "uri-security-supported" is\r
+ orthogonal to Client Authentication so that 'none' does not\r
+ exclude Client Authentication.\r
+ 53. Section 4.4.11 - simplified the "printer-state" descriptions\r
+ while generalizing to allow high end devices that interpret\r
+ one or more jobs while marking another. Indicated that\r
+ 'spool-area-full' and 'stopped-partly' "printer-state-reasons"\r
+ may be used to provide further state information.\r
+ 54. Section 4.4.12 - added the 'moving-to-paused' keyword value to\r
+ the "printer-state-reasons" attribute for use with the Pause-\r
+ Printer operation.\r
+ 55. Section 4.4.12 - replaced the duplicate 'marker-supply-low'\r
+ keyword with the missing 'toner-empty' keyword for the\r
+ "printer-state-reasons" attribute. (This correction was also\r
+ made before RFC 2566 was published).\r
+ 56. Section 4.4.12 - clarified 'spool-area-full' "printer-state-\r
+ reasons" to include non-spooling printers to indicate when it\r
+ can and cannot accept another job.\r
+ 57. Section 4.4.15 - added the enum values to the "operations-\r
+ supported" attribute for the new operations. Clarified that\r
+ the values of this attribute are encoded as any enum, namely\r
+ 32-bit values.\r
+ 58. Section 4.4.30 - clarified that the dateTime value of\r
+ "printer-current-time" is on a "best efforts basis". If a\r
+ proper date-time cannot be obtained, the implementation\r
+ returns the 'no-value' out-of-band value. Also clarified that\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 219]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ the time zone NEED NOT be the time zone that the people near\r
+ the device use and that the client SHOULD display the dateTime\r
+ attributes in the user's local time.\r
+ 59. Sections 4.4.36 and 4.4.37 - added the OPTIONAL "pages-per-\r
+ minute" and "pages-per-minute-color" Printer Description\r
+ attributes.\r
+ 60. Section 5.1 - clarified that the client conformance\r
+ requirements apply to clients controlled by an end user and\r
+ clients in servers.\r
+ 61. Section 5.1 - clarified that any response MAY contain\r
+ additional attribute groups, attributes, attribute syntaxes,\r
+ or attribute values.\r
+ 62. Section 5.1 - clarified that a client SHOULD do its best to\r
+ prevent a channel from being closed by a lower layer when the\r
+ channel is flow controlled off by the IPP Printer.\r
+ 63. Section 5.2 - clarified that the IPP object requirements apply\r
+ to objects embedded in devices or that are parts of servers.\r
+ 64. Section 5.2.2 - clarified that IPP objects MAY return\r
+ operation responses that contain attribute groups, attribute\r
+ names, attribute syntaxes, attribute values, and status codes\r
+ that are extensions to this standard.\r
+ 65. Section 6 - changed the terminology of "private extensions" to\r
+ "vendor extensions" and indicated that they are registered\r
+ with IANA along with IETF standards track extensions.\r
+ 66. Section 6.7 - inserted this section on registering out-of-band\r
+ attribute values with IANA as extensions.\r
+ 67. Section 8.3 - clarified the use of URIs for each Client\r
+ Authentication mechanism.\r
+ 68. Section 8.5 - added the security discussion around the new\r
+ operator/administrator operations.\r
+ 69. Section 13.1.4.16 - added client-error-compression-not-\r
+ supported (0x040F)\r
+ 70. Section 13.1.4.17 - added client-error-compression-error\r
+ (0x0410)\r
+ 71. Section 13.1.4.18 - added client-error-document-format-error\r
+ (0x0411)\r
+ 72. Section 13.1.4.19 - added client-error-document-access-error\r
+ (0x0412)\r
+ 73. Section 13.1.5.10 - added server-error-multiple-document-\r
+ jobs-not-supported (0x0509)\r
+ 74. Section 14 - added 'a-white', 'b-white', 'c-white', 'd-white',\r
+ and 'e-white' and clarified that the existing 'a', 'b', 'c',\r
+ 'd', and 'e' values are size values. Added American,\r
+ Japanese, and European Engineering sizes, filled out\r
+ -transparent and - translucent media names and drawings for\r
+ the synchro cut sizes.\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 220]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 75. Section 16 - softened the RECOMMENDATION for IPP Printer\r
+ attributes in a Directory schema so that they can have\r
+ equivalents.\r
+ 76. Section 16 - added the OPTIONAL "pages-per-minute" and\r
+ "pages-per-minute-color" Printer attributes to the Directory\r
+ schema.\r
+ 77. Section 16 - added OPTIONAL "multiple-document-jobs-supported"\r
+ to the Directory schema.\r
+ 78. Section 16 - added RECOMMENDED "uri-authentication-supported",\r
+ "ipp-versions-supported", and "compression-supported" to the\r
+ Directory schema.\r
+\r
+ The following changes in semantics and/or conformance have been\r
+ incorporated into this document:\r
+\r
+ 1. Section 3.1.6.3 - allowed a Printer to localize the\r
+ "detailed-status-message" operation response attribute, but\r
+ indicated that such localization might obscure the technical\r
+ meaning of such messages.\r
+ 2. Section 3.1.8, 5.2.4, and 13.1.5.4 - Clients and IPP objects\r
+ MUST support version 1.1 conformance requirements. It is\r
+ recommended that they interoperate with 1.0. Also clarified\r
+ that IPP Printers MUST accept '1.1' requests. It is\r
+ recommended that they also accept '1.x' requests.\r
+\r
+ 3. Section 3.2.1.1 and section 4.4.32 - changed the "compression"\r
+ operation and the "compression-supported" Printer Description\r
+ attribute from OPTIONAL to REQUIRED.\r
+ 4. Sections 3.2.1.2 and 4.3.8 - changed "job-state-reasons" from\r
+ RECOMMENDED to REQUIRED, so that "job-state-reasons" MUST be\r
+ returned in create operation responses.\r
+ 5. Sections 3.2.4, 3.3.1, 4.4.16, and 16 - changed Create-\r
+ Job/Send-Document so that they MAY be implemented while only\r
+ supporting one document jobs. Added the "multiple-document-\r
+ jobs-supported" boolean Printer Description attribute to\r
+ indicate whether Create-Job/Send-Document support multiple\r
+ document jobs or not. Added to the Directory schema.\r
+ 6. Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2',\r
+ since binary is not legal with the 'text' type.\r
+ 7. Section 4.1.9.1 - added the RECOMMENDATION that a Printer\r
+ indicate by printing on the job's job-start-sheet that auto-\r
+ sensing has occurred and what document format was auto-sensed.\r
+ 8. Section 4.2.4 - indicated that the "multiple-document-\r
+ handling" Job Template attribute MUST be supported with at\r
+ least one value if the Printer supports multiple documents per\r
+ job\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 221]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 9. Section 4.3.7.2 - indicated that the 'job-restartable' job\r
+ state reason SHOULD be supported if the Restart-Job operation\r
+ is supported.\r
+ 10. Section 4.3.8 - changed "job-state-reasons" from RECOMMENDED\r
+ to REQUIRED.\r
+ 11. Section 4.3.8 - clarified the conformance of the values of the\r
+ "job-state-reasons" attribute by copying conformance\r
+ requirements from other sections of the document so that it is\r
+ clear from reading the definition of "job-state-reasons" which\r
+ values MUST or SHOULD be supported. The 'none',\r
+ 'unsupported-compression', and 'unsupported-document-format'\r
+ values MUST be supported. The 'job-hold-until-specified'\r
+ SHOULD be specified if the "job-hold-until" Job Template is\r
+ supported. The following values SHOULD be supported: 'job-\r
+ canceled-by-user', 'aborted-by-system', and 'job-completed-\r
+ successfully'. The\r
+ 'job-canceled-by-operator' SHOULD be supported if the\r
+ implementation permits canceling by other than the job owner.\r
+ The 'job-canceled-at-device' SHOULD be supported if the device\r
+ supports canceling jobs at the console. The 'job-completed-\r
+ with-warnings' SHOULD be supported, if the implementation\r
+ detects warnings. The 'job-completed-with-errors' SHOULD be\r
+ supported if the implementation detects errors. The 'job-\r
+ restartable' SHOULD be supported if the Restart-Job operation\r
+ is supported.\r
+ 12. Section 4.3.10 - allowed a Printer to localize the "job-\r
+ detailed-status-message" Job Description attribute, but\r
+ indicated that such localization might obscure the technical\r
+ meaning of such messages.\r
+ 13. Section 4.3.14 - changed the "time-at-creation", "time-at-\r
+ processing", and "time-at-completed" Event Time Job\r
+ Description attributes from OPTIONAL to REQUIRED.\r
+ 14. Section 4.3.14.4 - added the REQUIRED "job-printer-up-time\r
+ (integer(1:MAX))" Job Description attribute as an alias for\r
+ "printer-up-time" to reduce number of operations to get job\r
+ times.\r
+ 15. Section 4.4.2 - added the REQUIRED "uri-authentication-\r
+ supported (1setOf type2 keyword)" Printer Description\r
+ attribute to describe the Client Authentication used by each\r
+ Printer URI.\r
+ 16. Section 4.4.12 - changed "printer-state-reasons" Printer\r
+ Description attribute from OPTIONAL to REQUIRED.\r
+ 17. Section 4.4.12 - changed 'paused' value of "printer-state-\r
+ reasons" to MUST if Pause-Printer operation is supported.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 222]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+ 18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported\r
+ (1setOf keyword)" Printer Description attribute, since IPP/1.1\r
+ Printers do not have to support version '1.0' conformance\r
+ requirements. Section 4.4.16 - added the "multiple-document-\r
+ jobs-supported (boolean)" Printer Description attribute so\r
+ that a client can tell whether a Printer that supports\r
+ Create-Job/Send-Document supports multiple document jobs or\r
+ not. This attribute is REQUIRED if the Create-Job operation\r
+ is supported.\r
+ 19. Section 4.4.24 - changed the "queued-job-count" Printer\r
+ Description attribute from RECOMMENDED to REQUIRED.\r
+ 20. Section 4.4.32 - changed "compression-supported (1setOf type3\r
+ keyword)" Printer Description attribute from OPTIONAL to\r
+ REQUIRED.\r
+ 21. Section 5.1 - changed the client security requirements from\r
+ RECOMMENDED non-standards track SSL3 to MUST support Client\r
+ Authentication as defined in the IPP/1.1 Encoding and\r
+ Transport document [RFC2910]. A client SHOULD support\r
+ Operation Privacy and Server Authentication as defined in the\r
+ IPP/1.1 Encoding and Transport document [RFC2910].\r
+ 22. Section 5.2.7 - changed the IPP object security requirements\r
+ from OPTIONAL non-standards track SSL3 to SHOULD contain\r
+ support for Client Authentication as defined in the IPP/1.1\r
+ Encoding and Transport document [RFC2910]. A Printer\r
+ implementation MAY allow an administrator to configure the\r
+ Printer so that all, some, or none of the users are\r
+ authenticated. An IPP Printer implementation SHOULD contain\r
+ support for Operation Privacy and Server Authentication as\r
+ defined in the IPP/1.1 Encoding and Transport document\r
+ [RFC2910]. A Printer implementation MAY allow an\r
+ administrator to configure the degree of support for Operation\r
+ Privacy and Server Authentication. Security MUST NOT be\r
+ compromised when the client supplies a lower version-number in\r
+ a request.\r
+ 23. Section 14 (Appendix C): Corrected typo, changing the keyword\r
+ 'iso-10-white' to 'iso-a10-white'.\r
+\r
+ See also the "IPP/1.1 Encoding and Transport" [RFC2910] document for\r
+ differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910].\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 223]\r
+\f\r
+RFC 2911 IPP/1.1: Model and Semantics September 2000\r
+\r
+\r
+18. Full Copyright Statement\r
+\r
+ Copyright (C) The Internet Society (2000). All Rights Reserved.\r
+\r
+ This document and translations of it may be copied and furnished to\r
+ others, and derivative works that comment on or otherwise explain it\r
+ or assist in its implementation may be prepared, copied, published\r
+ and distributed, in whole or in part, without restriction of any\r
+ kind, provided that the above copyright notice and this paragraph are\r
+ included on all such copies and derivative works. However, this\r
+ document itself may not be modified in any way, such as by removing\r
+ the copyright notice or references to the Internet Society or other\r
+ Internet organizations, except as needed for the purpose of\r
+ developing Internet standards in which case the procedures for\r
+ copyrights defined in the Internet Standards process must be\r
+ followed, or as required to translate it into languages other than\r
+ English.\r
+\r
+ The limited permissions granted above are perpetual and will not be\r
+ revoked by the Internet Society or its successors or assigns.\r
+\r
+ This document and the information contained herein is provided on an\r
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+Acknowledgement\r
+\r
+ Funding for the RFC Editor function is currently provided by the\r
+ Internet Society.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Hastings, et al. Standards Track [Page 224]\r
+\f\r
projects / thirdparty / cups.git / commitdiff
