home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-turner-ipp-trans-develop-00.txt < prev    next >
Text File  |  1997-03-25  |  41KB  |  1,050 lines
  1.  
  2.           draft-turner-ipp-trans-develop-00               Randy Turner
  3.           Expires September 1997         Sharp Laboratories of America
  4.                                                             March 1997
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.           HTTP 1.1 as a Transport for the Internet Printing Protocol
  15.  
  16.  
  17.  
  18.           Status of this Memo
  19.  
  20.           This document is an Internet-Draft.  Internet-Drafts are working
  21.           documents of the Internet Engineering task Force (IETF), its
  22.           areas, and its working groups.  Note that other groups may also
  23.           distribute working documents as Internet-Drafts.
  24.  
  25.           Internet-Drafts are draft documents valid for a maximum of six
  26.           months and may be updated, replaced, or obsoleted by other
  27.           documents at any time.  It is inappropriate to use Internet-
  28.           Drafts as reference material or to cite them other than as "work
  29.           in progress".
  30.  
  31.           To learn the current status of any Internet-Draft, please check
  32.           the "1id-abstract.txt" listing contained in the Internet-Drafts
  33.           Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  34.           (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  35.           Coast), or ftp.isi.edu (US West Coast).
  36.  
  37.           Abstract
  38.  
  39.           The definition of the Internet Printing Protocol (IPP) is
  40.           specified abstractly, and does not detail a particular
  41.           implementation. The abstract definition of IPP is contained
  42.           within the "IPP Model" document, a separate document available at
  43.           the Printer Working Group IPP web page HTTP://www.pwg.org/. This
  44.           document attempts to map IPP Model operations and semantics to
  45.           HTTP 1.1 equivalent operations.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.           draft-turner-ipp-trans-develop-00
  56.                                        1
  57.  
  58.  
  59.           draft-turner-ipp-trans-develop-00               Randy Turner
  60.           Expires September 1997         Sharp Laboratories of America
  61.                                                             March 1997
  62.  
  63.  
  64.  
  65.  
  66.           1. Overview                                                     4
  67.  
  68.  
  69.           2.  HTTP Mapping Strategy                                       5
  70.  
  71.  
  72.           3. PRINT Operation                                              7
  73.  
  74.  
  75.           3.1 Create-JOB                                                  9
  76.  
  77.  
  78.           3.2 Send-Job                                                    9
  79.  
  80.  
  81.           4. QUERY                                                       10
  82.  
  83.  
  84.           5. Cancel                                                      11
  85.  
  86.  
  87.           6. Interoperability with Existing (IPP-unaware) Browsers       11
  88.  
  89.  
  90.           6.1 IPP PRINT Operation                                        11
  91.  
  92.  
  93.           6.2 Query                                                      13
  94.  
  95.  
  96.           6.3 Cancel                                                     13
  97.  
  98.  
  99.           7. Practical Considerations                                    14
  100.  
  101.  
  102.           7.1 HTTP 1.1 Persistent Connections                            14
  103.  
  104.  
  105.           7.2 Cache Control Directives                                   15
  106.  
  107.  
  108.           7.3 Protocol Error Handling                                    16
  109.  
  110.  
  111.           8. Security Considerations                                     16
  112.  
  113.  
  114.           9. Internationalization/Localization Issues                    17
  115.  
  116.  
  117.  
  118.  
  119.  
  120.           draft-turner-ipp-trans-develop-00
  121.                                        2
  122.  
  123.  
  124.           draft-turner-ipp-trans-develop-00               Randy Turner
  125.           Expires September 1997         Sharp Laboratories of America
  126.                                                             March 1997
  127.  
  128.  
  129.           10. References                                                 19
  130.  
  131.  
  132.           11. Contacts                                                   19
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.           draft-turner-ipp-trans-develop-00
  178.                                        3
  179.  
  180.  
  181.           draft-turner-ipp-trans-develop-00               Randy Turner
  182.           Expires September 1997         Sharp Laboratories of America
  183.                                                             March 1997
  184.  
  185.  
  186.  
  187.  
  188.           1. Overview
  189.  
  190.  
  191.           The actual implementation of HTTP 1.1 as a transport can come in
  192.           several flavors, depending upon the disposition of the clients
  193.           and servers. The following client-server implementations for IPP-
  194.           over-HTTP are possible:
  195.  
  196.  
  197.               Client               IPP Server
  198.  
  199.           1) HTTP 1.1 Browser      HTTP 1.1 Server w/CGI-based IPP
  200.           2) HTTP IPP Client       HTTP 1.1 Server w/CGI-based IPP
  201.           3) HTTP 1.1 Browser      HTTP-capable IPP Server
  202.           4) HTTP IPP Client       HTTP-capable IPP Server
  203.  
  204.           Other combinations of the above scenarios can also be constructed
  205.           but the fundamental direct client/server relationships are
  206.           included in the above scenarios. This document does not directly
  207.           deal with the fact that in HTTP topologies, intermediaries such
  208.           as proxies and gateways may exist.
  209.  
  210.           The "HTTP IPP Client" in the above list of scenarios is a
  211.           dedicated IPP client entity (true-client) that implements IPP-
  212.           over-HTTP. This is in contrast to a HTTP browser which is
  213.           essentially unaware that it is utilizing IPP services over HTTP.
  214.           Use of a browser as an IPP client is discussed later in this
  215.           document. An "HTTP-capable IPP server" is an instance of an IPP
  216.           service that happens to support IPP-over-HTTP directly, for
  217.           example using a dedicated TCP port number. This is in contrast to
  218.           an "HTTP 1.1 Server w/CGI-based IPP" where the actual IPP service
  219.           is performed by CGI-based scripts or other executable content and
  220.           the bulk of the HTTP protocol is handled by a generic HTTP
  221.           server.
  222.  
  223.           Slight variations exist in the type of support that clients and
  224.           servers would offer within the context of IPP over HTTP. In the
  225.           following sections, the base IPP-over-HTTP specification will be
  226.           presented, with these implementation variants noted where
  227.           appropriate. When referenced in the following text, the above
  228.           scenarios will be highlighted by using the terms "scenario (1)",
  229.           "scenario (2)", etc.
  230.  
  231.  
  232.  
  233.  
  234.  
  235.           draft-turner-ipp-trans-develop-00
  236.                                        4
  237.  
  238.  
  239.           draft-turner-ipp-trans-develop-00               Randy Turner
  240.           Expires September 1997         Sharp Laboratories of America
  241.                                                             March 1997
  242.  
  243.  
  244.           A true-client is an IPP-aware entity that is fully compliant with
  245.           the IPP protocol, as specified by this document.
  246.  
  247.           It is possible that future releases of web browsers will have
  248.           true IPP client capability but there will always be the legacy
  249.           case where support for some level of interoperability between
  250.           non-IPP-aware browsers and IPP servers is required.
  251.  
  252.           This protocol contains "hooks" to allow IPP servers to return
  253.           status and query information about IPP services and IPP print
  254.           jobs in human readable form. These "hooks" do not require special
  255.           extensions or other non-HTTP compliant capabilities. Within this
  256.           document, IPP responses are said to be processed by "external"
  257.           means or by IPP automata (such as true IPP clients). An external
  258.           IPP entity could be a end-user (human) consumer, or a custom
  259.           extension or "plug-in" to a web browser.
  260.  
  261.           This document also makes use of object references similar to the
  262.           IPP Model document. "PRINTER" objects are referenced by clients
  263.           using a specific URL identifier. "JOB" objects are also
  264.           referenced by a specific URL identifier.
  265.  
  266.           Also, PRINTER objects come in two forms: there is the "root" URL
  267.           for the IPP Printing Service which could reference a logical or
  268.           physical printing device, and also a specific "Job-Data" URL
  269.           PRINTER object. Again, in a very simple print system topology,
  270.           these two object identification URL strings could point to the
  271.           same object. The "root" URL for a printing service is the URL
  272.           string that would be advertised by a directory service or by
  273.           other means. The "Job-Data" PRINTER object URL is the PRINTER
  274.           object that is assigned to process a particular instance of a
  275.           print JOB object, as explained later in this document.
  276.  
  277.  
  278.           2.  HTTP Mapping Strategy
  279.  
  280.  
  281.           This document proposes using HTTP POST operations for mapping IPP
  282.           abstract operations. Using the HTTP POST method attempts to
  283.           emulate a traditional request/response protocol that might be
  284.           used if IPP were mapped directly onto TCP with a dedicated port
  285.           number.
  286.  
  287.           In the traditional case, a packet-oriented client/server protocol
  288.           would utilize the following header fields:
  289.  
  290.  
  291.  
  292.  
  293.           draft-turner-ipp-trans-develop-00
  294.                                        5
  295.  
  296.  
  297.           draft-turner-ipp-trans-develop-00               Randy Turner
  298.           Expires September 1997         Sharp Laboratories of America
  299.                                                             March 1997
  300.  
  301.  
  302.  
  303.                     Packet-Protocol
  304.                     Packet-Length
  305.                     Protocol-version
  306.                     Protocol-operation
  307.                     .
  308.                     . Protocol-operation specific data
  309.                     .
  310.  
  311.           It is likely that IPP will be mapped onto other transport
  312.           protocols in the future, and a traditional protocol mapping
  313.           approach has been used to "translate" the traditional protocol-
  314.           encapsulation techniques into HTTP capabilities.
  315.  
  316.           The following mapping is used to translate these traditional
  317.           packet header fields into the HTTP framework:
  318.  
  319.           Packet-Protocol :
  320.  
  321.           Since we are re-using HTTP to carry another type of application
  322.           protocol, we need a way to key HTTP messages with a particular
  323.           protocol tag. In this document, the HTTP Entity-Header "Content-
  324.           Type" is keyed with the value "application/IPP" to denote the
  325.           specific module that should handle this type of message.
  326.  
  327.           Packet-Length :
  328.  
  329.           The Packet-Length field is directly mapped to the HTTP entity
  330.           header "Content-Length". The Content-Length field specifies how
  331.           many bytes are contained within the entity body.
  332.  
  333.           Protocol-Version :
  334.  
  335.           Protocol-Operation :
  336.  
  337.           The protocol operation field is the first IPP application-
  338.           specific field encoded into a packet - this is due to the fact
  339.           that the syntax and semantics of the remainder of the packet
  340.           contents varies depending upon the operation field.
  341.  
  342.  
  343.           Once this protocol header is decoded, the actual packet (or
  344.           entity body in HTTP) is the same for all protocol mappings. The
  345.           "encoding" of the packet or entity body might be different, but
  346.           the ordering of fields, data-types used, and semantic content are
  347.  
  348.  
  349.  
  350.           draft-turner-ipp-trans-develop-00
  351.                                        6
  352.  
  353.  
  354.           draft-turner-ipp-trans-develop-00               Randy Turner
  355.           Expires September 1997         Sharp Laboratories of America
  356.                                                             March 1997
  357.  
  358.  
  359.           the same for all protocol mappings. The tighter we keep the
  360.           protocol mapping model, the easier it will be to design gateway
  361.           implementations (from protocol mapping to another protocol
  362.           mapping) in the future. This is the primary reason for discussing
  363.           protocol mapping methods in this document. For the purposes of
  364.           this document, the encoding of the actual application-specific
  365.           portion of the packet (non-header fields) is specified by the
  366.           HTTP entity-header "Content-Encoding".
  367.  
  368.           In the following sections each of the three abstract IPP
  369.           operations PRINT, QUERY, and CANCEL are discussed in detail.
  370.           Subsequent versions of this specification will describe the
  371.           requests and responses in more detail. This initial specification
  372.           seeks only to describe fundamental ideas related to using HTTP
  373.           1.1 as a transport for IPP.
  374.  
  375.  
  376.  
  377.  
  378.           3. PRINT Operation
  379.  
  380.  
  381.           In this mapping document, the IPP model PRINT operation is broken
  382.           into three separate underlying HTTP operations. As previously
  383.           mentioned, all IPP operations over HTTP are implemented via the
  384.           HTTP "POST" operation. The three independent operations that make
  385.           up the abstract PRINT operation are
  386.  
  387.                     Create-Job
  388.                     Send-Job
  389.  
  390.           The "Create-Job" POST operation requests that the target IPP
  391.           server create an instance of a print job and return job object
  392.           identification information back to the client. There are three
  393.           job identification items that are returned, each formatted as a
  394.           standard URL string:
  395.  
  396.           1. J
  397.               ob-Data-URL
  398.           2.  
  399.              Job-Status-URL
  400.           3.  
  401.              Job-Modify-URL
  402.  
  403.           The rationale for returning three separate URLs for subsequent
  404.           access to a job are two-fold: in the first case, having three
  405.           separate targets for data, status, and modification for a job
  406.           allows the protocol to scale to widely different printing system
  407.  
  408.  
  409.  
  410.  
  411.           draft-turner-ipp-trans-develop-00
  412.                                        7
  413.  
  414.  
  415.           draft-turner-ipp-trans-develop-00               Randy Turner
  416.           Expires September 1997         Sharp Laboratories of America
  417.                                                             March 1997
  418.  
  419.  
  420.           topologies, from simple peer-to-peer printing all the way to
  421.           complex logical/physical printer spooling systems as described by
  422.           the ISO Document Print Application (DPA) standard. For simple
  423.           peer-to-peer printing systems wherein a client is communicating
  424.           directly with the physical printing device, the IPP server in the
  425.           printing device could potentially return all three URLs (data,
  426.           status, and modify) with the
  427.           same value. For more complicated systems with intermediate
  428.           spooling servers and fully distributed logical and physical
  429.           printing configurations, there could potentially be three
  430.           different IPP entities (not necessarily hosts) that are
  431.           responsible for each type of information.
  432.  
  433.           The second reason for returning three separate URL strings for
  434.           each type of information concerns the security aspects
  435.           surrounding each type of information access. For each type of
  436.           access (data, status, and modification), there may be different
  437.           security policies in force for a particular site. Each URL may be
  438.           coded differently to indicate a particular level of security
  439.           attached to each type of print job information access. Again,
  440.           this is an elaborate printing environment that would support
  441.           these types of policies, but as stated previously, the URL
  442.           strings could all be the same value to scale to very simple peer-
  443.           to-peer topologies.
  444.  
  445.           The "Job-Data-URL" string identifies a target for subsequent
  446.           delivery of actual print job data (i.e., raster data or page
  447.           description language streams).
  448.  
  449.           The "Job-Status-URL" string identifies a target whereby
  450.           subsequent requests for job status for this job should be
  451.           forwarded (See QUERY/JOB-ATTRIBUTES).
  452.  
  453.           The "Job-Modify-URL" string identifies a target whereby requests
  454.           to modify the disposition of a job should be forwarded. For
  455.           version 1.0 of this protocol, only the CANCEL sub-operation is
  456.           supported via this mechanism. However, future additions to job
  457.           modification capabilities over IPP would be instrumented through
  458.           this URL target.
  459.  
  460.  
  461.           3.1 Create-JOB
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.           draft-turner-ipp-trans-develop-00
  469.                                        8
  470.  
  471.  
  472.           draft-turner-ipp-trans-develop-00               Randy Turner
  473.           Expires September 1997         Sharp Laboratories of America
  474.                                                             March 1997
  475.  
  476.  
  477.           The POST operation for "Create-Job" contains an "application/ipp"
  478.           entity body that contains any production attributes that should
  479.           be applied to this job instance.
  480.  
  481.           Details of the exact format of this, and all, entity bodies
  482.           associated with the "application/ipp" type will be discussed in
  483.           future versions of this document.
  484.  
  485.           The response to a root IPP URL POST operation will also return a
  486.           message body with an entity type of "application/ipp". Contained
  487.           within this entity-body will be the job identifiers formatted as
  488.           the "Job-Data" URL, the "Job-Status" URL, and "Job-Modify" URL
  489.           strings as discussed earlier in the previous section.
  490.  
  491.           To elaborate on the actual syntax of these URL strings, it should
  492.           be noted that each one of these URL strings will be encoded with
  493.           some IPP server-assigned job-identification string which is a
  494.           unique identifier within the administrative domain of the IPP
  495.           print service. Practically, this job-identification should be
  496.           encoded as a CGI-style parameter within the URL-formatted string.
  497.  
  498.  
  499.           3.2 Send-Job
  500.  
  501.  
  502.           A single POST operation to the Job-Data-URL will deliver the
  503.           print job data to the IPP service. It is recommended that the
  504.           content-type for POSTing of print job data be "application/octet-
  505.           stream", although if the particular format of the job data is
  506.           known, then this information could be passed to the IPP service
  507.           via a registered MIME content-type specific to the application
  508.           data stream (i.e., "application/postscript"). Each POST operation
  509.           will contain an IPP-specific message body with appropriate HTTP
  510.           entity-headers for Content-Length and Content-Encoding. In some
  511.           cases, the IPP client will know in advance the total number of
  512.           bytes that are contained within a particular job data stream. If
  513.           this is known, then the length of the entity body is specified by
  514.           the "Content-Length" header. If for some reason, the IPP client
  515.           does not know how many total bytes of job stream data will be
  516.           sent, then a MIME "chunked" encoding should be used, with each
  517.           segment being tagged with the particular "Content-Length" for
  518.           that segment. IPP servers should be prepared to handle "Content-
  519.           Transfer-Encoding" headers for print job data as well. Some level
  520.           of Content-Transfer-Encoding may be required to transfer
  521.           particular types of print job raster data or page description
  522.  
  523.  
  524.  
  525.  
  526.           draft-turner-ipp-trans-develop-00
  527.                                        9
  528.  
  529.  
  530.           draft-turner-ipp-trans-develop-00               Randy Turner
  531.           Expires September 1997         Sharp Laboratories of America
  532.                                                             March 1997
  533.  
  534.  
  535.           language (PDL) streams. Future versions of this specification
  536.           will include a base set of Content-Transfer-Encoding types that
  537.           should minimally be supported by IPP clients and servers.
  538.  
  539.  
  540.           4. QUERY
  541.  
  542.  
  543.           QUERY operations allow a client to inquire as to the operational
  544.           attributes or status of a particular IPP object (printer object
  545.           or job object). As previously discussed, there are four different
  546.           URL objects that are referenced within the IPP: the "root" URL
  547.           for the Printing Service, and the three URL objects returned from
  548.           a successful "Create-Job" operation: Job-Data-URL, Job-Status-
  549.           URL, and Job-Cancel-URL. Different results are obtained depending
  550.           upon which URL object is queried.
  551.  
  552.           A QUERY directed towards the "root" IPP service URL will return
  553.           operational attributes associated with the print service, as well
  554.           as a list of currently active and pending print jobs within the
  555.           print service. A QUERY directed towards the "Job-Status" URL
  556.           object returns the current state of the print job referenced by
  557.           the "Job-Status" URL.
  558.  
  559.           All QUERY requests are submitted via the HTTP POST operation,
  560.           with requests and responses encoded within an "application/ipp"
  561.           entity body.
  562.  
  563.  
  564.           5. Cancel
  565.  
  566.  
  567.           Previously submitted print jobs can be cancelled via a POST
  568.           operation to the "Job-Modify-URL", with the CANCEL request
  569.           modifier specified in an "application/ipp" entity body. As stated
  570.           previously, the initial version 1.0 of IPP will only support the
  571.           CANCEL sub-operation. However, future job modification requests
  572.           will also be posted to this URL as well.
  573.  
  574.           It is anticipated that initial requirements for robust
  575.           authentication mechanisms will be associated with this particular
  576.           "Job-Modify" URL specification. Ordinarily, an IPP service would
  577.           require client authentication to verify that the client
  578.           submitting the job-modify request is the same client that
  579.           originally submitted the print job. This additional object
  580.  
  581.  
  582.  
  583.  
  584.           draft-turner-ipp-trans-develop-00
  585.                                        10
  586.  
  587.  
  588.           draft-turner-ipp-trans-develop-00               Randy Turner
  589.           Expires September 1997         Sharp Laboratories of America
  590.                                                             March 1997
  591.  
  592.  
  593.           security requirement could be communicated to clients via the URL
  594.           protocol field (i.e., HTTPS or HTTP).
  595.  
  596.  
  597.           6. Interoperability with Existing (IPP-unaware) Browsers
  598.  
  599.  
  600.           The following paragraphs discuss how the IPP operations PRINT,
  601.           QUERY, and CANCEL are supported through existing browser
  602.           implementations. This discussion assumes that the root URL for an
  603.           IPP printing service has already been obtained and is displayed
  604.           as a hyperlink on an HTTP browser display.
  605.  
  606.  
  607.           6.1 IPP PRINT Operation
  608.  
  609.  
  610.           Typically, the user will obtain a URL link to a root IPP service
  611.           through a directory service or "bookmark" database. The user will
  612.           then click on the link causing an HTTP GET operation to be
  613.           performed. Unlike the core IPP protocol which uses POST methods
  614.           for all requests into the IPP service, a GET request into an IPP
  615.           server is a hint that the IPP client is really a browser, and not
  616.           a true IPP-aware client entity. If an IPP service receives a GET
  617.           request on its root URL, the service will return a formatted HTML
  618.           response, as opposed to a "application/ipp" entity-type.
  619.  
  620.           An HTTP GET operation to a IPP root URL will return an HTML-
  621.           formatted response that displays, in human-readable form, the
  622.           operational attributes of the IPP service, as well as an HTML
  623.           form capable of enabling the end-user to print one or more files.
  624.           Each IPP server implementation may return a different "look-and-
  625.           feel" associated with the HTML interface, but the attribute names
  626.           and semantics MUST remain consistent for all implementations.
  627.  
  628.           As a part of the response to this client GET request, IPP server
  629.           implementations SHOULD use the "Form-Based File Upload" technique
  630.           described in RFC 1867. Using this capability, users can send one
  631.           or more arbitrary files for printing to an IPP service. More
  632.           importantly, RFC 1867 form-based file upload includes the
  633.           capability for sending the form data, and the file contents, to
  634.           an alternate URL destination for printing. This feature is
  635.           required since the actual form-action method (POST) will not be
  636.           encoded with IPP-specific protocol (entity-bodies), and could not
  637.           be sent to a standard IPP-compliant service URL.
  638.  
  639.  
  640.  
  641.  
  642.           draft-turner-ipp-trans-develop-00
  643.                                        11
  644.  
  645.  
  646.           draft-turner-ipp-trans-develop-00               Randy Turner
  647.           Expires September 1997         Sharp Laboratories of America
  648.                                                             March 1997
  649.  
  650.  
  651.           The destination URL for the form-based file upload action is a
  652.           dedicated target service that has been readied to receive the job
  653.           stream being delivered via the RFC-1867 method. This would
  654.           probably be a different URL specification than the root URL, as
  655.           previously mentioned.
  656.  
  657.           The response to submitting the file via the form-based file
  658.           upload method would be similar to the true IPP client "Job-
  659.           Create" response. The IPP service would return the same three
  660.           job-identifier URL strings as links, either as typical
  661.           highlighted links, or as possibly part of another HTML form with
  662.           image-mapped links, or basically whatever format the server
  663.           chooses.
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.           6.2 Query
  672.  
  673.  
  674.           Existing browsers are able to query both PRINTER objects as well
  675.           as JOB objects. The same GET operation that is used to obtain the
  676.           PRINT operation form (outlined in section 5.1) could also contain
  677.           information in an HTML page (or pages) that contains informative
  678.           attributes regarding the print service, which satisfies the QUERY
  679.           PRINT object requirement. Essentially, a particular IPP
  680.           implementation is free to design the root print service GET
  681.           response to be whatever that particular implementation of IPP
  682.           requires. On this same page could be another link, or GUI
  683.           control, that displays the active jobs pending for the print
  684.           service.
  685.  
  686.           As discussed in section 5.1, the response to a print job
  687.           submission (via the form-based file upload mechanism) would be
  688.           the IPP-Assigned-Printer, STATUS, and CANCEL URL identifiers that
  689.           are associated with the newly created job. To obtain status on
  690.           this job submission, the user could just click on the STATUS
  691.           link, which would cause an HTTP GET operation to be performed.
  692.           The response to this GET operation could be a brief or detailed
  693.           status on the job.
  694.  
  695.           6.3 Cancel
  696.  
  697.  
  698.  
  699.  
  700.           draft-turner-ipp-trans-develop-00
  701.                                        12
  702.  
  703.  
  704.           draft-turner-ipp-trans-develop-00               Randy Turner
  705.           Expires September 1997         Sharp Laboratories of America
  706.                                                             March 1997
  707.  
  708.  
  709.           Similar to the QUERY on the job status URL object, the browser
  710.           end-user would employ the same technique to CANCEL a particular
  711.           job. The HTML page that resulted from the job submission also
  712.           contains the CANCEL hyperlink. The user could just click on this
  713.           link which would cause an HTTP GET operation on the CANCEL URL.
  714.           The response to this GET request would be an HTML page indicating
  715.           success or failure. Optionally, if the CANCEL URL specifies some
  716.           level of security (i.e., via a link of the form HTTPS://), then
  717.           the response would be some type of authentication challenge that
  718.           requires the user to authenticate him or herself prior to
  719.           continuing the CANCEL operation. In most implementations, any
  720.           type of job modification operation would require that the client
  721.           authentication match the authenticated client that originally
  722.           submitted the job.
  723.  
  724.           From the IPP server's perspective, the key to determining whether
  725.           or not a specific request is from a browser, or a true IPP
  726.           client, is through the type of HTTP request. True IPP clients
  727.           accomplish their requests using the HTTP POST method on URL
  728.           objects, while traditional browsers would utilize the HTTP GET
  729.           method on URL objects.
  730.  
  731.  
  732.           7. Practical Considerations
  733.  
  734.  
  735.  
  736.           7.1 HTTP 1.1 Persistent Connections
  737.  
  738.  
  739.           Most HTTP 1.1 server implementations will choose to support
  740.           persistent connections by default (see RFC 2068 for a discussion
  741.           and rationale for use of persistent connections). In the case of
  742.           IPP-over-HTTP, support for persistent connections is a key
  743.           requirement for adequate protocol performance. This is especially
  744.           important for IPP clients that choose to deliver bulk job data in
  745.           two or more POST operations. In IPP client-server scenarios
  746.           (1),(2), and (3), IPP servers may not have the ability to sustain
  747.           persistent connections, since either the client, or the server,
  748.           is not IPP aware, and there is not IPP-specific automata that can
  749.           maintain the persistent connection between client and server. In
  750.           scenarios (1) and (2), the generic HTTP server controls the
  751.           opening and closing of actual network connections, not the CGI-
  752.           based IPP "handler". And in the case of a browser acting as an
  753.           IPP client, the IPP server can do nothing to stop a browser from
  754.           closing the connection once a response to an operation is
  755.  
  756.  
  757.  
  758.           draft-turner-ipp-trans-develop-00
  759.                                        13
  760.  
  761.  
  762.           draft-turner-ipp-trans-develop-00               Randy Turner
  763.           Expires September 1997         Sharp Laboratories of America
  764.                                                             March 1997
  765.  
  766.  
  767.           received; this is especially true if a legacy HTTP 1.0 browser is
  768.           used.
  769.  
  770.           Also, in the scenarios above that utilize CGI-based IPP server
  771.           solutions, all of the same semantics would apply to any external
  772.           IPP processing entity (such as Microsoft ISAPI-based
  773.           implementations)
  774.  
  775.  
  776.           7.2 Cache Control Directives
  777.  
  778.  
  779.           It is recommended that all IPP-over-HTTP requests and responses
  780.           be tagged with a HTTP "Pragma" header of "no-cache". This tag
  781.           should also be mirrored into the HTTP 1.1 Cache-Control
  782.           directive. Operation of the IPP-over-HTTP protocol is undefined
  783.           in the presence of caching of requests or responses, and further
  784.           analysis of this caching should be done before allowing this
  785.           capability into the protocol. This analysis would probably
  786.           incomplete until sufficient prototypes have been deployed and
  787.           operation experience obtained.
  788.  
  789.           In RFC 2068 (HTTP 1.1), there is a "no-transform" directive
  790.           defined. The following description of the "no-transform"
  791.           directive and its rationale is taken directly from RFC 2068:
  792.  
  793.           From RFC 2068:
  794.           [ Implementers of intermediate caches (proxies) have found it
  795.           useful to convert the media type of certain entity bodies. A
  796.           proxy might, for example, convert between image formats in order
  797.           to save cache space or to reduce the amount of traffic on a slow
  798.           link. HTTP has to date been silent on these transformations.
  799.  
  800.           Serious operational problems have already occurred, however, when
  801.           these transformations have been applied to entity bodies intended
  802.           for certain kinds of applications. For example, applications for
  803.           medical imaging, scientific data analysis and those using end-to-
  804.           end authentication, all depend on receiving an entity body that
  805.           is bit for bit identical to the original entity-body.
  806.  
  807.           Therefore, if a response includes the no-transform directive, an
  808.           intermediate cache or proxy MUST NOT change those headers that
  809.           are listed in section 13.5.2 as being subject to the no-transform
  810.           directive.  This implies that the cache or proxy must not change
  811.  
  812.  
  813.  
  814.  
  815.  
  816.           draft-turner-ipp-trans-develop-00
  817.                                        14
  818.  
  819.  
  820.           draft-turner-ipp-trans-develop-00               Randy Turner
  821.           Expires September 1997         Sharp Laboratories of America
  822.                                                             March 1997
  823.  
  824.  
  825.           any aspect of the entity-body that is specified by these headers.
  826.           ]
  827.  
  828.           Because of the risk imposed to varying kinds of print job data
  829.           streams and content-encodings that might be used to implement IPP
  830.           over HTTP, it is strongly recommended that usage of the "no-
  831.           transform" directive for requests and responses be employed for
  832.           all implementations of IPP clients and servers. The exception to
  833.           this rule is in the case of IPP-over-HTTP scenarios wherein
  834.           either a generic WEB server or generic browsers are used. In
  835.           these instances, the IPP service layer or component may not be
  836.           able to force the usage of the "no-transform" directive.
  837.  
  838.  
  839.           7.3 Protocol Error Handling
  840.  
  841.  
  842.           IPP client implementations will have to handle errors on two
  843.           different levels, depending upon the operational scenario(s) (1
  844.           through 4 outlined above) that the print service supports. For
  845.           browser-based IPP clients, the end-user is responsible for
  846.           "handling" errors returned via HTTP operations. These errors will
  847.           be returned in HTML format by the IPP service, or automatically
  848.           generated HTML format by the HTTP browser in the event of a
  849.           generic HTTP error.
  850.  
  851.           True IPP client implementations will have to handle both HTTP
  852.           protocol errors, as well as IPP-specific protocol errors embedded
  853.           in IPP response messages.
  854.  
  855.           8. Security Considerations
  856.  
  857.  
  858.           The same types of security considerations affecting the transport
  859.           of IPP over HTTP apply for the base HTTP 1.1 specification as
  860.           well. The IPP Model document and subsequent protocol mapping
  861.           documents contain no explicit support for security operations. It
  862.           is assumed that an underlying (at some protocol layer below IPP)
  863.           transport layer mechanism will be responsible for the security.
  864.           The IPP working group has acknowledged the requirement for a very
  865.           robust authentication mechanism, and has also considered privacy
  866.           as an option as well. It is anticipated that both the
  867.           authentication requirement and optional privacy capability will
  868.           be handled by underlying protocols such as a Secure Sockets Layer
  869.           (SSL) v3 implementation. In the case of IPP Scenario(1) mentioned
  870.  
  871.  
  872.  
  873.  
  874.           draft-turner-ipp-trans-develop-00
  875.                                        15
  876.  
  877.  
  878.           draft-turner-ipp-trans-develop-00               Randy Turner
  879.           Expires September 1997         Sharp Laboratories of America
  880.                                                             March 1997
  881.  
  882.  
  883.           previously in this document, it is assumed that SSL v3.0 will be
  884.           available.
  885.  
  886.           Multiple layers of security are supported by this protocol
  887.           mapping document, as specified by the PRINT operation response
  888.           methodology. IPP Server administrators may choose to advertise
  889.           IPP services (via the IPP "root" URL) as secure (HTTPS://) or
  890.           non-secure (HTTP://). It would also be possible for IPP servers
  891.           implementing IPP-over-HTTP to utilize basic HTTP authentication
  892.           (as specified in RFC 2068). HTTP Digest Authentication (RFC 2069)
  893.           could also be utilized to provide a higher level of secure
  894.           authentication; one that doesn't require passwords to be sent as
  895.           clear text. In some printing environments, however, two-way
  896.           authentication may be required wherein the IPP client and IPP
  897.           server authenticate each other. In this situation, IPP
  898.           implementations would have to rely on external means to achieve
  899.           the desired security requirements (external in this case meaning
  900.           SSL v3 or IPSEC or other means).
  901.  
  902.           One possible issue with the use of SSLv3 is its current status
  903.           within the IETF standards-track, and whether or not this would
  904.           cause problems with its acceptance and the possibility of wide-
  905.           spread deployment. One of the key criteria for the establishment
  906.           of a security solution for IPP is wide-spread availability and
  907.           adoption of a security solution.
  908.  
  909.  
  910.           9. Internationalization/Localization Issues
  911.  
  912.  
  913.           Localization of protocol information destined for human
  914.           consumption (names, descriptions, etc.) can either be performed
  915.           by explicit use of IPP-specific mechanisms, or, HTTP Accept-
  916.           Headers can be used by IPP clients to indicate to IPP servers the
  917.           type of language and/or character set that the client entity
  918.           wants to see for the associated response.
  919.  
  920.           Sending Accept-Headers with every request might seem somewhat
  921.           protocol inefficient with regards to this "extra information"
  922.           that must be sent for each request, but in complex printing
  923.           environments, depending upon the type of request, requests might
  924.           be sent to different server entities, so there is either initial
  925.           setup/negotiation overhead to deal with for each and every
  926.           server, or the client can only send Accept-Headers to service
  927.           entities for which client requests are actually required. Also,
  928.  
  929.  
  930.  
  931.  
  932.           draft-turner-ipp-trans-develop-00
  933.                                        16
  934.  
  935.  
  936.           draft-turner-ipp-trans-develop-00               Randy Turner
  937.           Expires September 1997         Sharp Laboratories of America
  938.                                                             March 1997
  939.  
  940.  
  941.           it might prove advantageous to keep the protocol as stateless as
  942.           possible, due to the fact that future versions will deal with
  943.           checkpoint/restart of print jobs, and other types of "crash"
  944.           recovery. The less state we have to save and restore the better.
  945.  
  946.           Use of IPP-specific localization support within IPP-over-HTTP
  947.           entity bodies might prove to be a more straightforward approach
  948.           in that some protocol design re-use could be employed when other
  949.           IPP transport mapping documents are generated. Also, along this
  950.           same reasoning, gateways between different IPP/Transport
  951.           combinations would be more easily conceptualized and understood.
  952.  
  953.           This document does not specifically call out either mechanism due
  954.           to the fact that no prototyping experience has been gained using
  955.           either method. A later and more detailed version of this document
  956.           will elaborate on a decision from the IPP working group regarding
  957.           localization for IPP-over-HTTP and include rationale for this
  958.           decision.
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.           draft-turner-ipp-trans-develop-00
  990.                                        17
  991.  
  992.  
  993.           draft-turner-ipp-trans-develop-00               Randy Turner
  994.           Expires September 1997         Sharp Laboratories of America
  995.                                                             March 1997
  996.  
  997.  
  998.  
  999.  
  1000.           10. References
  1001.  
  1002.  
  1003.           [1] deBry R., Hastings T., Herriot B., Isaacson S., "Internet
  1004.           Printing Protocol/1.0 Model and Semantics", IBM, Xerox, Sun,
  1005.           Novell, March 1997
  1006.  
  1007.           [RFC - 2068] Fielding R., Gettys J., Mogul J., Frystyk H.,
  1008.           Berners-Lee T., "Hypertext Transfer Protocol - HTTP 1.1", UC-
  1009.           Irvine, DEC, MIT/LCS, January 1997
  1010.  
  1011.           [RFC - 1867] Nebel E., Masinter L., "Form-based File Upload in
  1012.           HTML", Xerox Corporation, November 1995
  1013.  
  1014.           [RFC - 2069] Frank J., Hallam-Baker P., Hostetler J., Leach P.,
  1015.           Luotonen A., Sink E., Stewart L., "An Extension to HTTP - Digest
  1016.           Access Authentication", Northwestern Univ, CERN, Spyglass,
  1017.           Microsoft, Netscape, Open Market, January 1997
  1018.  
  1019.  
  1020.           11. Contacts
  1021.  
  1022.  
  1023.           Randy Turner
  1024.           Member of Technical Staff
  1025.           Sharp Laboratories of America
  1026.           5750 NW Pacific Rim Blvd
  1027.           Camas, WA 98607
  1028.           rturner@sharplabs.com
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.           draft-turner-ipp-trans-develop-00
  1048.                                        18
  1049.  
  1050.