INTERNET-DRAFT P. Moore, B Jahromi Microsoft Corporation S. Butler Hewlett-Packard Company Version 1.0 May 7, 1997 Simple Web printing (SWP/1.0) 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-abstracts.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). 1 Introduction 1 1.1 Terminology 1 2 Job submission 1 2.1 Obtaining the print URL 1 2.2 The data POST 1 2.3 HTTP Headers used 1 2.3.1 Content-type 1 2.3.2 Content-length 1 2.4 Empty POST 1 2.5 Print by reference 1 3 Server Responses 1 3.1 200 OK 1 3.2 400 Bad Request 1 3.3 403 Forbidden 1 3.4 413 Request entity too large 1 3.5 415 Unsupported media Type 1 4 Client Configuration 1 4.1 Deinstalling 1 5 Monitoring and management 1 6 Security 1 6.1 Server 1 6.1.1 Authentication 1 6.1.2 Access Control 1 6.1.3 Denial-of-service 1 6.2 User 1 6.2.1 Privacy 1 6.2.2 Authentication 1 6.2.3 Access Control 1 6.3 Expected Implementation. 1 7 HTTP Entity format 1 7.1 Header-length 1 7.2 Attribute-n 1 7.3 Print data 1 8 Attributes 1 8.1 Attribute Value syntax 1 8.1.1 Text 1 8.1.2 Octet String 1 8.1.3 Boolean 1 8.1.4 Integer 1 8.1.5 DateTime 1 8.1.6 Keywords 1 8.2 Attributes 1 8.2.1 Job-name 1 8.2.2 Job-originator 1 8.2.3 Document-format 1 8.2.4 Examples 1 9 Internationalization 1 9.1 Coding of the SWP header. 1 9.2 Encoding of the print data. 1 9.3 Service HTML pages. 1 10 Location of server providing SWP 1 11 Example of use 1 12 References 1 1 Introduction This document describes a Simple Web Printing solution (SWP). The purpose of SWP is to allow a user to submit, control and monitor print jobs whilst connected to a network via HTTP. This network may be the Internet, a corporate intranet or a mixture. The overall aims in the design of SWP are:- No changes to the HTTP protocols. Provide the UI via HTML. Not to compromise the security of the client nor the server. Simplicity of implementation and use. RATIONALE: The UI is presented via HTML so that as much of the existing client and server technology can be used. The alternative would have been to provide a management protocol that would have then necessitated a client-side UI. RATIONALE: HTTP is used as the transport for job submission because it is certain that a web user will have an HTTP connection. Although HTTP implies the availability of a general-purpose TCP/IP transport, many Internet proxy servers only support the proxying of HTTP. This project addresses many of the requirements identified by the IPP project of the IETF PWG [IPP]. That project is broader in scope, however. Where appropriate SWP has adopted the terminology, syntax and semantics of the IPP project. This has itself inherited much from the ISO 10175 DPA standard [ISO]. A large portion of SWP is left to the implementation of either the server or the configuration of a given implementation. This allows for the maximum flexibility in introducing this capability into rich web sites. It also allows for turnkey solutions to be developed. NOTE: HTTP/1.1 is required in order to implement SWP. The chunked data encoding of HTTP/1.1 is used to allow the transmission of data whose size is not known at the outset. In addition, persistent connections should be used whenever possible. 1.1 Terminology User: The person wishing to submit print data for printing via SWP. Client: The sum of the Operating System and applications executing on the user’s computer. Server: The sum of the operating system and applications executing on one or more computers that provide the service offered by SWP – i.e. where the printers are. Printer: The logical endpoint for data submitted via SWP. 2 Job submission The major part of SWP is the protocol that allows a client to submit a print job via HTTP. In keeping with its name this protocol is very simple:- The print job is submitted in a single HTTP POST. The entity part of the POST contains information about the job and the actual print data itself. RATIONALE: Several possibilities exist for submitting the print job to the server:- The model given above – the ‘atomic’ POST A ‘start-job’ POST including the job attributes followed by one POST containing the print data A ‘start-job’ POST including the job attributes followed by a set of print data POSTs. The job is terminated by an ‘end- job’ POST. The ‘atomic’ POST is chosen because this leads to the simplest and most robust server implementation. It is also in keeping with the spirit of statelessness of HTTP. NOTE: Only one print job may be submitted per POST request. How this protocol is used or implemented on the client is not specified by SWP. Several possibilities exist:- The browser could be modified to perform the POST directly A utility could be provided that performs the POST when given a file and a URL. A print subsystem component could be produced that pipes the data from a user application to the server via the POST. The last option is the one used by Microsoft and Hewlett Packard in their implementation. This in no way precludes others from providing one or more of the alternatives listed above. RATIONALE: The most common print operation performed by users is to print using an application’s print option. This is processed via the print provider / print driver / port monitor combination in Microsoft Windows 2.1 Obtaining the print URL The server must provide URLs for the printers that it wishes to expose via SWP. These URL can be supplied in one of two ways:- Displayed on an HTML page – the user may then copy this and use it wherever the printer URL is requested by the client side code. Automatically supplied as part of the client configuration – see later. This is the preferred option. The server should provide both. 2.2 The data POST The job attributes and the print data are sent as the entity part of a single HTTP POST using HTTP/1.1 chunked encoding if needed. The server must be able to accept both normal and chunked data. 2.3 HTTP Headers used SWP does not mandate the use of any HTTP headers but there are some headers which have meaning to, or are associated with, SWP. 2.3.1 Content-type The data POST must have a content-type of “application/swp”. This allows the server to verify that this is indeed a POST in SWP format. The charset parameter of the content-type must be used to indicate the character set used in the entity where needed. In the absence of a content-type header, or a content type header that does not specify a charset then the entity must be in ISO 8859-1 (‘latin1’) 2.3.2 Content-length The content-length may be given if known in advance or HTTP/1.1 chunked encoding may be used. 2.4 Empty POST The server must accept a POST with no print data and ignore it. This is used to allow the client to probe the server. In particular it allows the client to establish the authentication scheme(s) in use by the server. 2.5 Print by reference Print by reference means rather than the client supplying the data to be printed it supplies a pointer (a URL for example) to the file and the server then ‘pulls’ the data from that location. SWP print job submission does not support print by reference. RATIONALE: Print by reference can be implemented in other ways on the server without any interaction with the client, other than the submission of the request. For example one could have an ISAPI extension on the server that accepted the URL of a file to be printed. 3 Server Responses The normal HTTP/1.1 mechanisms are used to return results to the client from the server during a print POST operation. The following responses are explicitly used by SWP. Other responses may be used and have their normal meaning (‘401 Unauthorized’ for example) 3.1 200 OK This means that the print request has been accepted by the server. The server may include an entity containing the URI that the client may use to access the job in the server’s queue. This URI points to a resource that can be browsed directly by a web browser – i.e. this is a web page that the user can open directly. The encoding of this URI is specified in the entity headers. If absent then it is assumed to be ‘latin1’. The encoding used must be the same as that used in the original client request. 3.2 400 Bad Request The print POST request has incorrect syntax. In particular this response is used when the server cannot parse the SWP headers. 3.3 403 Forbidden The server has detected a syntactically correct POST for a resource that does not correspond to a printer. 3.4 413 Request entity too large The server may implement a scheme to limit the size of print jobs that it will accept. If a print request exceeds those limits then this response must be returned. 3.5 415 Unsupported media Type The SWP headers indicate that the print data is in a format not supported by the server. 4 Client Configuration In order for a user to make use of SWP facilities it is expected that their client system will need to be configured in some way. This may include installing of executable components, print drivers, utilities, etc. as well as configuration data. This configuration data may include information about the printer to be used and that is needed by the client (installed options, memory size for example). SWP does not specify what configuration needs to be done nor how it should be performed. This is specific to the client platform. The server should provide a mechanism for the client to be automatically configured, this is best done via URLs that point to client platform specific downloads. There is a potential threat to the client from these downloads given that these may include executable code to be loaded via the Web. These downloads should therefore make use of whatever client protection schemes may be available (Microsoft’s Authenticode for example). In the absence of these schemes it is hoped that the browser will at least alert the user to the potential threat. 4.1 Deinstalling The implementation should provide a mechanism for removing the configuration performed by the above steps. 5 Monitoring and management In this case monitoring and management means:- Allowing the user to follow the progress of their print job in the server Allowing the user to cancel their job, whilst queued and once delivery has started SWP includes no specific features for monitoring or management of the submitted print jobs, printers or queues. Instead the server implementation should provide HTML forms and pages that allow these actions to be performed. These pages will need to be dynamically generated by whatever tools the HTTP server supports, ISAPI, ASP, CGI, etc. The management pages should be easily discoverable; SWP provides no explicit support for these pages so it must be clear to the user where and how to reach them. The same page(s) that provided access to the client configuration and print submission should contain pointers to the relevant management pages. 6 Security The following issues should be addressed by any implementation. 6.1 Server The service provider (the organization running an instance of a particular SWP server implementation) will expect certain behaviors:- 6.1.1 Authentication In order to control access to its resources the provider needs to know the identity of the end-user. This can also provide a mechanism for billing the user. 6.1.2 Access Control To prevent malicious or accidental tampering with other print jobs the provider needs to be able to restrict access to only those jobs submitted by the current user. It should be possible to control access to devices depending on the identification of the user. For example color printers may only be available to certain users. 6.1.3 Denial-of-service The provider needs to have a mechanism for protecting itself from denial of service attacks. Example of this would be transmissions of large numbers of jobs, transmission of very large jobs, etc. 6.2 User The user will have certain expectations for security:- 6.2.1 Privacy The user should be able to request that the print job be transmitted in a secure manner. 6.2.2 Authentication The user needs to be sure that SWP server is really who it claims to be. 6.2.3 Access Control The user has the same expectation as the service provider that their jobs should be protected from other users whilst being processed. 6.3 Expected Implementation. SWP does not define any protocols for security. The implementation must use the standard HTTP authentication methods to establish the identity of the client. The server must accept at least anonymous access and basic authentication. Any other schemes are allowed, this depends on the schemes supported by the client and / or server. The normal HTTP authentication scheme negotiation must be used. 6.3.1 Anonymous use The anonymous case will probably be used for ‘Internet Fax’. In this case a company will announce on its web pages (or elsewhere) the URL of one or more public printers that anybody may send print jobs to. There is a challenge for the server implementation in this case: prevention of denial-of-service attacks. The protection schemes used by commercial fax machines could be used, keeping lists of recent callers and only allowing a limited number of connections within a certain period for example. The server may choose to not allow any management of the print jobs in this case given that there would be no control over which user could get at which jobs. Again, taking ‘real’ fax as the example, once a fax has been sent there is no way that it can be recalled. 6.3.2 Authenticated use Authentication will be used in the case where a service bureau is making its printers available to paying customers, or where a business users wants to submit print to private printers on their corporate intranet. Once the client identity is established then it is the responsibility of the server to maintain the association between the submitted job and the supplied user identification. It is also the responsibility of the server implementation to control access to the various server resources (printer, jobs, etc.) based on that user identification. User identification can be used to protect against denial of service attacks. Given that anonymous printing will not, in general, be available then it is unlikely that a known user would do this. The use of persistent HTTP connections is encouraged in order to avoid having the server challenge the user on every access to a resource. Optionally, privacy and mutual authentication should be provided by SSL3 where this is available. The server implementation can control and / or announce its support of SSL3 by changing the URLs published on the page(s) that grant access to the printers. Two URLs could be provided for each device, one using SSL the other not, this would allow for clients that do not support SSL. 7 HTTP Entity format The format of the entity sent in the job POST command is as follows:- Header-length Attribute-1 Attribute-2 Attribute-3 Attribute-n Print data This is transmitted as a contiguous sequence of octets. There is no alignment and no padding. 7.1 Header-length This is a count of the octets contained in the header. The header is defined as being the header-length itself (4) plus all of Attribute-1 through Attribute-n. It is a 32-bit binary value in little-endian form. The minimum value for header-length is therefore 4. Values less than 4 must result in a ‘400 Bad Request’ error. 7.2 Attribute-n Each Attribute is of the form:- Type Length value Where:- Type is a 32-bit binary value identifying the Attribute. Length is a 16-bit binary value identifying the length of the value that follows. The Type and Length fields are not included in this length. The length specifies the number of octets that the value occupies, not its logical length. For example a text string may have 5 characters in it but occupy 10 octets (and hence have a length of 10) if the entity is using UNICODE. Value is the value of the Attribute itself. The representation of the value being defined by the Attribute – see later RATIONALE: This Attribute type format is used because it is more compact, easier to parse and is unambiguous with regards to character set. This contrasts with using a text representation of the attribute name. RATIONALE: This value format is used because it makes it easy to parse and removes ambiguities that could arise from alternative schemes. For example a scheme using zero terminated strings may have problems with double-byte characters sets; a scheme based on CRLF termination is also ambiguous in those cases and in cases where there is a need to include CRLF in the value itself (a multi- line comment for example). There may be 0 or more attributes. No maximum limit is defined. 7.3 Print data This is the print data itself. Unless otherwise indicated in the document-format attribute it is assumed by the server to be in a format that can be sent directly to the printer. If the document-format is specified and is not directly compatible with the printer then the server must either convert the data into a form suitable for delivery or must raise an error (‘415 Unsupported Media Type’). The print data may be absent - see 2.4 Empty POST. 8 Attributes The attributes used in SWP follow the model of [IPP], which is itself based on ISO 10175 [ISO]. [IPP] does not (at the time of writing) define any protocol encoding for these attributes. SWP therefore defines an encoding for them:- Each attribute is identified by an unsigned 32-bit field. The value is derived by joining the [ISO] Object OID and the [ISO] Attribute OID. The respresentation of an attribute value depends on the type of the attribute. ‘SetOfX’ attributes (ones that have more than one value – example ‘finishing’) are represented by repeating the attribute triplet sequence for as many occurrences as required. The occurrences must be contiguous in the header. In the case where there is a default value then it must be the first value. 8.1 Attribute Value syntax This section refers to [IPP] 5.1 for the names of value syntaxes. It provides a mapping between the syntax specified there and that used in SWP. Many issues regarding the representation of attributes and their values are not discussed here (adornments, job vs. printer attributes, etc.). This is done because the attribute required for job submission are a simple subset of the complete IPP attributes and none of that sub-set need the more complex attributes. 8.1.1 Text All attribute values specified as being composed of a sequence of characters (‘Text’, ‘Name’, ‘fileName’ and ‘url’) are represented by characters in the character set specified in the Content-type HTTP header. The length field of the attribute triplet must contain the count of the number of octets used to store the text (i.e twice the number of characters for double-byte character sets) 8.1.2 Octet String A sequence of octets 8.1.3 Boolean Shall be represented by one octet. X’00’ meaning ‘false’ and X’FF’ meaning ‘true’. 8.1.4 Integer Shall be represented by a 32-bit signed integer in little-endian form. Includes IntegerSeconds, IntegerPoints, IntegerUnits. 8.1.5 DateTime Shall be encoded in RFC1123 format (e.g. ‘Mon, 28 Apr 1997 09:00:00). Note that this is in US-ASCII regardless of the encoding of the other SWP headers. 8.1.6 Keywords Shall be represented by a 16-bit unsigned integer. Each set of allowable value for a keyword shall be assigned its own enumeration. This is specified for each Attribute that takes a keyword value. Where [ISO] defines a set of values for an attribute (‘medium’ for example) then the OIDs specified are used. 8.2 Attributes All job and document attributes defined in [IPP] may be included in the SWP header. A server may ignore those attributes that it does not support. The attributes currently used by SWP are specified below. 8.2.1 Job-name SWP Type: X’00010001’ (Object OID:1, Attribute OID:1) Syntax: Text (1 to 4096 characters) Meaning: A client assigned name for the job. NFS for the server – treated as a comment 8.2.2 Job-originator SWP Type: X’00010002’ (Object OID:1, Attribute OID:2) Syntax: Name (1 to 255 characters) Meaning: A client assigned user name. NFS for the server – treated as a comment. NOTE: The user identification needed for access control must be obtained from the HTTP authentication negotiation, not from this attribute. 8.2.3 Document-format SWP Type: X’00010051’ (Object OID: 1, Attribute OID:81) Syntax: Keyword – values taken from [RFC 1759] Meaning: Specifies the type of data included; PCL, PostScript, etc. 8.2.4 Examples Note that the hexadecimal values are shown in the network octet order. Also note that there is no break between the header, the attributes and the print data, they are transmitted a continuous sequence of octets. The line breaks are included for readability only. A print job with no attributes given:- 04 00 00 00 A print job including name (“job”) and document-format of PCL:- 15 00 00 00 ; Header length = 21 01 00 01 00 03 00 j o b ; charset = latin1 (single-byte) 00 51 01 00 02 00 03 00 ; RFC 1759 : PCL = 3 9 Internationalization This topic covers several aspects. 9.1 Coding of the SWP header. The coding of the SWP header is specified by the Content-type charset parameter of the HTTP POST headers. The same character set is used for all the attributes in the header. 9.2 Encoding of the print data. The character set(s) used in the print data itself is not specified by SWP. 9.3 Service HTML pages. The HTML pages used to access and manage the SWP service should be in the native language of the client and should therefore also use the appropriate character set. The service implementation should use the normal HTTP/1.1 methods for discovering the client’s requirements (Accept-Charset, Accept- Language) and should honor them. 10 Location of server providing SWP SWP does not cover the location of service providers on the Web. The most likely scenario is that providers will announce this on their web pages and that standard web search engines will therefore be able to locate them. 11 Example of use A user wishes to submit a print job to a local print shop that is on the Web and offers SWP services. The user already has an account with the shop. The user is using Microsoft Windows and Microsoft Word The user accesses their home page Error! Bookmark not defined. On the home page there is a link to ‘online printing service’. The user clicks that link. That leads to a page that asks him to select a printer. There are three shown: B&W, color and transparency along with the rates for each. The web server has used the HTTP headers to identify the client platform and so offers links only to the relevant platform specific configuration downloads. The user clicks on the color printer link. This initiates a client configuration. This transfers the necessary print drivers and configuration information (including the printer URL). This printer now appears as a normal Windows printer The user now opens Word, selects the print shop’s color printer in the print dialog and then starts the print. The print provider spools the data to the web server. The web page that offered links to the printers also has links that allow you to view the queue for that printer. The user clicks on the link for the color printer’s queue and sees his job spooling in and then being printed. 12 References [IPP] deBry R., Hastings T., Herriot B., Isaacson S., "Internet Printing Protocol/1.0 Model and Semantics", IBM, Xerox, Sun, Novell, March 1997 [RFC2068] Fielding R., Gettys J., Mogul J., Frystyk H., Berners-Lee T., "Hypertext Transfer Protocol - HTTP 1.1", UC-Irvine, DEC, MIT/LCS, January 1997 [RFC2069] 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 [ISO] ISO/IEC 10175 Document Printing Application (DPA), Final, June 1996 [RFC1759] Smith, R. Wright, F. Hastings, T,Zilles, S., and Gyllenskog, J. “Printer MIB” RFC 1759, March 1995 ___ INTERNET-DRAFT Simple Web Printing 05/12/97 Page 1 of 1