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