I've posted some comments on the IPP Level 1 (formerly SWP) ipp-level1-95.*
-rw-r--r-- 1 pwg pwg 15360 Jun 13 00:04 lev1-tnh.doc
-rw-r--r-- 1 pwg pwg 6564 Jun 13 00:05 lev1-tnh.txt
The .txt file is just the relevant paragraphs followed by my comments.
I've copied the .txt into the remainder of this message.
The .doc file is the same as the .txt file, but with revision marks turned=
on for my comments.
I hope that we can cover these comments at the upcoming IPP protocol
meeting, Tuesday, June 17, in San Jose.
The form of the comments is comparing the document with the current
Model and Protocol documents.
I have a number of concerns about the encoding presented in this
document. There are many differences between this document and
the encoding that is in the current IPP Model and Semantics
document and the corresponding protocol document.
The text from the IPP Level 1 document is indented followed by my
comments at the left margin.
1. Page 5, section 1.1 Terminology:
Printer: The logical endpoint for data submitted via IPP1 =96
this may really be a printer. Alternatively it could be
I suggest using the term "output device" in the definition, as in
the Model document, so that the definition is circular.
2. Page 5, Section 2 Job submission:
The major part of IPP1 is the protocol that allows a client
to submit a print job via HTTP. In keeping with its name
this protocol is very simple:-
not SWP anymore
3. Page 7, Section 3.1 200 OK
The URI is encoded in UTF8.
Does the RFC for URI allow UTF8? (I hope so, but we need to
Also need to site the source for UTF8.
4. Page 8, Section 5. Monitoring and management
Allowing the user to cancel their job, whilst queued and
once delivery has started
Does "delivery" mean printing?
5. Page 11, 7.1 Protocol Version
This is a 16 bit value giving the version number of the
protocol encoing of this job. For version 1 it must be
We discussed the concept of major and minor version number in San
Diego. Need to add this here. Presumably the high order octet is
the major version number (1) and the low order octet is the minor
version number (0).
6. Page 11, Section 7.4 Attribute-n
Name is a US-ASCII string identifying the Attribute. The
string is case insensitive. The protocol permits the use of
Do we really want case-insensitive, so that a provider has to
convert to one case for comparison? All the keywords in the
Model document are all lower case with hyphens, except acronyms,
such as URI. Even the first character is lower case. If we have
lengths for efficiency on the provider side, why not also require
correct case too?
7. Page 11, Section 7.4 Attribute-n
any characters, however it is recommended that specialbe
avoided (=91+=92,=92_=92,=92 =91, etc.)
We need to specifically allow ASCII HYPHEN-MINUS (-).
8. Page 12, Section 7.4 Attribute-n
Value-Length is a 16-bit binary value identifying the length
of the value that follows. The NameType, Name-Length, and
Value-Length fields are not included in this length. The
Value-Llength 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 non ASCII
Need to correct the field names throughout the above paragraph.
9. Page 13, Section 8 Attributes
=91SetOfX=92 attributes (ones that have more than one value =96
example =91finishing=92) 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.
In San Diego, we agreed that multiple values has all but the
first with a Name-Length field of 0. This forces the additional
values to be associated with the proper attribute. An example of
multiple values would be good to include, as well.
10. Page 13, Section 8 Attributes
Also need a statement of what happens if the same attribute
appears more than once. Possibilities: syntax error, last
occcurrence wins, first occurrence wins?
11. Page 14, 8.1.3 Boolean
Shall be represented by one octet. X=9200=92 meaning =91false=92 and
X=92FF=92 meaning =91true=92.
Model document has these values as 'false' and 'true', i.e., text
12. Page 14, 8.1.4 Integer
Shall be represented by a 32-bit signed integer . Includes
IntegerSeconds, IntegerPoints, IntegerUnits.
The IPP Model and Protocol documents have these as ASCII digits.
13. Page 14, 8.1.5 DateTime
Shall be encoded in RFC1123 format (e.g. =91Mon, 28 Apr 1997
IPP Model document should clarify this same way as printable text
14. Page 14, 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 (=91medium=92 for example) then the OIDs specified are
The Model document has keywrods as text strings of up to 255
characters in length.
15. Page 14, 8.2 Attributes
All job and document attributes defined in [IPP] may be
included in the IPP1 header.
A server may ignore those attributes that it does not
Model spec says that the Printer shall reject a CreateJob or
PrintJob if the requester supplied any attributes that are not
implemented, any values that are not supported, or any values
with bad syntax.
16. Page 14, 8.2 Attributes
There are no mandatory attributes.
Except the "operation" pseudo attribute.
17. Page 14, 8.2.1 Job-name
Syntax: Text (1 to 4096 characters)
Model document has the 'name' data type as being 255 max length.
18. Page 15, Section 8.2.2 Job-originator
Meaning: A client assigned user name. NFS for the server =96
What is "NFS"?
19. Page 15, Section 8.2.3 Document-format
Syntax: Keyword =96 values taken from [RFC 1759]
Model document has document-format attribute value as the enum
symbol with the "lang" removed and the Protocol document has it
as the MIME type, i.e., a text string name, not a binary code.
20. Page 15, Section 8.2.4 Operation
Syntax : Keyword
PrintJob =3D 1
Validate =3D 2
Should be text string keywords: "PrintJob" and "Validate".
21. Page 16, 8.2.5 Examples
Strings are shown as characters to improve readability, it
should be understood that =91a=92 means hex 21
What is =91a=92? EXCLAMATION POINT (!) is ASCII hex 21.