Below are my comments on the latest draft IPP Model, using the plaintext
I-D form, 'ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-970903.txt'.
I have stated section numbers and page numbers from the plaintext I-D.
Hope these are helpful.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434
------------------------------------------------------------------------
1) Global - conformance keywords
- change all 'must' to uppercase 'MUST'
- change all 'shall' and 'SHALL' to uppercase 'MUST'
- reference for 'NEED NOT' is POSIX.2 (ISO 9945-2) - please add
2) Global - directories
- I suggest folding the IPP Directory document into the body of the
IPP Model document (for clarity, same as for IPP Security)
- IPP documents are generally fuzzy about directories and names,
saying that a 'printer-name' is NOT necessarily unique, but also
saying that directories may be used to find printers by name
- NO directory contains 'URLs' (some may contain 'URNs')
- see comment (3) below
3) Global - URIs, URLs, and URNs
- RFC 1738 and RFC 1808 do NOT define URIs - they define ONLY the
location-dependent URLs (Uniform Resource Locators)
- All IPP usage of URIs implies location-dependence, so that 'URI'
(which may also refer to a 'URN', location-independent Uniform
Resource Name, defined in RFC 2141) should NOT be used in IPP
- change 'Universal Resource Identifier' throughout document to
'Uniform Resource Locator' (universality NOT stated by RFC 1738)
- change 'uri' and 'URI' throughout document to 'url' and 'URL'
(to make clear that location-dependent IDs and NOT names are used)
- lastly, parsing URLs is perfectly reasonable - RFC 1808 specifies
rules for parsing all 'well-formed' URLs
4) Section 3.2.6 'Get-Jobs Operation', page 25
- change 'retrieve the list of jobs' to
'retrieve the ordered list of jobs'
- add a forward reference to ordering details in section 3.2.6.1
'Get-Jobs Response' on page 26
5) Section 4 'Object Attributes', page 31
- change 'Printer MIB (Draft Standard in progress...' to
'Printer MIB (work-in-progress...'
(the possible future state of the Printer MIB should NOT be
speculated on in an I-D)
- remove all references to the 'Job Monitoring MIB'
(there is no IETF charter and Harald A has recommended the Job Mon
MIB be published as an Informational RFC, if at all)
6) Section 4.1 'Attribute Syntaxes', page 31
'1' - 'text':
- why is length of 'text' up to '4095' and NOT '255' (same as 'name'
and 'keyword')??
- IETF SMIv1 and SMIv2 rules limit OCTET STRING in MIBs to 255
- if you permit greater than 255, then you need to make trunctation
rules explicit (for export by MIB or other limited interfaces)
7) Section 4.1 'Attribute Syntaxes', page 32
'5' - 'uri':
- see comment (3) above
8) Section 4.1 'Attribute Syntaxes', page 33
'11' - 'dateTime':
- reference the correct name in RFC 1514/1903, ie, 'DateAndTime'
9) Section 4.2 'Job Template Attributes', page 34
Section 4.2.4 'job-priority', page 39
- description of range and use of 'job-priority' does NOT agree with
DPA and Job Mon MIB (which say that ALL systems support 1 to 100
as an APPARENT range, with equal spacing between legal values, for
less fine-grained local priority schemes)
- from ISO 10175, section 9.2.4.6 'Job-priority'
"Priority is expected to be evenly or 'normally' distrbuted across
this range."
10) Section 4.2.2.1 'Event Notification Content', page 38-39
- restriction to 'US ASCII' for 'message' is unreasonable, given IPP
mandate of 'ISO 10646 w/ UTF-8 encoding', and NOT human-friendly
- the idea that application programs will process the content of
'message' (reliably) is implausible - it is MAINLY for humans
- this is NOT aligned with section 4.3.10 'job-state-message' which
uses 'text' (any language, in UTF-8)
- why doesn't the 'user-human-language' attribute apply to messages?
- see comment (12) below
11) Section 4.2.16 'document-format', page 45
- section 13 should NOT list MIME types explicitly
- IPP documents should supply pointers to the MIME registry at IANA
12) Section 4.3.7 'user-human-language', page 49
- rename to 'job-user-human-language' for clarity (and distinction
from the similar Printer object attribute)
13) Section 4.3.12-14 'time-since-pending/processing/completed', page 53
- change names to 'time-at-...', per table in section 4.3, page 47
and section 4.5.21 'printer-up-time', page 65
- change units to 'seconds', per table in section 4.3, page 47
and section 4.5.21 'printer-up-time', page 65
14) Section 4.5.19 'pdl-override', page 64
- change type to 'boolean'
- 'attempted' and 'not-attempted' are obscure, with no benefit
15) Section 7. 'Internationalization Considerations', page 70
- the sentence 'Since these are optional...specific to a given site'
is meaningless
- 'xxx-human-language' attributes need to be MANDATORY (per August
IETF Plenary in Munich)
- Harald Alvestrand's I-D 'Charset Policy' (June 1997, reviewed in
Munich in August), section 4.3 'Considerations for negotiation':
"Protocols that transfer human-readable text MUST provide for
multiple languages...
Negotiating a language should be regarded as a PERMANENT
requirement of the protocol that will not go away at any time in
the future."
16) Section 13 'Appendix C: "document-format" values', page 87
- delete entire appendix, add reference to IANA MIME registry