draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          
          
          
          
          
          
          
          HTTP 1.1 as a Transport 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 learn the current status of any Internet-Draft, please check
          the "1id-abstract.txt" listing contained in the Internet-Drafts
          Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
          (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
          Coast), or ftp.isi.edu (US West Coast).
          
          Abstract
          
          The definition of the Internet Printing Protocol (IPP) is
          specified abstractly, and does not detail a particular
          implementation. The abstract definition of IPP is contained
          within the "IPP Model" document, a separate document available at
          the Printer Working Group IPP web page HTTP://www.pwg.org/. This
          document attempts to map IPP Model operations and semantics to
          HTTP 1.1 equivalent operations.
          
          
          
          
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       1
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          
          
          1. Overview                                                     4
          
          
          2.  HTTP Mapping Strategy                                       5
          
          
          3. PRINT Operation                                              7
          
          
          3.1 Create-JOB                                                  9
          
          
          3.2 Send-Job                                                    9
          
          
          4. QUERY                                                       10
          
          
          5. Cancel                                                      11
          
          
          6. Interoperability with Existing (IPP-unaware) Browsers       11
          
          
          6.1 IPP PRINT Operation                                        11
          
          
          6.2 Query                                                      13
          
          
          6.3 Cancel                                                     13
          
          
          7. Practical Considerations                                    14
          
          
          7.1 HTTP 1.1 Persistent Connections                            14
          
          
          7.2 Cache Control Directives                                   15
          
          
          7.3 Protocol Error Handling                                    16
          
          
          8. Security Considerations                                     16
          
          
          9. Internationalization/Localization Issues                    17
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       2
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          10. References                                                 19
          
          
          11. Contacts                                                   19
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       3
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          
          
          1. Overview
          
          
          The actual implementation of HTTP 1.1 as a transport can come in
          several flavors, depending upon the disposition of the clients
          and servers. The following client-server implementations for IPP-
          over-HTTP are possible:
          
          
              Client               IPP Server
          
          1) HTTP 1.1 Browser      HTTP 1.1 Server w/CGI-based IPP
          2) HTTP IPP Client       HTTP 1.1 Server w/CGI-based IPP
          3) HTTP 1.1 Browser      HTTP-capable IPP Server
          4) HTTP IPP Client       HTTP-capable IPP Server
          
          Other combinations of the above scenarios can also be constructed
          but the fundamental direct client/server relationships are
          included in the above scenarios. This document does not directly
          deal with the fact that in HTTP topologies, intermediaries such
          as proxies and gateways may exist.
          
          The "HTTP IPP Client" in the above list of scenarios is a
          dedicated IPP client entity (true-client) that implements IPP-
          over-HTTP. This is in contrast to a HTTP browser which is
          essentially unaware that it is utilizing IPP services over HTTP.
          Use of a browser as an IPP client is discussed later in this
          document. An "HTTP-capable IPP server" is an instance of an IPP
          service that happens to support IPP-over-HTTP directly, for
          example using a dedicated TCP port number. This is in contrast to
          an "HTTP 1.1 Server w/CGI-based IPP" where the actual IPP service
          is performed by CGI-based scripts or other executable content and
          the bulk of the HTTP protocol is handled by a generic HTTP
          server.
          
          Slight variations exist in the type of support that clients and
          servers would offer within the context of IPP over HTTP. In the
          following sections, the base IPP-over-HTTP specification will be
          presented, with these implementation variants noted where
          appropriate. When referenced in the following text, the above
          scenarios will be highlighted by using the terms "scenario (1)",
          "scenario (2)", etc.
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       4
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          A true-client is an IPP-aware entity that is fully compliant with
          the IPP protocol, as specified by this document.
          
          It is possible that future releases of web browsers will have
          true IPP client capability but there will always be the legacy
          case where support for some level of interoperability between
          non-IPP-aware browsers and IPP servers is required.
          
          This protocol contains "hooks" to allow IPP servers to return
          status and query information about IPP services and IPP print
          jobs in human readable form. These "hooks" do not require special
          extensions or other non-HTTP compliant capabilities. Within this
          document, IPP responses are said to be processed by "external"
          means or by IPP automata (such as true IPP clients). An external
          IPP entity could be a end-user (human) consumer, or a custom
          extension or "plug-in" to a web browser.
          
          This document also makes use of object references similar to the
          IPP Model document. "PRINTER" objects are referenced by clients
          using a specific URL identifier. "JOB" objects are also
          referenced by a specific URL identifier.
          
          Also, PRINTER objects come in two forms: there is the "root" URL
          for the IPP Printing Service which could reference a logical or
          physical printing device, and also a specific "Job-Data" URL
          PRINTER object. Again, in a very simple print system topology,
          these two object identification URL strings could point to the
          same object. The "root" URL for a printing service is the URL
          string that would be advertised by a directory service or by
          other means. The "Job-Data" PRINTER object URL is the PRINTER
          object that is assigned to process a particular instance of a
          print JOB object, as explained later in this document.
          
          
          2.  HTTP Mapping Strategy
          
          
          This document proposes using HTTP POST operations for mapping IPP
          abstract operations. Using the HTTP POST method attempts to
          emulate a traditional request/response protocol that might be
          used if IPP were mapped directly onto TCP with a dedicated port
          number.
          
          In the traditional case, a packet-oriented client/server protocol
          would utilize the following header fields:
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       5
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          
                    Packet-Protocol
                    Packet-Length
                    Protocol-version
                    Protocol-operation
                    .
                    . Protocol-operation specific data
                    .
          
          It is likely that IPP will be mapped onto other transport
          protocols in the future, and a traditional protocol mapping
          approach has been used to "translate" the traditional protocol-
          encapsulation techniques into HTTP capabilities.
          
          The following mapping is used to translate these traditional
          packet header fields into the HTTP framework:
          
          Packet-Protocol :
          
          Since we are re-using HTTP to carry another type of application
          protocol, we need a way to key HTTP messages with a particular
          protocol tag. In this document, the HTTP Entity-Header "Content-
          Type" is keyed with the value "application/IPP" to denote the
          specific module that should handle this type of message.
          
          Packet-Length :
          
          The Packet-Length field is directly mapped to the HTTP entity
          header "Content-Length". The Content-Length field specifies how
          many bytes are contained within the entity body.
          
          Protocol-Version :
          
          Protocol-Operation :
          
          The protocol operation field is the first IPP application-
          specific field encoded into a packet - this is due to the fact
          that the syntax and semantics of the remainder of the packet
          contents varies depending upon the operation field.
          
          
          Once this protocol header is decoded, the actual packet (or
          entity body in HTTP) is the same for all protocol mappings. The
          "encoding" of the packet or entity body might be different, but
          the ordering of fields, data-types used, and semantic content are
          
          
          
          draft-turner-ipp-trans-develop-00
                                       6
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          the same for all protocol mappings. The tighter we keep the
          protocol mapping model, the easier it will be to design gateway
          implementations (from protocol mapping to another protocol
          mapping) in the future. This is the primary reason for discussing
          protocol mapping methods in this document. For the purposes of
          this document, the encoding of the actual application-specific
          portion of the packet (non-header fields) is specified by the
          HTTP entity-header "Content-Encoding".
          
          In the following sections each of the three abstract IPP
          operations PRINT, QUERY, and CANCEL are discussed in detail.
          Subsequent versions of this specification will describe the
          requests and responses in more detail. This initial specification
          seeks only to describe fundamental ideas related to using HTTP
          1.1 as a transport for IPP.
          
          
          
          
          3. PRINT Operation
          
          
          In this mapping document, the IPP model PRINT operation is broken
          into three separate underlying HTTP operations. As previously
          mentioned, all IPP operations over HTTP are implemented via the
          HTTP "POST" operation. The three independent operations that make
          up the abstract PRINT operation are
          
                    Create-Job
                    Send-Job
          
          The "Create-Job" POST operation requests that the target IPP
          server create an instance of a print job and return job object
          identification information back to the client. There are three
          job identification items that are returned, each formatted as a
          standard URL string:
          
          1. J
              ob-Data-URL
          2.
             Job-Status-URL
          3.
             Job-Modify-URL
          
          The rationale for returning three separate URLs for subsequent
          access to a job are two-fold: in the first case, having three
          separate targets for data, status, and modification for a job
          allows the protocol to scale to widely different printing system
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       7
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          topologies, from simple peer-to-peer printing all the way to
          complex logical/physical printer spooling systems as described by
          the ISO Document Print Application (DPA) standard. For simple
          peer-to-peer printing systems wherein a client is communicating
          directly with the physical printing device, the IPP server in the
          printing device could potentially return all three URLs (data,
          status, and modify) with the
          same value. For more complicated systems with intermediate
          spooling servers and fully distributed logical and physical
          printing configurations, there could potentially be three
          different IPP entities (not necessarily hosts) that are
          responsible for each type of information.
          
          The second reason for returning three separate URL strings for
          each type of information concerns the security aspects
          surrounding each type of information access. For each type of
          access (data, status, and modification), there may be different
          security policies in force for a particular site. Each URL may be
          coded differently to indicate a particular level of security
          attached to each type of print job information access. Again,
          this is an elaborate printing environment that would support
          these types of policies, but as stated previously, the URL
          strings could all be the same value to scale to very simple peer-
          to-peer topologies.
          
          The "Job-Data-URL" string identifies a target for subsequent
          delivery of actual print job data (i.e., raster data or page
          description language streams).
          
          The "Job-Status-URL" string identifies a target whereby
          subsequent requests for job status for this job should be
          forwarded (See QUERY/JOB-ATTRIBUTES).
          
          The "Job-Modify-URL" string identifies a target whereby requests
          to modify the disposition of a job should be forwarded. For
          version 1.0 of this protocol, only the CANCEL sub-operation is
          supported via this mechanism. However, future additions to job
          modification capabilities over IPP would be instrumented through
          this URL target.
          
          
          3.1 Create-JOB
          
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       8
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          The POST operation for "Create-Job" contains an "application/ipp"
          entity body that contains any production attributes that should
          be applied to this job instance.
          
          Details of the exact format of this, and all, entity bodies
          associated with the "application/ipp" type will be discussed in
          future versions of this document.
          
          The response to a root IPP URL POST operation will also return a
          message body with an entity type of "application/ipp". Contained
          within this entity-body will be the job identifiers formatted as
          the "Job-Data" URL, the "Job-Status" URL, and "Job-Modify" URL
          strings as discussed earlier in the previous section.
          
          To elaborate on the actual syntax of these URL strings, it should
          be noted that each one of these URL strings will be encoded with
          some IPP server-assigned job-identification string which is a
          unique identifier within the administrative domain of the IPP
          print service. Practically, this job-identification should be
          encoded as a CGI-style parameter within the URL-formatted string.
          
          
          3.2 Send-Job
          
          
          A single POST operation to the Job-Data-URL will deliver the
          print job data to the IPP service. It is recommended that the
          content-type for POSTing of print job data be "application/octet-
          stream", although if the particular format of the job data is
          known, then this information could be passed to the IPP service
          via a registered MIME content-type specific to the application
          data stream (i.e., "application/postscript"). Each POST operation
          will contain an IPP-specific message body with appropriate HTTP
          entity-headers for Content-Length and Content-Encoding. In some
          cases, the IPP client will know in advance the total number of
          bytes that are contained within a particular job data stream. If
          this is known, then the length of the entity body is specified by
          the "Content-Length" header. If for some reason, the IPP client
          does not know how many total bytes of job stream data will be
          sent, then a MIME "chunked" encoding should be used, with each
          segment being tagged with the particular "Content-Length" for
          that segment. IPP servers should be prepared to handle "Content-
          Transfer-Encoding" headers for print job data as well. Some level
          of Content-Transfer-Encoding may be required to transfer
          particular types of print job raster data or page description
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       9
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          language (PDL) streams. Future versions of this specification
          will include a base set of Content-Transfer-Encoding types that
          should minimally be supported by IPP clients and servers.
          
          
          4. QUERY
          
          
          QUERY operations allow a client to inquire as to the operational
          attributes or status of a particular IPP object (printer object
          or job object). As previously discussed, there are four different
          URL objects that are referenced within the IPP: the "root" URL
          for the Printing Service, and the three URL objects returned from
          a successful "Create-Job" operation: Job-Data-URL, Job-Status-
          URL, and Job-Cancel-URL. Different results are obtained depending
          upon which URL object is queried.
          
          A QUERY directed towards the "root" IPP service URL will return
          operational attributes associated with the print service, as well
          as a list of currently active and pending print jobs within the
          print service. A QUERY directed towards the "Job-Status" URL
          object returns the current state of the print job referenced by
          the "Job-Status" URL.
          
          All QUERY requests are submitted via the HTTP POST operation,
          with requests and responses encoded within an "application/ipp"
          entity body.
          
          
          5. Cancel
          
          
          Previously submitted print jobs can be cancelled via a POST
          operation to the "Job-Modify-URL", with the CANCEL request
          modifier specified in an "application/ipp" entity body. As stated
          previously, the initial version 1.0 of IPP will only support the
          CANCEL sub-operation. However, future job modification requests
          will also be posted to this URL as well.
          
          It is anticipated that initial requirements for robust
          authentication mechanisms will be associated with this particular
          "Job-Modify" URL specification. Ordinarily, an IPP service would
          require client authentication to verify that the client
          submitting the job-modify request is the same client that
          originally submitted the print job. This additional object
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       10
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          security requirement could be communicated to clients via the URL
          protocol field (i.e., HTTPS or HTTP).
          
          
          6. Interoperability with Existing (IPP-unaware) Browsers
          
          
          The following paragraphs discuss how the IPP operations PRINT,
          QUERY, and CANCEL are supported through existing browser
          implementations. This discussion assumes that the root URL for an
          IPP printing service has already been obtained and is displayed
          as a hyperlink on an HTTP browser display.
          
          
          6.1 IPP PRINT Operation
          
          
          Typically, the user will obtain a URL link to a root IPP service
          through a directory service or "bookmark" database. The user will
          then click on the link causing an HTTP GET operation to be
          performed. Unlike the core IPP protocol which uses POST methods
          for all requests into the IPP service, a GET request into an IPP
          server is a hint that the IPP client is really a browser, and not
          a true IPP-aware client entity. If an IPP service receives a GET
          request on its root URL, the service will return a formatted HTML
          response, as opposed to a "application/ipp" entity-type.
          
          An HTTP GET operation to a IPP root URL will return an HTML-
          formatted response that displays, in human-readable form, the
          operational attributes of the IPP service, as well as an HTML
          form capable of enabling the end-user to print one or more files.
          Each IPP server implementation may return a different "look-and-
          feel" associated with the HTML interface, but the attribute names
          and semantics MUST remain consistent for all implementations.
          
          As a part of the response to this client GET request, IPP server
          implementations SHOULD use the "Form-Based File Upload" technique
          described in RFC 1867. Using this capability, users can send one
          or more arbitrary files for printing to an IPP service. More
          importantly, RFC 1867 form-based file upload includes the
          capability for sending the form data, and the file contents, to
          an alternate URL destination for printing. This feature is
          required since the actual form-action method (POST) will not be
          encoded with IPP-specific protocol (entity-bodies), and could not
          be sent to a standard IPP-compliant service URL.
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       11
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          The destination URL for the form-based file upload action is a
          dedicated target service that has been readied to receive the job
          stream being delivered via the RFC-1867 method. This would
          probably be a different URL specification than the root URL, as
          previously mentioned.
          
          The response to submitting the file via the form-based file
          upload method would be similar to the true IPP client "Job-
          Create" response. The IPP service would return the same three
          job-identifier URL strings as links, either as typical
          highlighted links, or as possibly part of another HTML form with
          image-mapped links, or basically whatever format the server
          chooses.
          
          
          
          
          
          
          
          6.2 Query
          
          
          Existing browsers are able to query both PRINTER objects as well
          as JOB objects. The same GET operation that is used to obtain the
          PRINT operation form (outlined in section 5.1) could also contain
          information in an HTML page (or pages) that contains informative
          attributes regarding the print service, which satisfies the QUERY
          PRINT object requirement. Essentially, a particular IPP
          implementation is free to design the root print service GET
          response to be whatever that particular implementation of IPP
          requires. On this same page could be another link, or GUI
          control, that displays the active jobs pending for the print
          service.
          
          As discussed in section 5.1, the response to a print job
          submission (via the form-based file upload mechanism) would be
          the IPP-Assigned-Printer, STATUS, and CANCEL URL identifiers that
          are associated with the newly created job. To obtain status on
          this job submission, the user could just click on the STATUS
          link, which would cause an HTTP GET operation to be performed.
          The response to this GET operation could be a brief or detailed
          status on the job.
          
          6.3 Cancel
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       12
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          Similar to the QUERY on the job status URL object, the browser
          end-user would employ the same technique to CANCEL a particular
          job. The HTML page that resulted from the job submission also
          contains the CANCEL hyperlink. The user could just click on this
          link which would cause an HTTP GET operation on the CANCEL URL.
          The response to this GET request would be an HTML page indicating
          success or failure. Optionally, if the CANCEL URL specifies some
          level of security (i.e., via a link of the form HTTPS://), then
          the response would be some type of authentication challenge that
          requires the user to authenticate him or herself prior to
          continuing the CANCEL operation. In most implementations, any
          type of job modification operation would require that the client
          authentication match the authenticated client that originally
          submitted the job.
          
          From the IPP server's perspective, the key to determining whether
          or not a specific request is from a browser, or a true IPP
          client, is through the type of HTTP request. True IPP clients
          accomplish their requests using the HTTP POST method on URL
          objects, while traditional browsers would utilize the HTTP GET
          method on URL objects.
          
          
          7. Practical Considerations
          
          
          
          7.1 HTTP 1.1 Persistent Connections
          
          
          Most HTTP 1.1 server implementations will choose to support
          persistent connections by default (see RFC 2068 for a discussion
          and rationale for use of persistent connections). In the case of
          IPP-over-HTTP, support for persistent connections is a key
          requirement for adequate protocol performance. This is especially
          important for IPP clients that choose to deliver bulk job data in
          two or more POST operations. In IPP client-server scenarios
          (1),(2), and (3), IPP servers may not have the ability to sustain
          persistent connections, since either the client, or the server,
          is not IPP aware, and there is not IPP-specific automata that can
          maintain the persistent connection between client and server. In
          scenarios (1) and (2), the generic HTTP server controls the
          opening and closing of actual network connections, not the CGI-
          based IPP "handler". And in the case of a browser acting as an
          IPP client, the IPP server can do nothing to stop a browser from
          closing the connection once a response to an operation is
          
          
          
          draft-turner-ipp-trans-develop-00
                                       13
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          received; this is especially true if a legacy HTTP 1.0 browser is
          used.
          
          Also, in the scenarios above that utilize CGI-based IPP server
          solutions, all of the same semantics would apply to any external
          IPP processing entity (such as Microsoft ISAPI-based
          implementations)
          
          
          7.2 Cache Control Directives
          
          
          It is recommended that all IPP-over-HTTP requests and responses
          be tagged with a HTTP "Pragma" header of "no-cache". This tag
          should also be mirrored into the HTTP 1.1 Cache-Control
          directive. Operation of the IPP-over-HTTP protocol is undefined
          in the presence of caching of requests or responses, and further
          analysis of this caching should be done before allowing this
          capability into the protocol. This analysis would probably
          incomplete until sufficient prototypes have been deployed and
          operation experience obtained.
          
          In RFC 2068 (HTTP 1.1), there is a "no-transform" directive
          defined. The following description of the "no-transform"
          directive and its rationale is taken directly from RFC 2068:
          
          From RFC 2068:
          [ Implementers of intermediate caches (proxies) have found it
          useful to convert the media type of certain entity bodies. A
          proxy might, for example, convert between image formats in order
          to save cache space or to reduce the amount of traffic on a slow
          link. HTTP has to date been silent on these transformations.
          
          Serious operational problems have already occurred, however, when
          these transformations have been applied to entity bodies intended
          for certain kinds of applications. For example, applications for
          medical imaging, scientific data analysis and those using end-to-
          end authentication, all depend on receiving an entity body that
          is bit for bit identical to the original entity-body.
          
          Therefore, if a response includes the no-transform directive, an
          intermediate cache or proxy MUST NOT change those headers that
          are listed in section 13.5.2 as being subject to the no-transform
          directive.  This implies that the cache or proxy must not change
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       14
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          any aspect of the entity-body that is specified by these headers.
          ]
          
          Because of the risk imposed to varying kinds of print job data
          streams and content-encodings that might be used to implement IPP
          over HTTP, it is strongly recommended that usage of the "no-
          transform" directive for requests and responses be employed for
          all implementations of IPP clients and servers. The exception to
          this rule is in the case of IPP-over-HTTP scenarios wherein
          either a generic WEB server or generic browsers are used. In
          these instances, the IPP service layer or component may not be
          able to force the usage of the "no-transform" directive.
          
          
          7.3 Protocol Error Handling
          
          
          IPP client implementations will have to handle errors on two
          different levels, depending upon the operational scenario(s) (1
          through 4 outlined above) that the print service supports. For
          browser-based IPP clients, the end-user is responsible for
          "handling" errors returned via HTTP operations. These errors will
          be returned in HTML format by the IPP service, or automatically
          generated HTML format by the HTTP browser in the event of a
          generic HTTP error.
          
          True IPP client implementations will have to handle both HTTP
          protocol errors, as well as IPP-specific protocol errors embedded
          in IPP response messages.
          
          8. Security Considerations
          
          
          The same types of security considerations affecting the transport
          of IPP over HTTP apply for the base HTTP 1.1 specification as
          well. The IPP Model document and subsequent protocol mapping
          documents contain no explicit support for security operations. It
          is assumed that an underlying (at some protocol layer below IPP)
          transport layer mechanism will be responsible for the security.
          The IPP working group has acknowledged the requirement for a very
          robust authentication mechanism, and has also considered privacy
          as an option as well. It is anticipated that both the
          authentication requirement and optional privacy capability will
          be handled by underlying protocols such as a Secure Sockets Layer
          (SSL) v3 implementation. In the case of IPP Scenario(1) mentioned
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       15
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          previously in this document, it is assumed that SSL v3.0 will be
          available.
          
          Multiple layers of security are supported by this protocol
          mapping document, as specified by the PRINT operation response
          methodology. IPP Server administrators may choose to advertise
          IPP services (via the IPP "root" URL) as secure (HTTPS://) or
          non-secure (HTTP://). It would also be possible for IPP servers
          implementing IPP-over-HTTP to utilize basic HTTP authentication
          (as specified in RFC 2068). HTTP Digest Authentication (RFC 2069)
          could also be utilized to provide a higher level of secure
          authentication; one that doesn't require passwords to be sent as
          clear text. In some printing environments, however, two-way
          authentication may be required wherein the IPP client and IPP
          server authenticate each other. In this situation, IPP
          implementations would have to rely on external means to achieve
          the desired security requirements (external in this case meaning
          SSL v3 or IPSEC or other means).
          
          One possible issue with the use of SSLv3 is its current status
          within the IETF standards-track, and whether or not this would
          cause problems with its acceptance and the possibility of wide-
          spread deployment. One of the key criteria for the establishment
          of a security solution for IPP is wide-spread availability and
          adoption of a security solution.
          
          
          9. Internationalization/Localization Issues
          
          
          Localization of protocol information destined for human
          consumption (names, descriptions, etc.) can either be performed
          by explicit use of IPP-specific mechanisms, or, HTTP Accept-
          Headers can be used by IPP clients to indicate to IPP servers the
          type of language and/or character set that the client entity
          wants to see for the associated response.
          
          Sending Accept-Headers with every request might seem somewhat
          protocol inefficient with regards to this "extra information"
          that must be sent for each request, but in complex printing
          environments, depending upon the type of request, requests might
          be sent to different server entities, so there is either initial
          setup/negotiation overhead to deal with for each and every
          server, or the client can only send Accept-Headers to service
          entities for which client requests are actually required. Also,
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       16
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          it might prove advantageous to keep the protocol as stateless as
          possible, due to the fact that future versions will deal with
          checkpoint/restart of print jobs, and other types of "crash"
          recovery. The less state we have to save and restore the better.
          
          Use of IPP-specific localization support within IPP-over-HTTP
          entity bodies might prove to be a more straightforward approach
          in that some protocol design re-use could be employed when other
          IPP transport mapping documents are generated. Also, along this
          same reasoning, gateways between different IPP/Transport
          combinations would be more easily conceptualized and understood.
          
          This document does not specifically call out either mechanism due
          to the fact that no prototyping experience has been gained using
          either method. A later and more detailed version of this document
          will elaborate on a decision from the IPP working group regarding
          localization for IPP-over-HTTP and include rationale for this
          decision.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       17
          
          
          draft-turner-ipp-trans-develop-00               Randy Turner
          Expires September 1997         Sharp Laboratories of America
                                                            March 1997
          
          
          
          
          10. References
          
          
          [1] deBry R., Hastings T., Herriot B., Isaacson S., "Internet
          Printing Protocol/1.0 Model and Semantics", IBM, Xerox, Sun,
          Novell, March 1997
          
          [RFC - 2068] Fielding R., Gettys J., Mogul J., Frystyk H.,
          Berners-Lee T., "Hypertext Transfer Protocol - HTTP 1.1", UC-
          Irvine, DEC, MIT/LCS, January 1997
          
          [RFC - 1867] Nebel E., Masinter L., "Form-based File Upload in
          HTML", Xerox Corporation, November 1995
          
          [RFC - 2069] Frank J., Hallam-Baker P., Hostetler J., Leach P.,
          Luotonen A., Sink E., Stewart L., "An Extension to HTTP - Digest
          Access Authentication", Northwestern Univ, CERN, Spyglass,
          Microsoft, Netscape, Open Market, January 1997
          
          
          11. Contacts
          
          
          Randy Turner
          Member of Technical Staff
          Sharp Laboratories of America
          5750 NW Pacific Rim Blvd
          Camas, WA 98607
          rturner@sharplabs.com
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          draft-turner-ipp-trans-develop-00
                                       18