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)