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 = <any operation defined in the model document>
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.