INTERNET-DRAFT
Robert Herriot (editor)
Sun Microsystems
Sylvan Butler
Hewlett Packard
Paul Moore
Microsoft.
Randy Turner
Sharp Labs
July 2, 1997
Internet Printing Protocol/1.0: Protocol Specification
draft-ietf-ipp-protocol-01.txt
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).
Abstract
This document is one of a set of documents, which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technology. The protocol is heavily influenced
by the printing model introduced in the Document Printing Application
(ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and
administrative features, IPP version 1.0 is focused only on end user
functionality.
The full set of IPP documents includes:
Herriot, Butler, Moore and Turner [Page 1]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
Internet Printing Protocol: Requirements
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Security
Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema
The requirements document takes a broad look at distributed printing
functionality, and it enumerates real-life scenarios that help to
clarify the features that need to be included in a printing protocol for
the Internet. It identifies requirements for three types of users: end
users, operators, and administrators. The requirements document calls
out a subset of end user requirements that MUST be satisfied in the
first version of IPP. Operator and administrator requirements are out
of scope for v1.0. The model and semantics document describes a
simplified model with abstract objects, their attributes, and their
operations. The model introduces a Printer object and a Job object. The
Job object supports multiple documents per job. The security document
covers potential threats and proposed counters to those threats. The
protocol specification is formal document which incorporates the ideas
in all the other documents into a concrete mapping using clearly defined
data representations and transport protocol mappings that real
implementers can use to develop interoperable client and server side
components. Finally, the directory schema document shows a generic
schema for directory service entries that represent instances of IPP
Printers.
This document is the "Internet Printing Protocol/1.0: Protocol
Specification" document.
Herriot, Butler, Moore and Turner [Page 2]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
Table of Contents
1. Introduction .......................................................4
2. Conformance Terminology ............................................4
3. Encoding of the Operation Layer ...................................4
3.1 Syntax of Encoding ............................................4
3.2 Diagram of Encoding ...........................................5
3.3 Version .......................................................7
3.4 Mapping of Operations .........................................7
3.5 Mapping of Status .............................................8
3.6 Lengths of Parameter Names ...................................9
3.7 Mapping of Attribute and Parameter Names ......................9
3.8 Lengths of Parameter Values ..................................9
3.9 Mapping of Attribute and Parameter Values ....................10
3.10 Encoding of Data .............................................11
4. Encoding of Transport Layer .......................................11
4.1 General Headers ..............................................12
4.2 Request Headers .............................................13
4.3 Response Headers .............................................14
4.4 Entity Headers ..............................................14
5. Security Considerations ...........................................15
6. Appendix A: Requirements with Transports other than HTTP/1.1 ......16
6.1 Additional Parameter-group for HTTP header information .......16
6.2 Chunking of Data .............................................17
6.3 Revised Syntax for the Operation Layer .......................17
7. References ........................................................18
8. Author's Address ..................................................19
9. Other Participants: ...............................................20
Herriot, Butler, Moore and Turner [Page 3]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
1. Introduction
This document contains the rules for encoding IPP operations and
describes two layers: the transport layer and the operation layer.
The transport layer consists of an HTTP/1.1 request or response. RFC
2068 describes HTTP/1.1. This document specifies the HTTP headers that
an IPP implementation supports.
The operation layer consists of a message body in an HTTP request or
response. The document "Internet Printing Protocol/1.0: Model and
Semantics" defines the semantics of such a message body and the
supported values. This document specifies the encoding of an IPP
operation.
2. Conformance Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [25].
3. Encoding of the Operation Layer
The operation layer SHALL contain a single operation request or
operation response.
The encoding is defined using both a diagram and Augmented Backus-Naur
Form (ABNF), as specified by draft-ietf-drums-abnf-02.txt [29]
All binary integers in this encoding SHALL be transmitted in big-endian
format (also known as _network order_ and _most significant byte first_)
3.1 Syntax of Encoding
The syntax for the operation layer is:
ipp-message = ipp-request / ipp-response
ipp-request = version operation parameters %xFF %xFF [ data ]
ipp-response = version status parameters %xFF %xFF [ data ]
version = major-version minor-version
major-version = SIGNED-BYTE ; initially %d1
minor-version = SIGNED-BYTE ; initially %d0
operation = SIGNED-SHORT ; mapping from model defined below
Herriot, Butler, Moore and Turner [Page 4]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
status = SIGNED-SHORT ; mapping from model defined below
parameters = parameter-group *(%xFF %xFE parameter-group)
parameter-group = *parameter
parameter = single-parameter *(more-values)
single-parameter = name-length name value-length value
more-values = zero-name-length value-length value
name-length = SIGNED-SHORT ; number of octets of `name'
name = LALPHA *( LALPHA / DIGIT / _-_ / ___ )
value-length = SIGNED-SHORT ; number of octets of `value'
value = OCTET-STRING
zero-name-length = %x00 %x00
data = OCTET-STRING
SIGNED-BYTE = %x0..%xFF
SIGNED-SHORT = %x0..%xFF %x0..%xFF
DIGIT = "0".."9"
LALPHA = "a".."z"
BYTE = %x0..%xFF
OCTET-STRING = *BYTE
NOTE: there are 3 additional fields that are positioned, from a decoding
view, in the same position as the `name-length' field. These fields are
defined in the syntax above, and they have the following 3 special
values:
. 0 (0x0000): denotes an additional value of a parameter. When a
parameter has more than one value, the parameter-name for all but
the first value is empty and has a length of zero.
. -1 (0xFFFF): denotes the end of the parameters. The `data' starts
in the next byte. The 2 bytes of -1 are present even when there is
no data.
. -2 (0xFFFE): denotes the end of a parameter group. The next
parameter-group starts in the next byte. This special value exists
only when an operation contains 2 or more parameter groups. A
parameter group is defined in greater detail in section 3.7
_Mapping of Attribute and Parameter Names_.
3.2 Diagram of Encoding
The following is a diagram of the encoding of a request operation.
Note: there are be 1 or more parameter groups and data may be omitted.
----------------------------------------------
| major version | minor version | 2 bytes
----------------------------------------------
| operation | 2 bytes
Herriot, Butler, Moore and Turner [Page 5]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
----------------------------------------------
| parameter-group | k bytes
-----------------------------------------------------------
| 0xFFFE | 2 bytes |
---------------------------------------------- |
| _ | m bytes |
---------------------------------------------- |
| parameter-group | n bytes |- optional
---------------------------------------------- |
| 0xFFFE | 2 bytes |
---------------------------------------------- |
| parameter-group | p bytes |
-----------------------------------------------------------
| 0xFFFF | 2 bytes
----------------------------------------------
| data | q bytes - optional
----------------------------------------------
The following is a diagram of the parameter-group which is 0 or more
parameters
----------------------------------------------
| parameter | r bytes
----------------------------------------------
| _ | s bytes
----------------------------------------------
| parameter | t bytes
----------------------------------------------
Herriot, Butler, Moore and Turner [Page 6]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
The following is a diagram of a parameter. The optional fields are
present only when a parameter has more than one value.
----------------------------------------------
| length-of-name | 2 bytes
----------------------------------------------
| parameter-name | u bytes
----------------------------------------------
| length-of-value | 2 bytes
----------------------------------------------
| parameter-value | v bytes
-----------------------------------------------------------
| 0x0000 | 2 bytes |
---------------------------------------------- |
| length-of-value | 2 bytes |
---------------------------------------------- |
| parameter-value | w bytes |- optional
---------------------------------------------- |
| _ | x bytes |
---------------------------------------------- |
| 0x0000 | 2 bytes |
---------------------------------------------- |
| length-of-value | 2 bytes |
---------------------------------------------- |
| parameter-value | y bytes |
-----------------------------------------------------------
The encoding of a response operation is identical to the encoding of a
request operation except that the `status' field replaces the
`operation' field.
3.3 Version
The version SHALL consist of a major and minor version, each of which
SHALL be represented by a one byte signed integer. The protocol
described in this document SHALL have a major version of 1 (0x01) and a
minor version of 0 (0x00).
3.4 Mapping of Operations
The following SHALL be the mapping of operations names to integer values
which are encoded as two byte binary signed integers. The operations are
defined in the document "Internet Printing Protocol/1.0: Model and
Semantics".
Herriot, Butler, Moore and Turner [Page 7]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
Operation Integer Encoding (in decimal)
Get-Operations 0
Print-Job 1
Print-URI 2
Validate-Job 3
Create-Job 4
Send-Document 5
Send-URI 6
Cancel-Job 7
Get-Attributes 8
Get-Jobs 9
3.5 Mapping of Status
The following SHALL be the mapping of status names to integer values
which are encoded as two byte binary signed integers. The status names
are defined in the document "Internet Printing Protocol/1.0: Model and
Semantics".
If an IPP status is returned, then the HTTP status MUST be 200 (OK).
With any other HTTP status value, the HTTP response SHALL NOT contain an
IPP message-body, and thus no IPP status is returned.
Note: the integer encodings below were chosen to be similar to
corresponding status values in HTTP. But the status returned at the HTTP
level will always be different except in the case where `OK' is returned
at both levels, 200 (OK) in HTTP and 0 (successful-OK) in IPP.
Status Name Integer Encoding (in decimal)
successful-OK 0
client-error-bad-request 400
client-error-unauthorized 401
client-error-payment-required 402
client-error-forbidden 403
client-error-not-found 404
client-error-method-not-allowed 405
client-error-timeout 408
client-error-gone 410
client-error-request-entity-too-large 413
client-error-request-URI-too-long 414
client-error-unsupported-document-format 415
client-error-attribute-not-supported 416
server-error-internal-server-error 500
server-error-operation-not-implemented 501
Herriot, Butler, Moore and Turner [Page 8]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
server-error-service-unavailable 503
server-error-timeout 504
server-error-version-not-supported 505
server-error-printer-error 506
server-error-temporary-error 507
3.6 Lengths of Parameter Names
Each parameter name SHALL be preceded by a two byte binary signed
integer in big endian order which SHALL specify the number of octets in
the name which follows this length, exclusive of the two bytes
specifying the length.
3.7 Mapping of Attribute and Parameter Names
Attribute names and parameter names are ASCII text strings whose values
SHALL be the text names defined in the document "Internet Printing
Protocol/1.0: Model and Semantics".
The document "Internet Printing Protocol/1.0: Model and Semantics"
defines the parameters for each operation. Some of these parameters
SHALL receive special handling in the protocol, as described below.
The parameter named _status_ for each response SHALL become the
_status_ field in the operation layer. A response may optionally
include the parameter _reason-phase_ to specify human readable text
associated with the status. If this parameter is in the response, it
SHALL be the first one.
The parameter named _document-content_, which is defined for some
requests, SHALL become the _data_ in the operation layer.
Requests and responses contain a mixture of parameters and attributes.
All parameters SHALL be in the first parameter-group. Attributes shall
be in the second parameter-group. If an operation returns attributes
from more than one object (e.g. Get-Jobs), the attributes from each
object shall be in a separate parameter-group.
3.8 Lengths of Parameter Values
Each parameter value SHALL be preceded by a two byte binary signed
integer in big endian order which SHALL specify the number of octets in
the value which follows this length, exclusive of the two bytes
specifying the length.
Herriot, Butler, Moore and Turner [Page 9]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
3.9 Mapping of Attribute and Parameter Values
The following SHALL be the mapping of attribute and parameter values to
their IPP encoding. The syntax types are defined in the document
"Internet Printing Protocol/1.0: Model and Semantics".
text - an octet string where each character is encoded in UTF-8. The
first character in the octet string is the encoding of the first
character in the text value
name - same as text
fileName - same as text
keyword - same as text. Allowed text values are defined in the
document "Internet Printing Protocol/1.0: Model and Semantics".
uri - same as text
uriScheme - same as text
locale - same as text
boolean - one binary octet where 0x00 is `false' and 0x01 is `true'
integer - number of octets is a power of 2 (i.e. 1, 2 or 4). These
octets represent a signed binary integer in big endian order (MSB
first).
enum - same as integer. Allowed integer values are defined in the
document "Internet Printing Protocol/1.0: Model and Semantics".
dateTime - same as text. Syntax of data and time is defined by ISO
8601
ISSUE: should ISO 8601 be called out in the model document?
seconds - same as integer
milliseconds - same as integer
1setOf X - encoding according to the rules for a parameter with more
than more value. Each value X is encoded according to the rules
for encoding its type.
rangeOf X - same 1setOf X where the number of values is 2.
There is sometimes a need for a parameter to have some special `out-of-
band' values. Such value are represented by empty values with special
negative lengths as specified by the table below.
default - -1
unsupported - -2
Herriot, Butler, Moore and Turner [Page 10]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
3.10 Encoding of Data
No encoding SHALL be applied to the data. It is included within the
operation as is.
NOTE: HTTP, however, allows an encoding to be applied to the entire
message-body.
4. Encoding of Transport Layer
HTTP/1.1 shall be the transport layer for this protocol.
The operation layer has been designed with the assumption that the
transport layer contains the following information:
- the URI of the target job or printer operation
- the total length of the data in the operation layer, either as a
single length or as a sequence of chunks each with a length.
Each HTTP operation shall use the POST method where the URI the object
target of the operation, and where the _Content-Type_ of the message-
body in each request and response shall be _application/ipp_. The
message-body shall contain the operation layer and shall have the syntax
described in section 2.
ISSUE: Should the URI of the operation be in the operation layer? Should
the URI in the POST be a server/printer always with the target object as
a parameter within the message-body?
In the following sections, there are a tables of all HTTP headers which
describe their use in an IPP client or server. The following is an
explanation of each column in these tables.
- the _header_ column contains the name of a header
- the _request/client_ column indicates whether a client sends the
header. The values in each cell are described below:
- the _request/server_ column indicates whether a server supports the
header when received. The values in each cell are described below.
- the _response/server_ column indicates whether a server sends the
header. The values in each cell are described below:
- the _response /client_ column indicates whether a client supports
the header when received. The values in each cell are described
below.
- the _values and conditions_ column specifies the allowed header
values and the conditions for the header to be present in a
request/response.
Herriot, Butler, Moore and Turner [Page 11]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
The table for _request headers_ does not have columns for responses, and
the table for _response headers_ does not have columns for requests.
The following is an explanation of the values in the _request client_
and _response server_ columns.
man: (mandatory) the client or server MUST send the header,
c-man: (conditionally mandatory) the client or server MUST send the
header when the condition described in the _values and conditions_
column is met,
opt: (optional) the client or server MAY send the header
not: (not needed) the client or server NEED NOT send the header. It
is not relevant to an IPP implementation.
The following is an explanation of the values in the _response client_
and _request server_ columns.
man: (mandatory) the client or server MUST support the header,
opt: (optional) the client or server MAY support the header
not: (not needed) the client or server NEED NOT support the header.
It is not relevant to an IPP implementation.
4.1 General Headers
The following is a table for the general headers.
ISSUE: an HTTP expert should review these tables for accuracy.
General- Request Response Values and Conditions
Header
Cli Serv Serv Cli
ent er er ent
Cache- man not man not _no-cache_ only
Control
Connection c- man c- man _close_ only. Header must be
man man present only for last
request/response before the
connection is closed.
Date opt opt man opt per RFC 1123
Pragma` man not man not _no-cache_ only
Transfer- c- man c- man _chunked_ only . Header must be
Encoding man man present if Content-Length is
absent.
Upgrade not not not not
Herriot, Butler, Moore and Turner [Page 12]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
General- Request Response Values and Conditions
Header
Cli Serv Serv Cli
ent er er ent
Via not not not not
4.2 Request Headers
The following is a table for the request headers.
Request- Cli Serv Request Values and Conditions
Header ent er
Accept opt man _application/ipp_ only. This value is the
default if the client omits it
Accept- opt man per IANA Character Set registry. ISSUE:
Charset is this useful for IPP?
Accept- opt man empty and per RFC 2068 and IANA registry
Encoding for content-codings
Accept- opt man see RFC 1766
Language
Authorizatio c- man per RFC 2068. A client sends this header
n man when it receives a 401 _Unauthorized_
response and no _Proxy-Authenticate_
header.
From not not per RFC 2068. Because RFC recommends
sending this header only with the user's
approval, it is not very useful
Host man man per RFC 2068
If-Match not not
If-Modified- not not
Since
If-None- not not
Match
If-Range not not
If- not not
Unmodified-
Since
Max-Forwards not not
Proxy- c- not per RFC 2068. A client must send this
Authorizatio man header when it receives a 401
Herriot, Butler, Moore and Turner [Page 13]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
Request- Cli Serv Request Values and Conditions
Header ent er
n _Unauthorized_ response and a _Proxy-
Authenticate_ header.
Range not not
Referer not not
User-Agent not not
4.3 Response Headers
The following is a table for the request headers.
Response- Serv Clie Response Values and Conditions
Header er nt
Accept- not not
Ranges
Age not not
Location c- opt per RFC 2068. When URI needs redirection.
man
Proxy- not man per RFC 2068
Authenticate
Public opt opt per RFC 2068
Retry-After opt opt per RFC 2068
Server not not
Vary not not
Warning opt opt per RFC 2068
WWW- c- man per RFC 2068. When a server needs to
Authenticate man authenticate a client.
4.4 Entity Headers
The following is a table for the request headers.
Entity- Request Response Values and Conditions
Header
Cli Serv Serv Clie
ent er er nt
Allow not not not not
Content- not not not not
Herriot, Butler, Moore and Turner [Page 14]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
Entity- Request Response Values and Conditions
Header
Cli Serv Serv Clie
ent er er nt
Base
Content- opt man man man per RFC 2068 and IANA registry
Encoding for content codings.
Content- opt man man man see RFC 1766.
Language
Content- c- man c- man the length of the message-body
Length man man per RFC 2068. Header must be
present if Transfer-Encoding is
absent..
Content- not not not not
Location
Content-MD5 opt opt opt opt per RFC 2068
Content- not not not not
Range
Content- man man man man _application/ipp_ only
Type
ETag not not not not
Expires not not not not
Last- not not not not
Modified
5. Security Considerations
When utilizing HTTP 1.1 as a transport for IPP, all of the security
considerations specified in RFC 2068 apply. In addition, the IPP adds
some additional application-specific security considerations, including
denial-of-service attacks, mutual authentication, and privacy. The IPP
Model document addresses IPP-specific security considerations, while RFC
2068 addresses HTTP-related security considerations.
ISSUE: the security subgroup is free to add whatever is necessary to
fill out the "security considerations" section of this document.
However, the IPP model document should include the bulk of security
discussions that are IPP-specific.
Herriot, Butler, Moore and Turner [Page 15]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
6. Appendix A: Requirements with Transports other than HTTP/1.1
Some transports, such as raw TCP/IP, don't have a way to specify length
or carry along parameters supported by a transport layer, such as
HTTP/1.1. An example of such a parameter is the Content-Encoding for an
operation. Another example is the target URI.
This section specifies the modifications to the operation-layer encoding
for transports, such as raw TCP/IP. The following changes would have to
made. All of these changes are upward compatible with the encoding
defined in section 3 _Encoding of the Operation Layer_.
6.1 Additional Parameter-group for HTTP header information
First there is an additional parameter-group which SHALL appear as the
first parameter-group and which SHALL contain the target URI along with
relevant HTTP header information, including those shown below. This
parameter-group SHALL be preceded by a name-length of -4 (0xFFFC) which
functions like the other negative lengths defined in section 3 _Encoding
of the Operation Layer_. This special number specifies that the first
parameter group contains header type information, and distinguishes it
from the protocol which have these parameters outside of the operation
layer.
The following table shows the mapping of HTTP headers to parameters in
the operation layer.
HTTP header or other IPP parameter name Syntax Type of
concept Parameter
URI target-URI uri
Connection Close-Connection Boolean
Accept-Charset Accept-Charset keyword
Accept-Encoding Accept-Encoding keyword
Accept-Language Accept-Language keyword
Content-Encoding Content-Encoding keyword
Content-Language Content-Language keyword
charset parameter Content-Charset keyword
miscellaneous security if needed at this level
The first parameter in the header parameter-group for a request SHALL be
the attribute _target-URI_ which is the target object of the operation.
Herriot, Butler, Moore and Turner [Page 16]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
ISSUE: should the reason-phrase be in the initial parameter group
instead of the second one for responses?
6.2 Chunking of Data
Second the _parameters_ and _data_ of the operation layer are separated
by -3 (0xFFFD) instead of -1 (0xFFFF) to denote that the following data
is chunked. A chunk of length 0 denotes the end of the data. The syntax
for the chunked data is:
chunked-data = *data-chunk %x00 %x00
data-chunk = data-segment-length data-segment
data-segment-length = SIGNED-SHORT ; number of octets of the data
in binary
data-segment = OCTET-STRING
A data-segment contains fragments of the data. When all the data-
segments are concatenated together, they form the complete data.
6.3 Revised Syntax for the Operation Layer
The following is the revised syntax for the operation layer.
ipp-message = ipp-request / ipp-response
ipp-request = version operation parameters data
ipp-response = version status parameters %xFF %xFF [ data ]
version = major-version minor-version
major-version = SIGNED-BYTE ; initially %d1
minor-version = SIGNED-BYTE ; initially %d0
operation = SIGNED-SHORT ; mapping from model defined below
status = SIGNED-SHORT ; mapping from model defined below
parameters = (headers / parameter-group ) *(%xFF %xFE parameter-
group)
headers = %xFF %xFC parameter-group
parameter-group = *parameter
parameter = single-parameter *(more-values)
single-parameter = name-length name value-length value
more-values = zero-name-length value-length value
name-length = SIGNED-SHORT ; number of octets of `name'
name = LALPHA *( LALPHA / DIGIT / _-_ / ___ )
value-length = SIGNED-SHORT ; number of octets of `value'
value = OCTET-STRING
zero-name-length = %x00 %x00
data = (%xFF %xFF [ full-data ] ) / ( %xFF %xFD chunked-data )
full-data = OCTET-STRING
Herriot, Butler, Moore and Turner [Page 17]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
chunked-data = *data-chunk %x00 %x00
data-chunk = data-segment-length data-segment
data-segment-length = SIGNED-SHORT ; number of octets of the data
in binary
data-segment = OCTET-STRING
SIGNED-BYTE = %x0..%xFF
SIGNED-SHORT = %x0..%xFF %x0..%xFF
DIGIT = "0".."9"
LALPHA = "a".."z"
BYTE = %x0..%xFF
OCTET-STRING = *BYTE
7. References
[1] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog,
J., "Printer MIB", RFC 1759, March 1995.
[2] Berners-Lee, T, Fielding, R., and Nielsen, H., "Hypertext Transfer
Protocol - HTTP/1.0", RFC 1945, August 1995.
[3] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982.
[4] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993.
[5] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
[6] Herriot, R. (editor), X/Open A Printing System Interoperability
Specification (PSIS), August 1995.
[7] Kirk, M. (editor), POSIX System Administration - Part 4: Printing
Interfaces, POSIX 1387.4 D8, 1994.
[8] Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail
Extensions) Part One: Mechanism for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, September, 1993.
[9] Braden, S., "Requirements for Internet Hosts - Application and
Support", RFC 1123, October, 1989,
[10] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC
1179, August 1990.
[11] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform Resource
Locators (URL)", RFC 1738, December, 1994.
Herriot, Butler, Moore and Turner [Page 18]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
[20] Internet Printing Protocol: Requirements
[21] Internet Printing Protocol/1.0: Model and Semantics
[22] Internet Printing Protocol/1.0: Security
[23] Internet Printing Protocol/1.0: Protocol Specification (This
document)
[24] Internet Printing Protocol/1.0: Directory Schema
[25] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 , March 1997
[26] H. Alvestrand, " Tags for the Identification of Languages", RFC
1766, March 1995.
[27] R Fielding, et al, _Hypertext Transfer Protocol _ HTTP/1.1_
RFC 2068, January 1997
[28] Marcus Kuhn, _International Standard Date and Time Notation_,
ISO 8601,
http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html
[29] D. Crocker et al., _Augmented BNF for Syntax Specifications: ABNF_,
draft-ietf-drums-abnf-02.txt.
8. Author's Address
Robert Herriot (editor)
Sun Microsystems Inc.
901 San Antonio.Road, MPK-17
Palo Alto, CA 94303
Phone: 415-786-8995
Fax: 415-786-7077
Email: robert.herriot@eng.sun.com
Sylvan Butler
Hewlett Packard
Boise, ID
Paul Moore
Microsoft
One Microsoft Way
Herriot, Butler, Moore and Turner [Page 19]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
Redmond, WA 98053
Phone: 425-936-0908
Fax: 425-93MS-FAX
Email: paulmo@microsoft.com
Randy Turner
Sharp Laboratories
5750 NW Pacific Rim Blvd
Camas, WA 98607
Phone: 360-817-8456
Fax: : 360-817-8436
Email: rturner@sharplabs.com
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
9. Other Participants:
Ron Bergman - Data Products
Sylvan Butler - HP
Keith Carter - IBM
Jeff Copeland - QMS
Roger Debry - IBM
Lee Farrell - Canon
Brian Grimshaw - Apple
Jerry Hadsell - IBM
Tom Hastings - Xerox
Stephen Holmstead
Zhi-hony Huang - Zenographics
Scott Isaacson - Novell
David Kellerman - Northlake Software
Robert Kline - TrueSpectra
Dave Kuntz - HP
Takami Kurono - Brother
Harry Lewis - IBM
Tony Liao - Vivid Image
David Manchala - Xerox
Carl-Uno Manros - Xerox
J.K. Martin - Underscore
Jay Martin - Underscore
Larry Masinter - Xerox
Bob Pentecost - HP
Patrick Powell - SDSU
Herriot, Butler, Moore and Turner [Page 20]
July 2, 1997, Expires January 2, 1998
INTERNET-DRAFT IPP/1.0: Protocol Specification July 2, 1997
Xavier Riley - Xerox
Gary Roberts - Ricoh
Stuart Rowley - Kyocera
Richard Schneider - Epson
William Wagner - Digital Products
Don Wright - Lexmark
Rick Yardumian - Xerox
Peter Zehler - Xerox
Steve Zilles - Adobe
NOTE: if I missed someone, please let me know.
Herriot, Butler, Moore and Turner [Page 21]
July 2, 1997, Expires January 2, 1998