Minutes of IPP Protocol Meeting The protocol group held a face-to-face meeting on June 17 from 0930 to 1800 at Sun Microsystem in Mountain View. The people attending were: Brian Grimshaw Apple Roger Debry IBM Keith Carter IBM Jeff Copeland QMS Sylvan Butler HP Tom Hastings Xerox Carl-Uno Manros Xerox Bob Herriot Sun Microsystems Randy Turner Sharp (via telephone) NOTE: this document contains the new syntax for protocol. The group first discussed whether the encoding rules should use length or a delimiter to terminate values and other items. We considered three alternatives for representing an attribute: Description Syntax The binary proposal from San Diego binary-length name binary-length value Randy's hybrid name 1*%x20 ascii-length 1*%x20 value CRLF HTTP-like name ":" value CRLF After much discussion and looking at various pros and cons we decided on Randy's hybrid with some modifications. We decided that we didn't want to deal with escaping characters in the value and we didn't want to have binary values. We then decided it was as hard to scan for the end of an ascii integer as to scan for the end of an attribute name. The following is the syntax that we decided on. name %x20 1*4 digit %x20 value We talked about whether we should add a type identifier to specify the type of each attribute value. We decided not to do so because such information is only part of what a client needs to present an unknown attribute. Such information includes type, localization strings and presentation in the GUI. We decided that a client should either hard code (v1) or get such information from a server (later version). For representation of values we decided: Attribute values are all in UTF-8. Integer: only digits 1*10DIGIT Boolean: ascii "0" for false and "1" for true Range is represented by a set of 2 values Set of n elements is represented by a series of n attributes with a 0 length name for attributes 2 through n. date: ISSUE: should we use ISO 8601 vs rfc 1123: Examples: RFC 1123: Wed, 18 Jun 1997 15:20:03 GMT ISO 8601: 1997-06-18 15:20:03Z We changed the version number to be 4 ascii digits, 2 for major version and 2 for the minor version. So the syntax for a request is 4*DIGIT operation-name CRLF *parameters CRLF [ document-data ] The syntax for a response is: 4*DIGIT operation-response-name %x20 ipp-status CRLF * parameters CRLF [response-data] where ipp-status is 6 DIGIT where the first 3 digits are the HTTP status. We decided on all keywords to be case sensitive and follow model document names. Can only register key-words whose letters are all lower case. That is the syntax of a key word is LOWER-ALPHA *( LOWER_ALPHA / DIGIT / "-" / "_" ) Operations are mixed case with hyphens between words. If a Print-Job, Print-URI Create-Job, Send-Document or Send-URI operation has repeated attributes, the last one supersedes any earlier ones. The following is an example of a Print-Job request "0100Print-Job" CRLF "job-name 3 foocopies 1 2document-format 22 application/postscript" "finishings 5 staple 5 punch" CRLF "%!PS" ... The following is an example of a Print-Job response "0100Print-Job-Resp 200000" CRLF "reason-phrase 2 OK job-state 7 pending CRLF A response may have multiple CRLF to separate groups. For example, each CRLF for Get-Jobs separates a job object. ISSUE: is there a CRLF at the end? And do some operations support a back channel within the end of a response? The text in the document should use "attribute" to refer to attributes of an object, even when one is in an operation, but should use the word "parameter" for the other name-value pairs in an operation. Special values such as version have no general name. That is, the field containing the version is called the version. Add Get-Operations which is mandatory and returns all operations supported. Three mandatory operations Print-Job, Validate-Job, Get-Operations. The Printer may return attributes requested via Get-Attributes and Get-Jobs in any order and they need not be in the order requested via the operation. If a client requests an attribute twice in a Get-Attributes or Get-Jobs operation, the server may send it back once or twice and in the latter case the two occurrence may have different values. ISSUE: the group needs to revisit the notion of "do best effort" because of lack of Get-Attributes support in some implementations. It may not be possible for a client to determine what a Printer supports. We did decide that when Print-Job, Create-Job or Validate-Job reject a job, they MUST return at least one attribute that caused the rejection. They should return all attributes that caused a rejection. Such attributes appears as parameters such that the parameter name is the attribute name and the parameter value is the attribute value. If an attribute value is unsupported, its value is the same as the client submitted, and if an attribute name is unsupported, its value is "unsupported". We recognized that that an attribute with the value of "unsupported" would look the same, but we didn't want to fix this problem. The following is the syntax of the protocol that we have agreed on. This is my design of the syntax which should reflect what we agreed on. The following protocol primitives are defined: DIGIT = "0".."9" CRLF = %d13.10 ALPHA = "a..z" BYTE = %d0..%d255 OCTET-STRING = *BYTE The following ABNF specification describes the encoding of an IPP message (PDU): ipp-message = ipp-request / ipp-response ipp-request = version operation CRLF *parameter CRLF [ operation-data ] ipp-response = version operation-resp %x20 status CRLF *parameter CRLF [ response-data ] version = major-version minor-version major-version = 2DIGIT minor-version = 2DIGIT status = 6DIGIT operation = operation-resp = operation "-resp" parameter = name 1*( %x20 value-length %x20 value ) name = ALPHA *(ALPHA / DIGIT / "_" / "-" ) value-length = 1*4DIGIT value = OCTET-STRING operation-data = OCTET-STRING response-data = OCTET-STRING ISSUE: does the protocol support response data? We then reviewed Randy's document and produced the following observations and conclusions. The was a general comment that all semantics should move to the model document and that Randy's document should contain mappings and HTTP information only. We added new attributes job-URI-user and printer-URI-user which are URIs that a browser can use to get information about a job or printer. The job-URI-user is an optional result of a Print-Job and Create-Job operation. We added a parameter to Send-Document and Send-URI called "last-document" (or something like that) which is mandatory and is false for all but the last document to be sent. The document-data for the last document may be empty. We decided that a document-name could be a parameter in a Send-URI or Print-URI operation with document-URI specifying where the document is and document-name specifying a name to identify the document, perhaps on a banner page. Randy proposed that Cancel-Job return various job-state information. There was some question about whether Cancel-Job should have an option that allows a client to choose whether to receive such information. This was left as an ISSUE: We decided that Get-Attributes and Get-Jobs will not return unsupported attributes. We decided that Get-Jobs should not support the filtering mechanism (job-state and job-owner) parameters. We discussed the ordering of job that are pending and pending-held. We concluded that pending-held should appear in their position as if they were pending. Otherwise, a user might be deceived by jobs that move from pending-held to pending an seem to jump ahead in the queue.