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
<print data>
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
<Print Data>
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