Subject: IPP> IETF/IPP Working Group Minutes 8/11/97

From: Randy Turner <[email-masked]>
Date: Tue, 12 Aug 1997 11:46:42 +0200

IPP Meeting Minutes - IETF 39th Plenary 8/11/97

Carl-Uno Manros opened the meeting and reviewed the agenda.

Steve Zilles then briefly provided a quick overview of IPP,
specifically the object concept. Steve then handed the meeting
off to Scott Isaacson for review of current Model document
issues and proposed resolutions.

The specific issues and resolutions included:

1. BEST-EFFORT

   This attribute has been changed to "ipp-attribute-fidelity"

2. document-name

   "document-name" is optional - the printer will assign some
    document-name to a document if not specified by the client.

3. Persistence of ignored attributes 

   If values are ignored or substituted by an IPP server, the
   originally requested attributes that were replaced will not
   be queryable by a client (queryable?)

4. "Job Problems" in notifications

   Clarified the "job problems" specification in the "notify-events"
   attribute description. The "job problems" specification reflects
   the state of the job at the moment in time when the notify occurs.

5. "Printer Problems"

    Similar to "job problems", this value reflects the current state
    of the "printer-state-reasons" value.

6. Compression of IPP messages

    This issue is OPEN. The WG is looking at other standards and
    existing enumerations for compression algorithms.

7. Alignment with Job MIB

   job-k-octets, job-impressions, and job-media-objects will be
   aligned semantically with the job MIB.

   One note about the job MIB. Keith Moore, our area director for
   applications, noted that there is no formal IETF working group
   chartered for the Job MIB effort. Further, there may be problems
   with IPP achieving "proposed" status if IPP documents reference
   such other documents. He reiterated that the Printer Working
   Group had submitted an extension to the Printer MIB working 
   group's charter to include the Job MIB, but that the request
   was rejected by the IESG, so there may be a problem here.

8. MANDATORY job attributes

   All "time-since-xxxx" attributes are OPTIONAL.

   "number-of-intervening-jobs" is also OPTIONAL.

   "job-name" is MANDATORY. Must be assigned by client or printer.

   "job-originating-user" and "job-originating-host" are being
   merged into a single "job-originating-ID". This new attribute
   is MANDATORY, and is required to enable IPP security.

9. Human Language and Character Set

   IPP mandates UTF-8 for application/ipp messages. HTTP Accept-Headers
   will be used for human-language attributes. Questions from the
   audience asked about whether the WG had considered the use of 
   an updated Unicode spec. UCS-4 which is currently being proposed.
   Scott Isaacson implied that the WG is open to suggestions as to
   what standard should be applied here. The basic theme echoed by
   Keith Moore was to try and follow Harald Alvestrand's document, and
   if better methods are suggested, the IESG will keep an open mind.

10. Job "Processing" state

   Scott Isaacson explained why the "processing" state was defined,
   instead of a "printing" state. Basically, "Logical" and "Physical"
   printers are supported within the IPP model, and the "processing"
   state is less confusing when the job is actually being worked
   on by a "logical" printer. If the model was restricted to purely
   "physical" printers, then "printing" might have sufficed.

11. Job-State-Reasons

   Remove references to log files

12. number-of-intervening-jobs

   Will be OPTIONAL - remains in document.

13. Job-URI attribute

    "A lively discussion ensued". Basically, it was agreed that
    this issue is still OPEN and will be discussed on the mailing
    list.

14. Use of "Conditionally Mandatory" in IPP documents.

    The I-D will be re-edited to focus on what must be implemented 
    in order to realize certain specific functional components.
    Keith Moore reflected on current IETF documents for keywords
    such as MUST, SHOULD, MAY, etc. and that the WG should try and
    follow the IETF guidelines and best current practice with
    regards to such conformance/compliance vocabulary.

15. MANDATORY job attributes

    Again, clarification of the current I-D with regards to
    MANDATORY and OPTIONAL is needed. Also, default attribute
    bindings are applied "late", at job processing time, and not
    job submission time.

16. Use of MIME types for "document-format"

    Currently, the model document specifies the use of Printer MIB
    enumerations for specification of document-format. In addition,
    at a recent IPP meeting, it was agreed that enumerations for
    PDF and HTML would be added to this list. 

    Upon hearing the proposed alignment with the Printer MIB for
    these values, "a lively discussion ensued".

    It was the opinion of Larry Masinter (chair of HTTP WG), Keith
    Moore, and most of the IETF audience that alignment with the
    Printer MIB was a mistake, and that we should focus on sticking
    with MIME-type specifications.

    Further, Keith Moore went on to say that the current draft of
    the Printer MIB was "broken", and that he is seriously
    considering delaying advancement of the Printer MIB draft until
    this (and possibly other) issues are addressed.  Keith did not
    go into any detailed analysis of why the MIB was broken, but
    seemed to suggest that there were more than one reason why it's
    broken. He went on to say that its possible that (ironically)
    the IESG might suggest to the working group that the Printer
    MIB should align itself with the MIME-types and change the way
    that interpreters are enumerated in the MIB. He suggested that
    the group should consider strings, and not enumerations, to
    specify these types (i.e., MIME types). Keith was pretty adamant
    on this issue and would have conntinued discussion, but Steve Z.
    and Scott suggested that discussion on the Printer MIB was
    not appropriate at an IPP WG meeting.  

17. Use of "well known values" in IPP documents.

    Basically, the specification of a value as "well-known" will 
    be removed.

18. Status Code Mappings

    The specification of status code mappings is inconsistent. The
    mapping between status codes and IPP operations will be reviewed.

19. Server Timeout

    The printer will abort a job after some server-configured 
    inactivity timeout. If some documents had already been printed,
    the rest of the job is cancelled. Larry Masinter questioned
    why IPP operations could not be "re-tried" if a failure occurred.
    Steve Zilles responded that there might be idempotency problems
    with operation retries. More discussion on the mailing list 
    should be done.

20. Extensibility of attributes & syntaxes

    These extensions should be accomplished via type-2 enumerations.

21. Version Numbers

    Given the number of HTTP WG members in the room, "a lively
    discussion on capability negotiation and version numbers
    ensued. It is very likely that some combination of versioning,
    and capability negotiation will be required before gaining
    IESG acceptance.

22. Directory syntax/schema

    More work needs to be done to bring the current directory schema
    documents up to date with the current Model document. One of 
    the members of the Service Location Protocol WG mentioned that
    they already have started working on a schema for Printing Class
    applications within their WG, and that input from the IPP WG
    is "very welcome" at this stage. Scott Isaacson stated that
    such cooperation should definitely teke place.

23. User Name

    See job-originating-id. This attribute will replace the user-name
    attribute.

24. Color

    Will remain a boolean, "color-supported'. Leave it to the PDL
    to handle other color model and capabilities requirements.
    Some questions by the audience questioned the usefulness of a
    "boolean" to specify color capabilities. Keith Moore said that
     he would like to see the specification of color capabilities
    more fleshed out than just "yes, this device supports color".
    Larry Masinter also suggested that in order to curb the 
    displeasure with such a "boolean" specification of color, that
    maybe the WG should remove this and just do a complete color
    capabilities model in a future version of IPP. He suggested that
    either IPP should do color (the right way), or not at all. 
    After a brief rationale statement by Scott Isaacson and Steve
    Zilles for the boolean color-supported, both Larry and Keith
    seemed to understand why, but still were not crazy about the
    inclusion of color, without the WG "doing it right".

25. "document-char-set"

    Describes the coded character set of the PDL data - the WG
    agreed to add it.

26. Filter for Get-Jobs operation

    The WG deemed this capability too complex for IPP 1.0

27. Date and Time

    "time-since-xxxx" attributes will be in "seconds" (and OPTIONAL).
    A MANDATORY "printer-up-time" will be added to the spec. and
    will essentially reflect the MIB-II "sysUpTime" object. Larry
    Masinter questioned why a printer "end-user" would care about
    how long the printer had been "up", since IPP 1.0 is basically
    targeted for end-users. He further questioned why the value
    was mandatory. The WG implied that since MIB-II sysUpTime was
    mandatory, that no undue burden should be placed on IPP
    implementations to support it. 

28. Account-Name

    The specification of an account-name has been POSTPONED.

29. Should Validate-Job be OPTIONAL?

    The WG decided that it should be MANDATORY.

30. Formatting Attributes

    The WG will work on a proposal for "page-range" and 
    "page-orientation" attributes.

31. Attribute Group Names

    Support of IPP attribute group names is MANDATORY, however
    one or more attributes within these groups may be OPTIONAL.

32. Order of Jobs returned by "Get-Jobs"

    OPEN.

33. Support for NCs (Network Computers)

    Unclear. This topic was pushed to a future version of IPP WG
    to decide.

34. Event Notification

    The WG has an action item to specify event notifications. They
    should be machine-readable.

35. media-ready vs. media-supported

    OPEN. Some implementation require this distinction. Especially
    server-based implementations of IPP. It was suggested that
    media-supported be dropped and only support for media-ready
    should be supported, since this would apply to all IPP
    configurations.

36. Collated vs. Uncollated copies

    Add two other ranges of values, one for "collated" and one for
    "uncollated" copies.

37. Printer-State-Reasons

    Action item to align with Printer MIB generic alerts.

38. Printer Name

    No restrictions should be placed on printer names. This should
    be a "site policy".

---

From: Larry Masinter <[email-masked]>
Date: Mon, 18 Aug 1997 11:18:03 PDT

>     with MIME-type specifications.

To be more precise:

When IPP is being used for transporting a message (document, print
instructions) from a willing sender to a willing recipient, alignment
with other widely implemented and deployed Internet protocols for
message transmission (mail, fax, Web) is more useful than alignment with
some hypothetical and not widely deployed protocol for system management
and monitoring of the status of a device.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 18 Aug 1997 13:21:08 PDT

> and monitoring of the status of a device.

and stand corrected. I wish to remove the word "hypothetical" and
insert the word "as" before "widely deployed", since there have been
many printers that support the printer MIB.

However, I would like to inquire if there are clients of printer MIBs
that use the enum list of printer interpreters for anything other
than displaying to the user of a system monitoring device for
informational
display, i.e., whether the protocol use within printer MIB could be
replaced with a comment string without affecting the operational
stability of any application.

Larry

---

From: AlBrahme <[email-masked]>
Date: Mon, 18 Aug 1997 18:39:07 +0000

> and monitoring of the status of a device.

 I like this idea. Earlier i tried to get TIFF-F  (for fax) included in
the printer
 mib but did not get much support. But if IPP is going to be aligned
with
 MIME that will solve the problem since TIFF-F will be assigned a MIME
type
 anyway.

 /al