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: Printer: The logical endpoint for data submitted via IPP1 – 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: 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 check). 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 X’0100’ 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 (‘+’,’_’,’ ‘, 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 characters. Need to correct the field names throughout the above paragraph. 9. Page 13, Section 8 Attributes ‘SetOfX’ attributes (ones that have more than one value – example ‘finishing’) 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’00’ meaning ‘false’ and X’FF’ meaning ‘true’. Model document has these values as 'false' and 'true', i.e., text string. 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. ‘Mon, 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 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 (‘medium’ 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 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 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 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 – treated What is "NFS"? 19. Page 15, Section 8.2.3 Document-format Syntax: Keyword – 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 = 1 Validate = 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 ‘a’ means hex 21 What is ‘a’? EXCLAMATION POINT (!) is ASCII hex 21.