IPP> PRO - Comments on IPP Level 1 (formerly SWP) document

IPP> PRO - Comments on IPP Level 1 (formerly SWP) document

IPP> PRO - Comments on IPP Level 1 (formerly SWP) document

Tom Hastings hastings at cp10.es.xerox.com
Thu Jun 12 20:16:03 EDT 1997


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.



More information about the Ipp mailing list