IPP>PRO latest protocol document available

IPP>PRO latest protocol document available

IPP>PRO latest protocol document available

Ira Mcdonald x10962 imcdonal at eso.mc.xerox.com
Thu Jul 3 21:51:45 EDT 1997


Bob Herriot and IPP folks,                        Thursday (3 July 1997)


Here are my comments on Bob's new draft (ipp970702.doc) of the IPP/1.0
Protocol Encoding.  I hope they're helpful.


Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  PO Box 221
  Grand Marais, MI  49839
  906-494-2434


PS - While I could sort of review this document with the MS-Word Viewer,
it wasn't easy - please post IPP documents in '.pdf' and NOT just '.ps'
for those of us who don't have access to hardcopy (or MS-Word) - also,
please use relatively large fonts (eg, 12 point) to ease screen viewing
(eg, on laptops w/ VGA 640x480 resolution) - tables are especially
tricky to view.


------------------ Comments on 'ipp970702.doc' -------------------------


1)  Global - conformance keywords
    - change 'MUST' and 'must' to 'SHALL' - use of both is obscure
    - 'NEED NOT' is defined in POSIX.2 (ISO 9945-2) and NOT in RFC 2119


2)  Global - references
    - use symbolic references (eg, '[RFC-2068]') rather than numeric
      ones (eg, '[1]') - more accessible and safer for proof-reading
      (and one of David Perkins' recent comments on Job Mon MIB draft)
    - add reference to '[US-ASCII]' (ANSI X.3-4:1986) for name strings
      (note that 'US-ASCII' is a 7-bit code set, NOT an 8-bit set!!)
    - add reference to '[POSIX.2]' (ISO 9945-2) for conformance keywords
      (with explanation of relationship to POSIX.3-4 IEEE 1387.4)
    - add reference to '[RFC-1766]' for language tags
      (and clarify whether unregistered extensions are permissible)


3) Global - response formats
    - most robust protocols include the operation code in their response
      formats and do NOT depend on correlators (eg, xid's)
    - I would suggest encoding the 'status' as a named parameter which
      SHALL be included in responses
    - in my experience, this makes debugging much easier, at a very
      modest cost
    - it also would make future extensions for asynchronous responses
      and/or notifications much easier


4)  Page 5 - Section 3.4
    - please number the IPP operation codes from '1' and NOT from '0'
    - else, a future IPP statistics MIB can't have rows indexed by
      the operation code (indices SHALL be positive/non-zero, per SMIv2)
    - we've run into this one repeatedly at Xerox w/ the DPA standard
      (often, we moved the DPA enums up by 3, so that 'other(1)' and
      'unknown(2)' were also possible)


5)  Page 6 - Section 3.7
    - clarify what 'human-readable text' means in this document
      (eg, in the 'locale' of the corresponding request??)
    - clarify what 'locale' means throughout the IPP document set
      (I would suggest a reference to POSIX.2)


6)  Page 7 - Section 3.9
    - 'text' is specified as consisting of UTF-8
      (which is NOT a coded character set!!)
    - a CCS (coded character set) per RFC 2130 is a
      'mapping from a set of abstract characters to a set of integers'
      (eg, UCS-2 in ISO 10646)
    - a CES (character encoding scheme) per RFC 2130 is a
      'mapping from a CCS to a set of octets'
      (eg, UTF-8 in ISO 10646)
    - a TES (transfer encoding syntax) per RFC 2130 is a
      'transformation applied to character data encoded using a CCS and
      possibly CES to allow it to be transmitted'
      (eg, Base64 in RFC 2045)
    - All new Internet protocol standards SHOULD specify (and LABEL
      'over-the-wire') their base CCS, CES, and TES per RFC 2130
      (note HTTP uses ISO 8859-1 as its base CCS and NOT US-ASCII!!)
    - All new Internet protocol standards SHOULD specify ISO 10646
      as their base CCS (coded character set) per RFC 2130
      (but RFC 2130 does NOT specify UCS-2 versus UCS-4!!)
    - All new Internet protocol standards SHOULD specify UTF-8
      as their base CES (character encoding scheme) per RFC 2130
      (but with the UCS-2/UCS-4 amibiguity, this is not rigorous)
    - All new Internet protocol standards SHOULD specify 'something'
      as their base TES (transfer encoding syntax) per RFC 2130
      (and SHOULD use '8-bit clean' transports, if possible)


7)  Page 7 - Section 3.9
    - 'locale' is never referenced elsewhere in this document
    - it SHOULD be part of the protocol encoding (per RFC 2130)


8)  Page 8 - Section 3.10
    - by 'encoding' do you mean the TES (transfer encoding syntax)??


9)  Page 11 - Section 6 - Appendix
    - see RFC 2126 (ISO Transport over TCP/IP), which updates RFC 1006,
      for an example of encoding discrete packets (w/ length) in TCP


10) Page 15 - Other Participants
    - please add 'Angelo Caruso - Xerox'
    - please do NOT add 'Ira McDonald' (my observer role in IPP is out
      of personal interest and NOT one of my main 'tasks' for Xerox)
    - I would suggest referencing ONE participants list in whatever is
      deemed the 'top level' IPP document (although this is a problem
      with separately published and updated RFCs)



More information about the Ipp mailing list