INTERNET-DRAFT HTTP 1.1 Transport Mapping for the Internet Printing Protocol Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes a method to encapsulate the abstract Internet Printing Protocol (IPP) Model using the Hypertext Transfer Protocol (HTTP) Version 1.1, as described in RFC 2068 [see bib]. Abstract IPP operations and responses are mapped to specific HTTP methods and responses. Where appropriate, HTTP response codes and message headers are used to convey abstract IPP model semantics. Within the context of IPP, HTTP is primarily used as a pure transport, carrying entire IPP protocol data units (PDUs) as "payload" within HTTP messages. 1. IPP Model Overview The IPP Model document[see bib] describes protocol operations and responses that are designed to fulfill the requirements set forth in the IPP Requirements Specification [see bib]. IPP operations are designed to operate on IPP "objects". There are two such objects defined by the IPP model: PRINTER objects and JOB objects. IPP objects are referenced by their Uniform Resource Identifier, or URI [see bib]. For each type of IPP object (PRINTER or JOB), one or more IPP operations defined. Also, for each type of IPP object, a set of attributes exist that detail object-specific characteristics or properties of that object. Individual IPP operations can be supplemented by object attribute specifications that are used to refine a particular operations' effect on a object. 2. HTTP 1.1 Mapping Strategy IPP operations and responses can be mapped directly to HTTP methods and responses. The IPP Model Document (see bib) defines the following protocol operations: PRINT-JOB - Print the enclosed job, with attributes PRINT-URI - Print the document specified by a URI CREATE-JOB - Create an instance of a JOB object SEND-DOCUMENT - Append enclosed print data to an existing JOB object SEND-URI - Retrieve a document referenced by a URI and print it. CANCEL - Destroy a specific JOB object VALIDATE - Validate attributes for a specific object GET-JOBS - Return job queue information for PRINTER object GET-ATTR - Return attribute information for a specified object All IPP operations are encapsulated within the HTTP POST method. Each POST request and each POST response message contain message bodies that are tagged with a "Content-Type" of "application/ipp". The format of the application/ipp content-type is defined in section 3 of this document. Briefly, the application/ipp entity contains a complete IPP protocol data unit (PDU), containing all IPP-specific encodings that make up a request or response. In this sense, HTTP is being utilized as a pure transport, merely conveying IPP messages between IPP clients and IPP servers. Associated with a POST method for IPP messages is an HTTP "Content-Length:" header that specifies the total length (in bytes) of the PDU contained within the application/ipp entity. 2.1 IPP Status/Error Code Handling The following information is related to the processing of response status codes received as a result of an IPP request operation. There are five different classes of status codes that can be returned by an IPP server while processing a request. Much of the description of the following classes is taken from the HTTP 1.1 specification (RFC 2068): Informational Success Redirection Client Error Server Error IPP responses include a 6-digit status code. The severity of the status code (information, warning, or error) is indicated by the first digit in the status code: 1xxxxx = informational, request ok, with information 2xxxxx = success, request successfully processed. 3xxxxx = redirection, further action must be taken to complete the request 4xxxxx = client error, the request contains bad syntax or cannot be fulfilled 5xxxxx = server error, the server failed to fulfill an apparently valid request The first 3 digits of the status code are the same as that in the HTTP 1.1 header. The second group of 3-digits specifies a more detailed IPP-specific status that extends the overall HTTP 1.1 status code with more detail. The extended status codes supported in this version of the protocol are: [ list status codes here. This should be the only section wherein a textual description of the semantic value of the status codes is specified. IPP Response message type descriptions will include only the status codes and a brief label describing the code that is returned for a particular response message ] RFC 2068, Section 10 should be referenced for descriptions of HTTP 1.1 status codes. 3. Encoding of application/ipp Entities IPP clients and servers exchange protocol messages over an HTTP message stream using the "application/ipp" MIME entities. This document refers to the "payload" carried within an application/ipp entity as a "protocol data unit" or PDU. The following is an example HTTP Content-Type header for IPP: Content-Type: application/ipp; charset=UTF8; XID=FF00FF00 The parameters for the application/ipp MIME-type are 'charset' and 'XID'. The 'charset' is similar to other MIME tags and specifies the character set in which the entity body is encoded. The 'XID' parameter is a transaction-id that is uniquely generated by clients for request messages, and echoed by IPP servers in a corresponding response. This document specifies that all IPP entities MUST be encoded in UTF8. Consequently specifying the 'charset' parameter is optional in this version of the protocol. Likewise, if the XID parameter is not included as a Content-Type parameter, it is assumed that the requests and responses are issued in 'lock-step' and no pipelining of IPP requests will be attempted. This section defines the encoding for an IPP protocol data unit. The application/ipp entity body contains four basic parts: IPP header, IPP operation, operation-attributes, and operation-data. The operation-data is essentially opaque to the "wire" IPP-over-HTTP protocol. Using the "8-bit clean" HTTP protocol as a transport implies that no special encoding of the actual operation-data is needed. The syntax rules follow the Augmented Backus-Naur Form (ABNF), as specified by . Per the ABNF specification, all multi-byte tokens within this protocol specification are transmitted in big-endian format (most significant byte first). The following protocol primitives are defined: DIGIT = "0".."9" CRLF = %d13.10 ALPHA = "A..Z" DELIM = 1*WSP BYTE = %d0..%d255 OCTET-STRING = *BYTE The following ABNF specification describes the encoding of an IPP message (PDU): ipp-message = ipp-version CRLF (ipp-request / ipp-response) ipp-version = "IPP" DELIM ipp-major-version "." ipp-minor-version ipp-major-version = 1*DIGIT ipp-minor-version = 1*DIGIT ipp-request = operation CRLF *ipp-attribute CRLF *operation-data operation = ( "PRINT-JOB" / ; See section 3.1 "PRINT-URI" / ; See section 3.2 "CREATE-JOB" / ; See section 3.3 "SEND-DOC" / ; See section 3.4 "SEND-URI" / ; See section 3.5 "VALIDATE" / ; See section 3.6 "GET-ATTR" / ; See section 3.7 "GET-JOBS" / ; See section 3.8 "CANCEL" ) ; See section 3.9 ipp-attribute = attr-name DELIM attr-value-length DELIM attr-value CRLF attr-name = 1*ALPHA { ALPHA / DIGIT / "_" } attr-value-length = 1*4DIGIT attr-value = OCTET-STRING operation-data = OCTET-STRING ipp-response = operation-response DELIM ipp-status CRLF *ipp-attribute CRLF *response-data operation-response = ( "PRINT-JOB-RESP" / ; "PRINT-URI-RESP" / "CREATE-JOB-RESP" / "SEND-DOC-RESP" / "SEND-URI-RESP" / "VALIDATE-RESP" / "GET-ATTR-RESP" / "GET-JOBS-RESP" / "CANCEL-RESP" ) ipp-status = 3DIGIT response-data = OCTET-STRING The first attribute in a response MAY be a "reason-phrase" and its value shall be a string which describes the status in human readable form. The value of the reason-phrase attribute is localized by the IPP server to the server's configured language. If a particular IPP request contains attribute names or attribute values that are not supported by the IPP service, the IPP server MAY return in the response the specific attribute or attributes that are not supported. If a particular attribute value is not supported, then the "attr-value" field will contain the value that was rejected by the server. If the requested attribute name was not supported, then the "attr-value-length" field for the name shall be set to "9999". For a complete list of IPP attributes, as well as attribute semantics and attribute values supported by this protocol, see the IPP Model Document. 3.1 PRINT-JOB A PRINT-JOB Request allows a user to submit a job with attributes and exactly one document. The following IPP attributes may be included with a PRINT-JOB request: ISSUE: I would like to propose a change in the "notification-events" and "notification-addresses" attribute names. The new names would be notify-events and notify-addresses. Is this ok? Its alot shorter to encode this way and I think it still carries the same semantics. Also, can we change "finishings" to "finishing"? job-name job-sheets notify-events notify-addresses job-priority job-hold-until multiple-documents-are best-effort media number-up sides printer-resolution print-quality copies finishing compression job-k-octets job-impressions job-media-sheets 3.1.1 PRINT-JOB-RESP A PRINT-JOB Request returns a PRINT-JOB-RESP message. Conforming IPP servers MUST return a "job-URI" attribute for a successful PRINT-JOB request. The IPP server MAY return a "reason-phrase" attribute as the first attribute in a response attribute set. In this case, the "job-URI" attribute would appear as the second attribute in the set. Otherwise, the "job-URI" MUST be the first attribute specified in the response attribute set. The IPP server MAY also return print job-related data with the response. This data is carried in the "operation-data" field within the message encoding. Job-related data would typically be "back-channel" or data returned via a Postscript or PJL query operation, for example. In addition to the "reason-phrase" and "job-URI" attributes, the following job attributes MAY also be returned: job-originating-user job-originating-host user-locale job-state job-state-reasons job-state-message output-device-assigned time-since-submission time-since-processing number-of-intervening-jobs job-message-from-operator time-since-completion job-k-octets-completed job-impressions-completed job-media-sheets-completed If an error is encountered by an IPP server during processing of the PRINT-JOB request, then the PRINT-JOB-RESP message will contain the "reason-phrase" attribute as the first attribute in the message. If the IPP status code indicates that the error was related to the processing of one or more attributes, then these attributes will be in the returned attribute set immediately after the "reason-phrase" attribute. [List possible status codes for this response] 3.2 PRINT-URI operation The PRINT-URI operation is similar in semantics to the PRINT-JOB operation, except no operation data (print job stream) is included in the request message. Instead, a URI is supplied within the request that serves as a "pointer" to where the document to be printed resides. At this point, it is up to the IPP server to interpret the URI and subsequently "pull" the document from the source referenced by the URI string. 3.2.1 PRINT-URI-RESP A client-generated PRINT-URI operation results in a PRINT-URI-RESP message from the IPP server. The status codes returned in the PRINT-URI-RESP message include all status codes returned by the PRINT-JOB-RESP message, and also additional codes to reflect whether or not the IPP server was successful in retrieving the specified document URI. [List status codes for URI-related document "pull" problems ] 3.3 CREATE-JOB operation A CREATE-JOB Request allows a user to submit a job with attributes only and then send the document(s) later in one or more SEND-DOCUMENT requests. If the CREATE-JOB request is successful, the IPP server creates a job object and returns the URI for this new object in the CREATE-JOB-RESP message. During the processing of a CREATE-JOB request, IPP servers validate requested job processing attributes (job template attributes) against what attributes are supported by the particular printer object (URI) to which the CREATE-JOB operation is directed. If the IPP server determines that processing can continue, some number of resources are allocated to handle the print job, including the selection of a physical printer to handle the job. IPP clients may elect to include a set of attributes describing processing requirements for the job being created. The allowable attributes to be included with a CREATE-JOB operation are identical to the attributes listed under the description for PRINT-JOB. 3.3.1 CREATE-JOB-RESP A CREATE-JOB Request returns a CREATE-JOB-RESP message. The syntax and semantics of the CREATE-JOB-RESP are identical to that of the PRINT-JOB-RESP message with the exception that there is no "response-data" field included with the CREATE-JOB-RESP message. [List possible status codes for this response] 3.4 SEND-DOCUMENT Request A SEND-DOCUMENT Request allows a user to send job data along with attributes that pertain to just that document. IPP clients typically transmit SEND-DOCUMENT requests after receiving a successful CREATE-JOB-RESP message from an IPP server. SEND-DOCUMENT requests are directed towards the job object referenced by the "job_URI" string returned in a successful CREATE-JOB-RESP message. SEND-DOCUMENT requests MAY include an attribute set describing document attributes to be applied only to the enclosed document. The allowable attributes for the SEND-DOCUMENT request are: job-URI document-name document-format end-document-stream The job-URI is the job object to which this document is to be applied. The document-name attribute specifies a name for the document that could be included in a separator or banner page included during printing of the job. The document-format specifies in what language the job stream is encoded. The "end-document-stream" attribute is specified on a SEND-DOCUMENT to notify the IPP server that no more documents are to be expected for this particular job. 3.4.1 SEND-DOCUMENT-RESP A SEND-DOCUMENT Request returns a SEND-DOCUMENT-RESP message. In addition to IPP status codes, the SEND-DOCUMENT-RESP can include an attribute set that specifies the current state of job processing. The following attributes can be returned by SEND-DOCUMENT-RESP: job-state job-state-reasons job-state-message The following status codes can be returned in a SEND-DOCUMENT-RESP message: [List possible IPP status codes that can be returned] 3.5 SEND-URI Request The SEND-URI request is similar to the PRINT-URI request in that no print job data is included in the request. Rather, a URI is specified that serves as a "pointer" to the actual document to be retrieved or "pulled" and printed. The allowable attributes that MAYbe included with a SEND-URI request are: document-uri document-name document-format end-document-stream For the SEND-URI request, the specification of the document-uri attribute is MANDATORY. Usage of the end-document-stream is identical to that of the SEND-DOCUMENT request. 3.5.1 SEND-URI-RESP A SEND-URI request generates a SEND-URI-RESP message from the server. The syntax and status code semantics for the SEND-URI-RESP message are identical to the PRINT-URI-RESP message. 3.6 VALIDATE Request A VALIDATE Request allows a user to send job attributes to the Printer to determine if such a job would print if submitted. The syntax and allowable attributes of the VALIDATE request are identical to the that of the CREATE-JOB request. The VALIDATE request is semantically equivalent to the CREATE-JOB request with the exception that no resources are allocated (i.e., job object) to process the job. The VALIDATE request is only used to verify capabilities of a printer object against whatever requirements are specified in the VALIDATE request. 3.6.1 VALIDATE-RESP A VALIDATE Request generates a VALIDATE-RESP message from an IPP server. The syntax of the VALIDATE-RESP is identical to the CREATE-JOB-RESP message with the exception that servers MUST NOT return a "job-URI" attribute within an attribute set. The status codes that MAY be returned in a VALIDATE-RESP message are: [ List possible status codes here ] 3.7 CANCEL Request A CANCEL Request allows a user to destroy a particular instance of a JOB object. Only JOB objects are supported as targets of a CANCEL request. 3.7.1 CANCEL-RESP A CANCEL Request generates a CANCEL-RESP message from an IPP server. The CANCEL-RESP message can contain an attribute set wherein the following attributes MAY be specified: job-state job-state-reasons job-state-message job-k-octets-completed job-impressions-completed job-media-sheets-completed time-since-submission time-since-processing job-originating-user job-originating-host The following IPP status codes MAY be returned in a CANCEL-RESP message [List possible status codes here] 3.8 GET-ATTR Request A GET-ATTR Request allows a user to obtain the attributes and attribute values associated with a particular object. The target URI of a GET-ATTR request can be a printer object or a job object. Both types of objects are referenced by their corresponding URI string. The attribute sets that can be requested by the GET-ATTR request depend upon the type of object (printer or job) to which the request is directed. For printer objects, the following attributes MAY be specified: printer-URI printer-location printer-description printer-more-info-site printer-driver-installer printer-make-and-model maximum-printer-speed printer-more-info-manf printer-state printer-state-reasons printer-state-message printer-is-accepting-jobs queued-job-count printer-message-from-operator printer-locate printer-locales-supported For job objects, the following attributes MAY be specified: job-name job-sheets notification-events notification-addresses job-priority job-hold-until multiple-documents-are best-effort media number-up printer-resolution print-quality copies finishing compression job-k-octets job-impressions job-media-sheets job-URI job-originating-user job-originating-host user-locale job-state job-state-reasons job-state-message output-device-assigned time-since-submission time-since-processing number-of-intervening-jobs job-message-from-operator time-since-completion job-k-octets-completed job-impressions-completed job-media-sheets-completed If a GET-ATTR request specifies no attributes, then all known attributes, and their associated values, will be returned by the IPP server for the specified object. 3.8.1 GET-ATTR-RESP A GET-ATTR Request generates a GET-ATTR-RESP message from an IPP server. The GET-ATTR-RESP message contains an attribute set that reflects the original requested attributes specified in the GET-ATTR request for a particular object. The GET-ATTR-RESP message will contain only those requested attributes that are supported by the IPP server for the requested object type (printer or job). Any unsupported attributes will not be included in the result attribute set. Note that for GET-ATTR-RESP messages, the return attribute set can contain multiple instances of the same attribute name. For example if a GET-ATTR request was made to a printer object and only one attribute, printer-locale, was specified, then the GET-ATTR-RESP attribute set would contain as many instances of the printer-locale attribute as was supported by the printer object. 3.9 GET-JOBS Request A GET-JOBS Request returns a list of jobs currently pending (queued) for a particular printer object. The IPP client can specify a "filter" that only returns jobs in a queue that match certain criteria. The criteria by which the resulting list is determined is specified by including an attribute set with the GET-JOBS request. The attribute set contains both filtering attributes, as well as a list of job attributes to be returned for each job in the printer queue. The filter attributes and job information attributes are contained within a single attribute set. The filter attributes are specified first, followed by the job information attributes. The GET-JOBS request supports the following attributes for filtering the returned job list: job-owner job-state If job-owner is specified, then only those jobs in the queue matching the value for the job-owner filter attribute will be returned. If the job-state is specified, then only those jobs in the queue that are currently in the specified job state value will be returned. For informational attributes, the GET-JOBS request supports all job attributes as specified in section 3.8. At a minimum, the GET-JOBS operation will always return at least a "job-URI" attribute for each job in the queue, whether the client specified this in request or not. ISSUE: should this operation get the printer attributes too? It saves an operation, but complicates the response. This is currently in the model, but we have talked about removing it. 3.9.1 GET-JOBS-RESP A GET-JOBS Request generates a GET-JOBS-RESP message from the IPP server. The requested job queue objects are returned in the order of job execution for the queue. The job list is encoded as a series of logical attribute sets, one per job object. Each logical attribute set is indicated by an initial "job-number" attribute. The value for the "job-number" attribute is a character-encoded number representing the position of this job in the queue (i.e., "1", "2", "3", etc.) Following the initial "job-number" attribute is the "job-URI" attribute for this job. The "job-URI" attribute is then followed by a series of job information attributes that reflect the attributes requested in the original GET-JOBS request. If the original GET-JOBS request specified attributes that are not supported by the IPP server, then those attributes will be absent from the returned attribute set for each job. 4.0 HTTP 1.1 General Headers Many of the headers specified by RFC 2068 do not have to be supported by general purpose HTTP clients and servers. The following text clarifies what IPP clients and servers should consider and the HTTP 1.1 conformance issues for each. 4.1 Cache-Control IPP servers and clients will have to operate within a caching proxy environment. In order to ensure a pure client and server environment between IPP clients and servers, caching of IPP requests and responses must be prohibited. The "Cache-Control:" general header MUST be included in all IPP requests and responses. The value for the "Cache-Control:" header directive would be "no-cache". Also, to make sure there are no HTTP 1.0 caching proxies between HTTP 1.1 clients and servers, IPP clients and servers MUST also include the "Pragma:" general header, also specifying "no-cache" as the value. It is conceivable that there would be some value in caching of attribute requests to IPP printer objects, since in a large environment, these requests might be very frequent. The IPP working group may want to consider the value in caching certain IPP object attribute requests. If caching of certain IPP response data is allowed, then we should also consider the use of the "no-transform" value for the "Cache-Control" directive. 4.2 Connection The "Connection:" general header SHOULD be used by IPP servers or IPP clients to instruct either a remote client or server that the HTTP connection be closed. For an IPP server that accepts CREATE-JOB/SEND-DOCUMENT sequences for job submission, the last SEND-DOCUMENT (POST) operation required to deliver the job data could include the "Connection:" header with the value "close" to instruct the server that the connection will be closed after reception of this request. 4.3 Content-Coding The "Content-Coding:" entity header field specifies how the entity body of a particular message is to be decoded. For HTTP, this is typically a compression encoding so the field would be "gzip" or "compressed". If the IPP working group wants to define a base set of content-codings, then the values for these codings would be specified in IPP messages via the "Content-Coding:" header. Content-Language: Like the "Content-Coding:" header, this header also specifies information related to the enclosed entity. The "Content-Coding:" header describes the natural language in which the entity body has been encoded. IPP servers should only return entities in languages that have been "agreed" upon by a particular client in a previously received "Accept-Language:" request header. 4.4 Content-Length The "Content-Length:" header specifies the size of a message body. IPP clients and servers will use the same algorithm as general-purpose HTTP 1.1 servers for determining the length of IPP messages. From RFC 2068, the description of the Content-Length header: Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. It must be possible for the recipient to reliably determine the end of HTTP/1.1 requests containing an entity-body, e.g., because the request has a valid Content-Length field, uses Transfer-Encoding: chunked or a multipart body. 4.5 Content-Type The Content-Type header would be used by IPP clients and servers to specify IPP-specific entities. The Content-Type value MUST be "application/ipp". IPP clients and servers MAY also supply a Content-Type modifier "charset", as part of the applicaion/ipp Content-Type. The "charset" modifier would specify the character set used within the application/ipp entity body. 4.6 Date The "Date:" header field is currently specified in the HTTP 1.1 document as a MUST header by all compliant implementations. The date format used as the value of this header must be in RFC 1123 format. There is a recent internet draft that has been published that attempts to describe how some embedded, lightweight HTTP server implementations can still be "compliant" even if they don't contain any realtime clock or time capabilities. 4.7 Pragma The "Pragma:" directive would only be used by IPP implementations for backwards compatibility with HTTP 1.0 caching proxies. The Pragma header would specify the value "no-cache", which is understood by HTTP 1.0 proxies to have the same semantics as the HTTP 1.1 "Cache-Control" directive with the value "no-cache". 4.8 Transfer-Encoding: For HTTP 1.1, the only "Transfer-Encoding" specified is the "chunked" encoding. Since an HTTP connection is "8-bit clean", the traditional rationale for transfer-encodings (like used in MIME) are unneeded. But when IPP implementations are attempting to send messages for which the total length of the message cannot be determined, then the message should be transferred as "chunked" or via a multipart message with message boundaries. The current HTTP specification requires that all HTTP 1.1 applications MUST be able to receive and decode the chunked transfer encoding. 5.0 HTTP 1.1 Request Headers 5.1 Accept The Accept: header is used to specify certain media types that a client is willing accept as a result of a request to a server. IPP clients SHOULD always specify (at a minimum) application/ipp, text/html, and text/plain. 5.2 Accept-Charset This header indicates to servers what character sets a client is willing to accept in a response. According to the HTTP 1.1 specification, all clients should be able to support ISO-8859-1. 5.3 Accept-Encoding Similar to "Accept:", the Accept-Encoding header is sent from client to server to inform the server what types of encoding of responses that the client can handle. 5.4 Accept-Language IPP clients SHOULD send Accept-Language headers in IPP requests to notify IPP servers what type of localization is acceptable to the client. 5.5 Authorization IPP servers may protect certain types of IPP objects via HTTP basic authentication. If an IPP client has knowledge that a requested resource requires basic authentication, then an appropriate "Authorization:" request header should be included in all IPP requests to the IPP object (URI) in question. The client can also dynamically learn of the authentication requirements for a particular object if the client attempts to access the object without an authentication header. IPP servers that receive un-authenticated requests for IPP objects that require basic authentication would return a status code of 401, which indicates to clients that authentication is required for accessing the requested object. It is assumed that, for the lifetime of a particular IPP object (URI), that the user's credentials (once successfully validated) will be valid. Therefore, on the first successful authenticated response to a request, IPP clients can cache the user's credentials and reuse these credentials on subsequent requests to the server for this object. Each subsequent request for the IPP object (URI) would include an "Authorization:" header specifying the cached credentials. 5.6 From The "From:" header contains the internet e-mail address for the human individual that is responsible for the request being generated. The IPP working group has talked about using the "From:" header as a means for some type of authentication or access protection. The current HTTP 1.1 specification states that the "From:" header "SHOULD NOT be used as an insecure method of access protection". The specification goes on to say that "the interpretation of this field is that the request is being performed on behalf of the user specified by the "From:" header, who accepts responsibility for the operation being performed.". The following paragraph from RFC 2068 is especially relevant: Note: The client SHOULD not send the From header field without the user's approval, as it may conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request. 5.7 Host The "Host:" field typically comes on a separate line after the HTTP method specification. This field MUST be set by HTTP 1.1 clients with the network location of the specified URI in the method. All internet-based HTTP 1.1 servers MUST respond with a 400 status code to any HTTP 1.1 request message which lacks a "Host:" header. This header is used by newer WEB server sites for so-called "virtual host" access. IPP could utilize this field in some very interesting ways with regards to multiple logical printers serviced by a single IPP/HTTP server. 5.8 Proxy-Authorization When there is an HTTP 1.1 caching proxy operating in between an IPP client and server, it is possible that certain resources identified by a site administrator might require basic authentication. If an IPP client receives a 407 response to a valid IPP request, the client should format an authorization request back to the requested resource (URI) using the "Proxy-Authorization:" request header. Section 11 of RFC 2068 discusses HTTP authorization in detail. 6.0 HTTP 1.1 Response Headers 6.1 Allow The "Allow:" entity header field MUST be returned by IPP servers to notify IPP clients which HTTP methods are allowed to be executed on a particular URI (or IPP object). In the future, we may want to define conformance levels with respect to IPP, wherein some IPP servers implement all possible methods on IPP objects, and other lighter weight IPP servers are restricted in the domain of methods supported on IPP objects. The "Allow:" header permits interoperability between clients and servers of different capabilities. The client can adapt its behavior to the capabilities it learns from a particular server. 6.2 Location The "Location:" header MAY be used by IPP servers to dynamically redirect IPP clients to other URIs that can be contacted for completing the client's request. The Location header could be used as a replacement for the multiple-URL facility discussed in the early IPP-over-HTTP internet draft. IPP implementations would follow the direction set forth by the current HTTP 1.1 specification: "for 201 ("Created") responses, the "Location" is that of the new resource created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URL for automatic redirection to the resource." The term "resource" used in the above paragraph would normally be a URI referencing an IPP job object. 6.3 Proxy-Authenticate It is possible that, in the presence of caching HTTP 1.1 proxies, that IPP client implementations may have to deal with "Proxy-Authenticate" responses. The "Proxy-Authenticate" response header could be returned as part of a 407 (Proxy Authentication Required) response. (see also Proxy-Authorization request header). IPP clients SHOULD support proxy-authorization. 6.4 Public The "Public:" response header SHOULD be used by IPP servers to inform IPP clients what types of HTTP methods are supported by the server. The "Public" response header would typically be used by very lightweight HTTP/IPP server implementations that implement a minimal IPP capability. 6.5 Retry-After The "Retry-After" response header would be used in tandem with the 503 (Service Unavailable) response code to indicate how long the resource (or service) is to remain unavailable. This could be used by IPP servers to indicate how long a printing service might be unavailable to IPP clients. 6.6 WWW-Authenticate The WWW-Authenticate response header is used to initiate basic HTTP authentication. If an IPP client receives a 401 (Unauthorized) response to an IPP request, then the response MAY contain a "WWW-Authenticate" header with an appropriate challenge. The next request for this resource formulated by the IPP client SHOULD contain an "Authorization" header specifying appropriate credentials. 7.0 Security Considerations When utilizing HTTP 1.1 as a transport for IPP, all of the security considerations specified in RFC 2068 apply. In addition, the IPP adds some additional application-specific security considerations, including denial-of-service attacks, mutual authentication, and privacy. The IPP Model document addresses IPP-specific security considerations, while RFC 2068 addresses HTTP-related security considerations. ISSUE: the security subgroup is free to add whatever is necessary to fill out the "security considerations" section of this document. However, the IPP model document should include the bulk of security discussions that are IPP-specific. Appendix A - Transport Requirements Some transports, such as raw TCP/IP, don't have a way to specify length or carry along attributes that pertain to the transport. An example of such an attribute is the compression encoding for the operation. In addition, the target URI needs to be specified as a transport attribute. This section specifies the encoding for such cases. The encoding is defined as follows: transport-encoding = transport-version transport-attributes transport-operation transport-version = transport-major-version transport-minor-version transport-major-version = one-byte-integer ; major version in binary, initially 1 transport-minor-version = one-byte-integer ; minor version in binary, initially 0 transport-attributes = attribute-length *attribute transport-operation = ( type-zero operation-encoding ) | ( type-one 1*transport-chunk ) type-zero = byte-value-zero ;; a byte with binary 0 type-one = byte-value-one ;; a byte with binary 1 transport-chunk = transport-data-length transport-data transport-data-length = four-byte-integer ; number of octets of the data in binary transport-data = octet-string The transport-version shall be the version for this syntax and is separate from the operation-version. A zero length transport-chunk shall denote the end of the transport-operation. The transport-data contains fragments of the operation. When all the transport-chunks are concatenated together, they shall form a complete operation. The first attribute in the transport-header for a request shall be the attribute "URI" which is the target object of the operation. ISSUE: is the URI sufficiently important that it should have its own field that doesn't require looking for the URI attribute. ISSUE: should the status and reason-phrase be in the transport-header instead of the operation-header for the responses? ISSUE: is the type-zero and type-one encoding worth the complexity to save specifying the same length twice for data-less operations - once at the transport level and once at the operation level. The type-one encoding is the most compatible with HTTP. The transport-operation may use type-zero encoding for operation-encodings with no operation-data. References [RFC 2068] [IPP Model Document]