Subject: IPP> My comments on IPP Model draft of 3 Sept

From: [email-masked] (Ira Mcdonald x10962)
Date: Sun, 7 Sep 1997 10:21:18 PDT

Scott Isaacson and IPP folks,                  Sunday (7 September 1997)

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