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