IPP> MOD - 5/14 mintues

IPP> MOD - 5/14 mintues

IPP> MOD - 5/14 mintues

Scott Isaacson SISAACSON at novell.com
Wed May 21 14:25:25 EDT 1997

I posted the minutes from the 5/14 model meeting in San Diego.  Thanks to
Patrick for hosting the meeting.


The text version is below:

IPP Model Meeting 5/14/97


            Keith Carter, Patrick Powell, Peter Zehler, Carl-Uno Manros,
            Steve Zilles, Randy Turner, Rob Klien, Bob Herriot, Scott
            Isaacson, Tom Hasting, Jeff Copeland, Ron Bergman, Harry


            1. Review High level goals
                 Must an IPP Printer spool?
                 Desktop vs. Workgroup
                 Section 3
                 Review SWP proposal and scope
            2. Review Job Template Attributes
                 No xxx-capable
                 Definition of xxx-supported
            3. Review Mandatory attributes
            4. Protocol Issues
                 Look at Get Jobs
                 Look at Create-Job and Send-Document
                 Are all attributes required in the Create-Job
                 Model relationship to protocol
                 Use of MIME types
            5. Extensibility Statements
            6. Security
            7. I18N
            8 Review 9701512 version of the Model Doc
            9. What does IETF require in terms of Management?


            1. Reviewed the high level goals as enumerated in the
            Requirements Document and the Charter.  Decided that the
            Model as is stands is at the right level to support those
            goals and requirements.  Reaffirmed that an IPP Printer is a
            logical abstraction that is more than just a "print device".
            Text in the document should use Printer Object when there
            might be confusion between an IPP Printer abstraction and a
            print device.

            2. Decided that section 3 needs to be just an introduction
            of the IPP model, not a comparison between some generic
            model that does not exist and IPP.

            3. Clarified that the "originating-host" is always the host
            of the job submitting client.  "originating-host" is not
            used in the case where the IPP Printer forwards the job onto
            some other print subsystem.

            4. Reminder that the Model document still includes concepts
            that are not to be implemented in v1.0 of the protocol.

            5. Steve Zilles reminded us that the IPP model is really a
            OO Database model.  The Printer, Job, and Document objects
            are objects in the OO database.  The Printer is responsible
            for implementing a named logical instance of the data base
            and for implementing an instance of an object to represent
            itself in the database.  There are no exposed operations to
            create or delete or modify new instances of Printer objects
            in IPP v1.0, but there are operations to query the database
            objects (get-attributes, get-jobs).  There are operations to
            control the life cycle of the Job object though.  create new
            instances of Job objects (Create-Job)  and  Documents (Send-
            Document); destroy Job objects (Cancel).   The protocol is
            just an access protocol into this OO Database.

            6. We reviewed the diagrams on page 17 and 21.  Theses need
            to be simplified and condensed into a much more readable
            section : specifically change Print Service => Native Print

            7.  We all seemed to agree that explicit spooling operations
            (get-document, resubmit, etc.) should not part of the model

            8.  Some suggested that RFC 758 or the Bradnor RFC are the
            right documents to find correct  language for conformance

            9.  There was some disagreement about fan-in.  Agreed that
            multiple clients fanning into the same IPP Printer is
            expected and allowed as part of the model.  Agreed that
            multiple Printer Objects for a single printer output device
            is allowed by the model, but not called out explicitly.  Fan
            in of that sort could be used for either multiple defaults
            or access control manipulation.

            10.  Concluded that the Model document does not need to
            address compatibility or coexistance with no modifications
            to Existing Web Browsers or not (this is a protocol issue).

            11  Reminded ourselves that there are really 3 pieces to the
            overall IPP document suite:  Abstract Model, Encoding, and
            Transport mapping

            12. For Job template attributes, we should ignore English
            grammar rules for plural and singular and just use regular
            rules for xxx, xxx-supported, and xxx-available.  Decided
            not to worry about xxx-capable type attributes.

            13. There was much discussion on job-name: whether it should
            be a mandatory attribute that the client must supply in the
            submit request or whether it should be optional and one
            could be generated by the Printer if not supplied by the
            client.  We decided to make ALL Job Template attributes

            optional in the submit request.  That means that the Printer
            simply generates a name based on whatever info it has
            (document names, user name, submitting host name, printer
            name, etc.)  The rules on job-name generation need to be
            cleaned up to not be so limiting.

            14.  All "name", "text", and "fileName" attributes are
            defined as characters in the Model document.  This leaves
            open the option of Unicode or other DBCS in the actual

            15. Reaffirmed that keywords must start with a character (no

            16. The model document is now too verbose and full of too
            much wasted space structure.  The editor should compress the
            format of the Model document.

            17. We had a 3 hour discussion on best-effort.  The final
            proposal was to do away with any notion of "substitute"
            values when there is a conflict between what is requested
            and what is supported.  The expectation is that if a client
            specifies something and it is not supported, return an error
            so that the client can query what is supported.  best-effort
            will now apply to only conflicts between IPP attributes and
            what is in the document stream (PDL) itself.  Proposed
            values are:  SHALL_HONOR_IPP_ATTR (IPP attribute values take
            precedence over PDL instructions),  SHOULD_HONOR_IPP_ATTR
            (same as SHALL with no guarantees), and
            NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP

            18. Clarified that defaults are not overrides.  What does a
            user intend when the user does not specify an attribute:
            either 1)  They want the admin default,  2) They want the
            PDL default.  In either case, they really don't know or
            care, they really care if they specify the value.  The idea
            of "default behavior" will be removed from the Model
            document.  It is not possible to specify a consistent
            default behavior for features that are not implemented or
            for extensions that are yet to be added.

            19.  When a Job object is created only supplied attributes
            will be copied from the request into the Job object.  In
            order to determine the defaults that will be applied, query
            the Printer Job Template attributes to get defaults.

            20. There was a motion to include all of the Job Monitoring
            MIB attributes in the IPP.  This motion was rejected.

            21. There was a discussion about including security concepts
            in the Model document.  There was a suggestion that there be
            a "job-submitter-credentials" attribute in the submit

            request.  All security issues are still on hold awaiting
            more details in the security document.

            22. "orig-user" is part of the security solution and is not

            23. Moved to change from "job-state-as-text" and "printer-
            state-as-text" to "job-state-message" and "printer-state-
            message", make them optional, and allow for less rigid rules
            about text string content.

            24. Moved to make all time related attributes relative to
            job submission (not absolute time).  That is "job-sumission-
            time" moves to "time-since-submitted".  There was also a
            discussion about having "time-since-xxx" attributes for each
            of the Job state transitions (pending to processing,
            processing to completed).  I did not capture the final
            decision on this.  These are mandatory

            25. Moved to make printer-locales-supported and printer-
            locale MANDATORY

            26. Reminder that get-jobs includes a set of attributes in
            which the requester has interest.

            27. We had a discussion on using MIME registered types as
            document-format values.  I didn't capture a final decision
            on this issue.

            28. Decided that all implementations shall support a single
            operation with data and separate create with later data
            operations.  However, as I record these minutes, I note that
            this decision was reversed the next day at the general IPP
            meeting where "levels of conformance" where introduced.

            29. Issues about Job and Document fragmentation are left as
            a protocol exercise.  When there is resolution, the model
            document will be updated to reflect the decision

            30 We went through is "Issue:" paragraph in the 9970512
            model document.  Scott will update the Model document and
            include new text to document the closed issues.


            1. Clean up picture on page 17,  take out output device,
            make an ASCII version of Steve's drawing
            Who: Scott and Steve

            2. Fix section 3.  Do not put in management functions
            Who: Patrick

            3. Rename IPP Printer to IPP Printer Object

            Who: Scott

            4. name (start with char, at least length 1)
            Who: Scott

            5. Restructure the document
            Who: Scott

            6. Fix the section on "implements" it does not read
            correctly as it pertains to Job attributes
            Who: Scott

            7. Define SHALL and SHOULD get rid of NEED_NOT
            Who: Scott

            8. Create a table of attributes
            Who: Tom

            9. Supply text for "color" Job Template attribute "color-
            Who: Randy

            10 Fix missing and incorrect conditionally mandatory
            Who: Scott

            11. Determine if the following Job Template attributes
            should be mandatory or not:   job name, best-effort, copies.
            Who: Scott

            12. job-state-reasons should be 1setOf
            Who: Scott

            13. Add printer-locales-supported and make it and printer-
            locale MANDATORY
            Who: Scott

            14. Remove scheduling-algorithm
            Who: Scott

Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com

More information about the Ipp mailing list