diff options
Diffstat (limited to 'doc/rfc/rfc2565.txt')
| -rw-r--r-- | doc/rfc/rfc2565.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc2565.txt b/doc/rfc/rfc2565.txt new file mode 100644 index 0000000..56511d4 --- /dev/null +++ b/doc/rfc/rfc2565.txt @@ -0,0 +1,2075 @@ + + + + + + +Network Working Group R. Herriot, Ed. +Request for Comments: 2565 Xerox Corporation +Category: Experimental S. Butler + Hewlett-Packard + P. Moore + Microsoft + R. Turner + Sharp Labs + April 1999 + + + Internet Printing Protocol/1.0: Encoding and Transport + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +IESG Note + + This document defines an Experimental protocol for the Internet + community. The IESG expects that a revised version of this protocol + will be published as Proposed Standard protocol. The Proposed + Standard, when published, is expected to change from the protocol + defined in this memo. In particular, it is expected that the + standards-track version of the protocol will incorporate strong + authentication and privacy features, and that an "ipp:" URL type will + be defined which supports those security measures. Other changes to + the protocol are also possible. Implementors are warned that future + versions of this protocol may not interoperate with the version of + IPP defined in this document, or if they do interoperate, that some + protocol features may not be available. + + The IESG encourages experimentation with this protocol, especially in + combination with Transport Layer Security (TLS) [RFC 2246], to help + determine how TLS may effectively be used as a security layer for + IPP. + + + + + + + + +Herriot, et al. Experimental [Page 1] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +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 "application/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.0: Model and Semantics [RFC2566] + Internet Printing Protocol/1.0: Encoding and Transport (this + document) + Internet Printing Protocol/1.0: 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.0. Operator and administrator requirements are + out of scope for version 1.0. + + The document, "Rationale for the Structure and Model and Protocol for + the Internet Printing Protocol", describes IPP from a high level + view, defines a roadmap for the various documents that form the suite + of IPP specifications, and gives background and rationale for the + IETF working group's major decisions. + + The document, "Internet Printing Protocol/1.0: Model and Semantics", + describes a simplified model with abstract objects, their attributes, + and their operations 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. + + This document "Internet Printing Protocol/1.0: Implementer's Guide", + gives advice to implementers of IPP clients and IPP objects. + + + + + +Herriot, et al. Experimental [Page 2] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + The document "Mapping between LPD and IPP Protocols" gives some + advice to implementers of gateways between IPP and LPD (Line Printer + Daemon) implementations. + +Table of Contents + + 1. Introduction.....................................................4 + 2. Conformance Terminology..........................................4 + 3. Encoding of the Operation Layer.................................4 + 3.1 Picture of the Encoding.....................................5 + 3.2 Syntax of Encoding..........................................7 + 3.3 Version-number..............................................9 + 3.4 Operation-id................................................9 + 3.5 Status-code.................................................9 + 3.6 Request-id..................................................9 + 3.7 Tags.......................................................10 + 3.7.1 Delimiter Tags.........................................10 + 3.7.2 Value Tags.............................................11 + 3.8 Name-Length................................................13 + 3.9 (Attribute) Name...........................................13 + 3.10 Value Length...............................................16 + 3.11 (Attribute) Value..........................................16 + 3.12 Data.......................................................18 + 4. Encoding of Transport Layer.....................................18 + 5. Security Considerations.........................................19 + 5.1 Using IPP with SSL3........................................19 + 6. References......................................................20 + 7. Authors' Addresses..............................................22 + 8. Other Participants:.............................................24 + 9. Appendix A: Protocol Examples...................................25 + 9.1 Print-Job Request..........................................25 + 9.2 Print-Job Response (successful)............................26 + 9.3 Print-Job Response (failure)...............................27 + 9.4 Print-Job Response (success with attributes ignored).......28 + 9.5 Print-URI Request..........................................30 + 9.6 Create-Job Request.........................................31 + 9.7 Get-Jobs Request...........................................31 + 9.8 Get-Jobs Response..........................................32 + 10. Appendix C: Registration of MIME Media Type Information for + "application/ipp"..............................................35 + 11. Full Copyright Statement.......................................37 + + + + + + + + + + +Herriot, et al. Experimental [Page 3] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +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 + 2068 [RFC2068] 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.0: Model and + Semantics" [RFC2566] defines the semantics of such a message body and + the supported values. This document specifies the encoding of an IPP + operation. The aforementioned document [RFC2566] is henceforth + referred to as the "IPP model document" + +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 MUST contain a single operation request or + 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 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 + + + +Herriot, et al. Experimental [Page 4] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + 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 values + fields and the sequence number. + + The following two sections present the operation layer in two ways + + - informally through pictures and description + - formally through Augmented Backus-Naur Form (ABNF), as specified + by RFC 2234 [RFC2234] + +3.1 Picture of the Encoding + + The encoding for an operation request or response consists of: + + ----------------------------------------------- + | version-number | 2 bytes - required + ----------------------------------------------- + | operation-id (request) | + | or | 2 bytes - required + | status-code (response) | + ----------------------------------------------- + | request-id | 4 bytes - required + ----------------------------------------------------------- + | xxx-attributes-tag | 1 byte | + ----------------------------------------------- |-0 or more + | xxx-attribute-sequence | n bytes | + ----------------------------------------------------------- + | end-of-attributes-tag | 1 byte - required + ----------------------------------------------- + | data | q bytes - optional + ----------------------------------------------- + + The xxx-attributes-tag and xxx-attribute-sequence represents four + different values of "xxx", namely, operation, job, printer and + unsupported. The xxx-attributes-tag and an xxx-attribute-sequence + represent attribute groups in the model document. The xxx- + attributes-tag identifies the attribute group and the xxx-attribute- + sequence contains the attributes. + + The expected sequence of xxx-attributes-tag and xxx-attribute- + sequence is specified in the IPP model document for each operation + request and operation response. + + + + + +Herriot, et al. Experimental [Page 5] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + A request or response SHOULD contain each xxx-attributes-tag defined + for that request or response even if there are no attributes except + for the unsupported-attributes-tag which SHOULD be present only if + the unsupported-attribute-sequence is non-empty. A receiver of a + request MUST be able to process as equivalent empty attribute groups: + + a) an xxx-attributes-tag with an empty xxx-attribute-sequence, + b) an expected but missing xxx-attributes-tag. + + The data is omitted from some operations, but the end-of-attributes- + tag is present even when the data is omitted. Note, the xxx- + attributes-tags and end-of-attributes-tag are called 'delimiter- + tags'. Note: the xxx-attribute-sequence, shown above may consist of 0 + bytes, according to the rule below. + + An xxx-attributes-sequence consists of zero or more compound- + attributes. + + ----------------------------------------------- + | compound-attribute | s bytes - 0 or more + ----------------------------------------------- + + A compound-attribute consists of an attribute with a single value + followed by zero or more additional values. + + Note: a 'compound-attribute' represents a single attribute in the + model document. The 'additional value' syntax is for attributes with + 2 or more values. + + Each attribute consists of: + + ----------------------------------------------- + | value-tag | 1 byte + ----------------------------------------------- + | name-length (value is u) | 2 bytes + ----------------------------------------------- + | name | u bytes + ----------------------------------------------- + | value-length (value is v) | 2 bytes + ----------------------------------------------- + | value | v bytes + ----------------------------------------------- + + + + + + + + + +Herriot, et al. Experimental [Page 6] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + An additional value consists of: + + ----------------------------------------------------------- + | value-tag | 1 byte | + ----------------------------------------------- | + | name-length (value is 0x0000) | 2 bytes | + ----------------------------------------------- |-0 or more + | value-length (value is w) | 2 bytes | + ----------------------------------------------- | + | value | w bytes | + ----------------------------------------------------------- + + Note: an additional value is like an attribute whose name-length is 0. + + From the standpoint of a parsing loop, the encoding consists of: + + ----------------------------------------------- + | 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 | 2 bytes - required + ----------------------------------------------- + | data | y bytes - optional + ----------------------------------------------- + + The value of the tag determines whether the bytes following the + tag are: + + - attributes + - data + - the remainder of a single attribute where the tag specifies the + type of the value. + +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. + + + +Herriot, et al. Experimental [Page 7] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + ipp-message = ipp-request / ipp-response + ipp-request = version-number operation-id request-id + *(xxx-attributes-tag xxx-attribute-sequence) + end-of-attributes-tag data + ipp-response = version-number status-code request-id + *(xxx-attributes-tag xxx-attribute-sequence) + end-of-attributes-tag data + xxx-attribute-sequence = *compound-attribute + + xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / + printer-attributes-tag / unsupported-attributes-tag + + version-number = major-version-number minor-version-number + major-version-number = SIGNED-BYTE ; initially %d1 + minor-version-number = SIGNED-BYTE ; initially %d0 + + 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 + + compound-attribute = attribute *additional-values + attribute = value-tag name-length name value-length value + additional-values = 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 + 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 + end-of-attributes-tag = %x03 ; tag of 3 + value-tag = %x10-FF + + 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 + + + + + +Herriot, et al. Experimental [Page 8] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + 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.3 Version-number + + The version-number MUST consist of a major and minor version-number, + each of which MUST be represented by a SIGNED-BYTE. The protocol + described in this document MUST have a major version-number of 1 + (0x01) and a minor version-number of 0 (0x00). The ABNF for these + two bytes MUST be %x01.00. + +3.4 Operation-id + + Operation-ids are defined as enums in the model document. An + operation-ids enum value MUST be encoded as a SIGNED-SHORT. + + Note: the values 0x4000 to 0xFFFF are reserved for private + extensions. + +3.5 Status-code + + Status-codes are defined as enums in the model document. A status- + code enum value MUST be encoded as a SIGNED-SHORT. + + 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. + + 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.6 Request-id + + The request-id allows a client to match a response with a request. + This mechanism is unnecessary in HTTP, but may be useful when + application/ipp entity bodies are used in another context. + + The request-id in a response MUST be the value of the request-id + received in the corresponding request. A client can set the + request-id in each request to a unique value or a constant value, + such as 1, depending on what the client does with the request-id + + + +Herriot, et al. Experimental [Page 9] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + returned in the response. The value of the request-id MUST be greater + than zero. + +3.7 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.7.1 Delimiter Tags + + The following table specifies the values for the delimiter tags: + + Tag Value (Hex) Delimiter + + 0x00 reserved + 0x01 operation-attributes-tag + 0x02 job-attributes-tag + 0x03 end-of-attributes-tag + 0x04 printer-attributes-tag + 0x05 unsupported-attributes-tag + 0x06-0x0e reserved for future delimiters + 0x0F reserved for future chunking-end-of-attributes- + tag + + When an xxx-attributes-tag occurs in the protocol, it MUST mean that + zero or more following attributes up to the next delimiter tag are + attributes belonging to group xxx as defined in the model document, + where xxx is operation, job, printer, unsupported. + + Doing substitution for xxx in the above paragraph, this means the + following. When an operation-attributes-tag occurs in the protocol, + it MUST mean that the zero or more following attributes up to the + next delimiter tag are operation attributes as defined in the model + document. When an job-attributes-tag occurs in the protocol, it MUST + mean that the zero or more following attributes up to the next + delimiter tag are job attributes or job template attributes as + defined in the model document. When a printer-attributes-tag occurs + in the protocol, it MUST mean that the zero or more following + attributes up to the next delimiter tag are printer attributes as + defined in the model document. When an unsupported-attributes-tag + occurs in the protocol, it MUST mean that the zero or more following + attributes up to the next delimiter tag are unsupported attributes as + defined in the model document. + + + + + +Herriot, et al. Experimental [Page 10] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + The operation-attributes-tag and end-of-attributes-tag MUST each + occur exactly once in an operation. The operation-attributes-tag MUST + be the first tag delimiter, and the end-of-attributes-tag MUST be the + last tag delimiter. If the operation has a document-content group, + the document data in that group MUST follow the end-of-attributes- + tag. + + Each of the other three xxx-attributes-tags defined above is + OPTIONAL in an operation and each MUST occur at most once in an + operation, except for job-attributes-tag in a Get-Jobs response which + may occur zero or more times. + + The order and presence of delimiter tags for each operation request + and each operation response MUST be that defined in the model + document. For further details, see section 3.9 "(Attribute) Name" and + section 9 "Appendix A: Protocol Examples". + + A Printer MUST treat the reserved delimiter tags differently from + reserved value tags 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.7.2 Value Tags + + The remaining tables show values for the value-tag, which is the + first octet of an attribute. The value-tag specifies the type of the + value of the attribute. The following table specifies the "out-of- + band" values for the value-tag. + + Tag Value (Hex) Meaning + + 0x10 unsupported + 0x11 reserved for future 'default' + 0x12 unknown + 0x13 no-value + + Tag Value (Hex) Meaning + + 0x14-0x1F reserved for future "out-of-band" values. + + The "unsupported" value MUST be used in the attribute-sequence of an + error response for those attributes which the printer does not + support. The "default" value is reserved for future use of setting + value back to their default value. The "unknown" value is used for + the value of a supported attribute when its value is temporarily + unknown. The "no-value" value is used for a supported attribute to + which + + + + +Herriot, et al. Experimental [Page 11] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + no value has been assigned, e.g. "job-k-octets-supported" has no + value if an implementation supports this attribute, but an + administrator has not configured the printer to have a limit. + + The following table specifies the integer values for the value-tag: + + Tag Value (Hex) Meaning + + 0x20 reserved + 0x21 integer + 0x22 boolean + 0x23 enum + 0x24-0x2F reserved for future integer types + + NOTE: 0x20 is reserved for "generic integer" if it should ever be + needed. + + The following table specifies the octetString values for the value- + tag: + + Tag Value (Hex) Meaning + + 0x30 octetString with an unspecified format + 0x31 dateTime + 0x32 resolution + 0x33 rangeOfInteger + 0x34 reserved for collection (in the future) + 0x35 textWithLanguage + 0x36 nameWithLanguage + 0x37-0x3F reserved for future octetString types + + The following table specifies the character-string values for the + value-tag: + + Tag Value (Hex) Meaning + + 0x40 reserved + 0x41 textWithoutLanguage + 0x42 nameWithoutLanguage + 0x43 reserved + 0x44 keyword + 0x45 uri + 0x46 uriScheme + 0x47 charset + 0x48 naturalLanguage + + + + + + +Herriot, et al. Experimental [Page 12] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Tag Value (Hex) Meaning + + 0x49 mimeMediaType + 0x4A-0x5F reserved for future character string types + + 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 types. There are no + values allocated for private extensions. A new type MUST be + registered via the type 2 registration process [RFC2566]. + + 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. All these 4 byte tag values + are currently unallocated except that the values 0x40000000- + 0x7FFFFFFF are reserved for experimental use. + +3.8 Name-Length + + The name-length field MUST consist of a SIGNED-SHORT. This field MUST + specify the number of octets in the name field which follows the + name-length field, excluding the two bytes of the name-length field. + + 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 preceding attribute. Within an attribute- + sequence, if two attributes have the same name, the first occurrence + MUST be ignored. The zero-length name is the only mechanism for + multi-valued attributes. + +3.9 (Attribute) Name + + Some operation elements are called parameters in the model document + [RFC2566]. They MUST be encoded in a special position and they MUST + NOT appear as an operation attributes. These parameters are: + + - "version-number": The parameter named "version-number" in the + IPP model document MUST become the "version-number" field in the + operation layer request or response. + + + +Herriot, et al. Experimental [Page 13] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + - "operation-id": The parameter named "operation-id" in the IPP + model document MUST become the "operation-id" field in the + operation layer request. + - "status-code": The parameter named "status-code" in the IPP + model document MUST become the "status-code" field in the + operation layer response. + - "request-id": The parameter named "request-id" in the IPP model + document MUST become the "request-id" field in the operation + layer request or response. + + 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: + + - "printer-uri": When the target is a printer and the transport is + HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined + in each operation in the IPP model document MUST be an operation + attribute called "printer-uri" and it MUST also be specified + outside of the operation layer as the request-URI on the + Request-Line at the HTTP level. + - "job-uri": When the target is a job and the transport is HTTP or + HTTPS (for SSL3), the target job-uri of each operation in the + IPP model document MUST be an operation attribute called "job- + uri" and it MUST also be specified outside of the operation + layer as the request-URI on the Request-Line at the HTTP level. + + 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: + + + + + + +Herriot, et al. Experimental [Page 14] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + 1. Although potentially redundant, a client MUST supply the target + of the operation both as an operation attribute and as a URI at + the 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. + 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. + + The model document arranges the remaining attributes into groups for + each operation request and response. Each such group MUST be + represented in the protocol by an xxx-attribute-sequence preceded by + the appropriate xxx-attributes-tag (See the table below and section 9 + "Appendix A: Protocol Examples"). In addition, the order of these + xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST + be the same as in the model document, but the order of attributes + within each xxx-attribute-sequence MUST be unspecified. The table + below maps the model document group name to xxx-attributes-sequence: + + Model Document Group xxx-attributes-sequence + + Operation Attributes operations-attributes-sequence + Job Template Attributes job-attributes-sequence + Job Object Attributes job-attributes-sequence + Unsupported Attributes unsupported-attributes-sequence + Requested Attributes job-attributes-sequence + Get-Job-Attributes) + Requested Attributes printer-attributes-sequence + Get-Printer-Attributes) + Document Content in a special position as described + above + + If an operation contains attributes from more than one job object + (e.g. Get-Jobs response), the attributes from each job object MUST + be in a separate job-attribute-sequence, such that the attributes + + + + +Herriot, et al. Experimental [Page 15] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + from the ith job object are in the ith job-attribute-sequence. See + Section 9 "Appendix A: Protocol Examples" for table showing the + application of the rules above. + +3.10 Value Length + + Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST + specify the number of octets in the value which follows this length, + exclusive of the two bytes specifying the length. + + 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. + + If a value-tag contains an "out-of-band" value, such as + "unsupported", the value-length MUST be 0 and the value empty. The + value has no meaning when the value-tag has an "out-of-band" value. + If a client receives a response with a nonzero value-length in this + case, it MUST ignore the value field. If a printer receives a request + with a nonzero value-length in this case, it MUST reject the request. + +3.11 (Attribute) Value + + The syntax types and most of the details of their representation 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. + +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. + + + + +Herriot, et al. Experimental [Page 16] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + 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'. + +Syntax of Attribute Encoding +Value + + +integer and enum a SIGNED-INTEGER. + +dateTime OCTET-STRING consisting of eleven octets whose + contents are defined by "DateAndTime" in RFC + 2579 [RFC2579]. + +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 + 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. + + + + + + +Herriot, et al. Experimental [Page 17] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +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 type of the value in the model document determines the encoding + in the value and the value of the value-tag. + +3.12 Data + + The data part MUST include any data required by the operation + +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 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. + In addition, a printer may have to support another port for privacy + (See Section 5 "Security Considerations"). + + Note: even though port 631 is the IPP default, port 80 remains the + default for an HTTP URI. Thus a URI for a printer using port 631 + MUST contain an explicit port, e.g. "http://forest:631/pinetree". An + HTTP URI for IPP with no explicit port implicitly reference port 80, + which is consistent with the rules for HTTP/1.1. 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 MUST + adhere to the rules for a client described for HTTP1.1 [RFC2068]. A + printer (server) implementation MUST adhere the rules for an origin + server described for HTTP1.1 [RFC2068]. + + 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 + + + +Herriot, et al. Experimental [Page 18] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + 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 [RFC2068]. + +5. Security Considerations + + The IPP Model document defines an IPP implementation with "privacy" + as one that implements Secure Socket Layer Version 3 (SSL3). Note: + SSL3 is not an IETF standards track specification. SSL3 meets the + requirements for IPP security with regards to features such as mutual + authentication and privacy (via encryption). The IPP Model document + also outlines IPP-specific security considerations and should be the + primary reference for security implications with regards to the IPP + protocol itself. + + The IPP Model document defines an IPP implementation with + "authentication" as one that implements the standard way for + transporting IPP messages within HTTP 1.1. These include the security + considerations outlined in the HTTP 1.1 standard document [RFC2068] + and Digest Access Authentication extension [RFC2069]. + + The current HTTP infrastructure supports HTTP over TCP port 80. IPP + server implementations MUST offer IPP services using HTTP over the + IANA assigned Well Known Port 631 (the IPP default port). IPP server + implementations may support other ports, in addition to this port. + + See further discussion of IPP security concepts in the model document + [RFC2566]. + +5.1 Using IPP with SSL3 + + An assumption is that the URI for a secure IPP Printer object has + been found by means outside the IPP printing protocol, via a + directory service, web site or other means. + + IPP provides a transparent connection to SSL by calling the + corresponding URL (a https URI connects by default to port 443). + However, the following functions can be provided to ease the + integration of IPP with SSL during implementation: + + connect (URI), returns a status + + "connect" makes an https call and returns the immediate status + of the connection as returned by SSL to the user. The status + values are explained in section 5.4.2 of the SSL document + [ssl]. + + + + +Herriot, et al. Experimental [Page 19] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + A session-id may also be retained to later resume a session. + The SSL handshake protocol may also require the cipher + specifications supported by the client, key length of the + ciphers, compression methods, certificates, etc. These should + be sent to the server and hence should be available to the IPP + client (although as part of administration features). + + disconnect (session) + + to disconnect a particular session. + + The session-id available from the "connect" could be used. + + resume (session) + + to reconnect using a previous session-id. + + The availability of this information as administration features are + left for implementers, and need not be specified at this time. + +6. References + + [RFC2278] Freed, N. and J. Postel, "IANA Charset Registration + Procedures", BCP 19, RFC 2278, January 1998. + + [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.0: + Implementer's Guide", Work in Progress. + + [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, + "Mapping between LPD and IPP Protocols", RFC 2569, April + 1999. + + [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. + Powell, "Internet Printing Protocol/1.0: Model and + Semantics", RFC 2566, April 1999. + + [RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet + Printing Protocol/1.0: Encoding and Transport", RFC 2565, + April 1999. + + + + + + +Herriot, et al. Experimental [Page 20] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + [RFC2568] Zilles, S., "Rationale for the Structure and Model and + Protocol for the Internet Printing Protocol", RFC 2568, + April 1999. + + [RFC2567] Wright, D., "Design Goals for an Internet Printing + Protocol", RFC 2567, April 1999. + + [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, August 1982. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. + + [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon + Protocol" RFC 1179, August 1990. + + [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", + RFC 2223, October 1997. + + [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. + Gyllenskog, "Printer MIB", RFC 1759, March 1995. + + [RFC1766] Alvestrand, H., " Tags for the Identification of + Languages", RFC 1766, March 1995. + + [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC + 1808, June 1995. + + [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual + Conventions for SMIv2", STD 58, RFC 2579, April 1999. + + [RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC2048] Freed, N., Klensin J. and J. Postel. Multipurpose Internet + Mail Extension (MIME) Part Four: Registration Procedures", + BCP 13, RFC 2048, November 1996. + + [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC + 2068, January 1997. + + + + + + +Herriot, et al. Experimental [Page 21] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., + Luotonen, A., Sink, E. and L. Stewart, "An Extension to + HTTP: Digest Access Authentication", RFC 2069, January + 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded + Word Extensions: Character Sets, Languages, and + Continuations", RFC 2184, August 1997. + + [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234. November 1997. + + [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + +7. Authors' Addresses + + Robert Herriot (Editor) + Xerox Corporation + 3400 Hillview Ave., Bldg #1 + Palo Alto, CA 94304 + + Phone: 650-813-7696 + Fax: 650-813-6860 + EMail: rherriot@pahv.xerox.com + + + Sylvan Butler + Hewlett-Packard + 11311 Chinden Blvd. + Boise, ID 83714 + + Phone: 208-396-6000 + Fax: 208-396-3457 + EMail: sbutler@boi.hp.com + + + + + + + + + + + + +Herriot, et al. Experimental [Page 22] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Paul Moore + Microsoft + One Microsoft Way + Redmond, WA 98053 + + Phone: 425-936-0908 + Fax: 425-93MS-FAX + EMail: paulmo@microsoft.com + + + Randy Turner + Sharp Laboratories + 5750 NW Pacific Rim Blvd + Camas, WA 98607 + + Phone: 360-817-8456 + Fax: 360-817-8436 + EMail: rturner@sharplabs.com + + + IPP Mailing List: ipp@pwg.org + IPP Mailing List Subscription: ipp-request@pwg.org + IPP Web Page: http://www.pwg.org/ipp/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Herriot, et al. Experimental [Page 23] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +8. Other Participants: + + Chuck Adams - Tektronix Harry Lewis - IBM + Ron Bergman - Dataproducts Tony Liao - Vivid Image + Keith Carter - IBM David Manchala - Xerox + Angelo Caruso - Xerox Carl-Uno Manros - Xerox + Jeff Copeland - QMS Jay Martin - Underscore + Roger deBry - IBM Larry Masinter - Xerox + Lee Farrell - Canon Ira McDonald - High North Inc. + Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard + Charles Gordon - Osicom Patrick Powell - Astart + Technologies + Brian Grimshaw - Apple Jeff Rackowitz - Intermec + Jerry Hadsell - IBM Xavier Riley - Xerox + Richard Hart - Digital Gary Roberts - Ricoh + Tom Hastings - Xerox Stuart Rowley - Kyocera + Stephen Holmstead Richard Schneider - Epson + Zhi-Hong Huang - Zenographics Shigern Ueda - Canon + Scott Isaacson - Novell Bob Von Andel - Allegro Software + Rich Lomicka - Digital William Wagner - Digital Products + David Kellerman - Northlake Jasper Wong - Xionics + Software + Robert Kline - TrueSpectra Don Wright - Lexmark + Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox + Takami Kurono - Brother Lloyd Young - Lexmark + Rich Landau - Digital Peter Zehler - Xerox + Greg LeClair - Epson Frank Zhao - Panasonic + Steve Zilles - Adobe + + + + + + + + + + + + + + + + + + + + + + + +Herriot, et al. Experimental [Page 24] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +9. Appendix A: Protocol Examples + +9.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 + + 0x0100 1.0 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- 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 + 0x001A value-length + http://forest: printer pinetree value + 631/pinetree + 0x42 nameWithoutLanguage type value-tag + 0x0008 name-length + job-name job-name name + 0x0006 value-length + foobar foobar value + 0x22 boolean type value-tag + 0x16 name-length + ipp-attribute- ipp-attribute-fidelity name + fidelity + 0x01 value-length + 0x01 true value + 0x02 start job-attributes job-attributes-tag + 0x21 integer type value-tag + + + +Herriot, et al. Experimental [Page 25] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + 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 + +9.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 + + 0x0100 1.0 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 + successful-ok successful-ok value + 0x02 start job-attributes job-attributes-tag + 0x21 integer value-tag + 0x0006 name-length + + + + + +Herriot, et al. Experimental [Page 26] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Octets Symbolic Value Protocol field + + job-id job-id name + 0x0004 value-length + 147 147 value + 0x45 uri type value-tag + 0x0007 name-length + job-uri job-uri name + 0x001E value-length + http://forest:63 job 123 on pinetree value + 1/pinetree/123 + 0x42 nameWithoutLanguage 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 + +9.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 + + 0x0100 1.0 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 + 0x48 natural-language type value-tag + 0x001B name-length + attributes- attributes-natural-language name + natural- + language + 0x0005 value-length + + + + +Herriot, et al. Experimental [Page 27] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Octets Symbolic Value Protocol field + + en-us en-US value + 0x41 textWithoutLanguage type value-tag + 0x000E name-length + status- status-message name + message + 0x002F value-length + client-error- client-error-attributes-or- value + attributes- values-not-supported + or-values- + 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 + +9.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 + + 0x0100 1.0 version-number + 0x0001 successful-ok-ignored-or- status-code + 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 + + + +Herriot, et al. Experimental [Page 28] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Octets Symbolic Value Protocol field + + 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 + 0x001E value-length + http://forest:63 job 123 on pinetree value + 1/pinetree/123 + 0x42 nameWithoutLanguage 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 + + + + + +Herriot, et al. Experimental [Page 29] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +9.5 Print-URI Request + + The following is an example of Print-URI request with copies and + job-name parameters: + + Octets Symbolic Value Protocol field + + 0x0100 1.0 version-number + + Octets Symbolic Value Protocol field + 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 + 0x001A value-length + http://forest printer pinetree value + :631/pinetree + 0x45 uri type value-tag + 0x000C name-length + document-uri document-uri name + 0x11 value-length + ftp://foo.com ftp://foo.com/foo value + /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 + + + +Herriot, et al. Experimental [Page 30] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + 0x00000001 1 value + 0x03 end-of-attributes end-of-attributes-tag + +9.6 Create-Job Request + + The following is an example of Create-Job request with no parameters + and no attributes: + + Octets Symbolic Value Protocol field + 0x0100 1.0 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 + + Octets Symbolic Value Protocol field + 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 + 0x001A value-length + http://forest: printer pinetree value + 631/pinetree + 0x03 end-of-attributes end-of-attributes-tag + +9.7 Get-Jobs Request + + The following is an example of Get-Jobs request with parameters but + no attributes: + + Octets Symbolic Value Protocol field + + 0x0100 1.0 version-number + 0x000A Get-Jobs operation-id + 0x00000123 0x123 request-id + 0x01 start operation-attributes operation-attributes-tag + 0x47 charset type value-tag + + + +Herriot, et al. Experimental [Page 31] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Octets Symbolic Value Protocol field + + 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 + 0x001A value-length + http://forest:6 printer pinetree value + 31/pinetree + 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 + 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 + +9.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): + + + + + +Herriot, et al. Experimental [Page 32] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Octets Symbolic Value Protocol field + + 0x0100 1.0 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 + 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 + + + +Herriot, et al. Experimental [Page 33] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Octets Symbolic Value Protocol field + + 148 148 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Herriot, et al. Experimental [Page 34] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +10. Appendix C: 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 + + A Content-Type of "application/ipp" indicates an Internet Printing + Protocol message body (request or response). Currently there is one + version: IPP/1.0, whose syntax is described in Section 3 "Encoding of + the Operation Layer" of [RFC2565], and whose semantics are described + in [RFC2566]. + + Required parameters: none + + Optional parameters: none + + Encoding considerations: + + IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS + contain binary data (for example attribute value lengths). + + Security considerations: + + IPP/1.0 protocol requests/responses do not introduce any security + risks not already inherent in the underlying transport protocols. + Protocol mixed-version interworking rules in [RFC2566] as well as + protocol encoding rules in [RFC2565] are complete and unambiguous. + + Interoperability considerations: + + IPP/1.0 requests (generated by clients) and responses (generated by + servers) MUST comply with all conformance requirements imposed by the + normative specifications [RFC2566] and [RFC2565]. Protocol encoding + rules specified in [RFC2565] 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.0 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). + + + + +Herriot, et al. Experimental [Page 35] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + + Published specification: + + [RFC2566] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P. + Powell, "Internet Printing Protocol/1.0: Model and + Semantics" RFC 2566, April 1999. + + [RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet + Printing Protocol/1.0: Encoding and Transport", RFC 2565, + April 1999. + + Applications which use this media type: + + Internet Printing Protocol (IPP) print clients and print servers, + communicating using HTTP/1.1 (see [RFC2565]), 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: + + Scott A. Isaacson + Novell, Inc. + 122 E 1700 S + Provo, UT 84606 + + Phone: 801-861-7366 + Fax: 801-861-4025 + Email: sisaacson@novell.com + + or + + Robert Herriot (Editor) + Xerox Corporation + 3400 Hillview Ave., Bldg #1 + Palo Alto, CA 94304 + + Phone: 650-813-7696 + Fax: 650-813-6860 + EMail: rherriot@pahv.xerox.com + + + + + + + + + + + + +Herriot, et al. Experimental [Page 36] + +RFC 2565 IPP/1.0: Encoding and Transport April 1999 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Herriot, et al. Experimental [Page 37] + |