I've posted some comments on the IPP Level 1 (formerly SWP) ipp-level1-95.*
document:
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/
-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=
=20
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.
Thanks,
Tom
File: lev1-tnh.txt:
--------------------------------------------------------------------
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.
Tom
1. Page 5, section 1.1 Terminology:
=20
Printer: The logical endpoint for data submitted via IPP1 =96
this may really be a printer. Alternatively it could be
storage, an
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:
=20
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
=20
The URI is encoded in UTF8.
Does the RFC for URI allow UTF8? (I hope so, but we need to
check).
Also need to site the source for UTF8.
4. Page 8, Section 5. Monitoring and management
=20
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
=20
This is a 16 bit value giving the version number of the
protocol encoing of this job. For version 1 it must be
=20
X=920100=92
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
=20
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
=20
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
=20
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
characters.
Need to correct the field names throughout the above paragraph.
9. Page 13, Section 8 Attributes
=20
=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
=20
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
string.
12. Page 14, 8.1.4 Integer
=20
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
=20
Shall be encoded in RFC1123 format (e.g. =91Mon, 28 Apr 1997
09:00:00).
IPP Model document should clarify this same way as printable text
strings.
14. Page 14, 8.1.6 Keywords
=20
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
used.
The Model document has keywrods as text strings of up to 255
characters in length.
15. Page 14, 8.2 Attributes
=20
All job and document attributes defined in [IPP] may be
included in the IPP1 header.
=20
A server may ignore those attributes that it does not
support.
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
=20
There are no mandatory attributes.
Except the "operation" pseudo attribute.
17. Page 14, 8.2.1 Job-name
=20
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
=20
Meaning: A client assigned user name. NFS for the server =96
treated
What is "NFS"?
19. Page 15, Section 8.2.3 Document-format
=20
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
=20
Syntax : Keyword
=20
PrintJob =3D 1
=20
Validate =3D 2
Should be text string keywords: "PrintJob" and "Validate".
21. Page 16, 8.2.5 Examples
=20
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.