Subject: IPP> September Meeting Minutes

From: [email-masked]
Date: Mon, 22 Sep 1997 23:45:18 -0400

Here are the meeting minutes from the Spetember Meeting in Atlanta.
I have also posted these to the ftp server as:

ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0997.txt
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0997.pdf

Don

**********************************************
* Don Wright                 [email-masked] *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

------ Minutes
-------------------------------------------------------------

                     Internet Printing Project Meeting Minutes
                                September 17-18, 1997
                                     Atlanta, GA

            The meeting started on September 17, 1997 at 8:40 AM led by
            Carl-Uno Manros.  These minutes were recorded by Don Wright.
            The attendees were:

            * Randy Turner - Sharp
            * Ron Bergman - DataProducts
            * Xavier Riley - Xerox
            * Peter Zehler - Xerox
            * Lee Farrell - Canon
            * Yuji Sasaki - Japan Computer Industry
            * Philip Thambidurai  - Okidata
            * Bob Pentecost - HP
            * Rick Landau - Digital
            * Richard Hart - Digital
            * Lloyd Young - Lexmark
            * Dale Wick - TrueSpectra
            * Bill Wagner - DPI/Osicom
            * Jeff Van Wie - Kodak
            * Bob Herriot - Sun
            * Don Wright - Lexmark
            * Harry Lewis - IBM
            * Steve Zilles - Adobe
            * Mabrey Dozier - QMS
            * Roger deBry - IBM
            * Tom Hastings - Xerox
            * Scott Isaacson - Novell
            * Carl-Uno Manros - Xerox

            Carl-Uno Manros reviewed the agenda for the two days.

            Scott Isaacson reviewed the decision from the last
            conference call to stop adding functionality and hold
            additions for a version 2.0.  At that call, we decided not
            to make any of the job template attributes also document
            attributes.  Additionally, IPP V1 will have NO ATTRIBUTES
            for documents including no longer having a document name.

            Scott went through his list of issues which were posted to
            the FTP server (ftp://ftp.pwg.org/ipp/new_MOD/issues-
            970916.pdf).

            1) Cancel semantics: trailing edge, new job-state reasons
            from Tom Hastings.

            2) Global: MUST, SHOULD, SHALL  editor will fix

            3) Global: Directory document will become an appendix to the
            model document

            4) Global: URI versus URL: leave as URIs.  We will include a
            requirement that the printer must support an http scheme
            URL.  If notification is supported then you must support at
            least the mailto scheme.

            5) Get-Jobs operation: What order are jobs returned?  There
            were a number of arguments on both sides of this issue.  Not
            all OS's return jobs in the same order.  The document will
            state that pending jobs SHALL be returned in the expected
            order of execution.  Completed jobs SHALL be returned with
            the most recently completed jobs returned first.  A enum
            attribute will be added to specify whether the request is
            for pending or completed jobs.  Pending Held jobs are be
            included as active jobs.  Where they are included in the
            list is implementation dependent.

            6) References to Printer MIB and Job Monitoring MIB:  We
            will include references to these documents but not indicate
            whether they are I-Ds or not.

            7) Attribute Syntax:  Text attributes are specified as 1 to
            4095 characters.  Anything that might be expected to be
            exported to a MIB would need to be up to 255. -- Leave as it
            is.

            8) URL versus URI - see #4 above.

            9) Attribute Syntax - date/time - reference the correct RFC
            - Scott will do this.

            10) Job Template Attributes: Job Priority - All
            implementations must accept on the wire values of 1 to 100
            and map them evenly to the internal priority levels.  An
            administrator can limit the range a particular user can
            assign to his job.  (100 is the highest priority.)  How a UI
            maps from the user to the wire is outside the scope of this
            effort.  Scott will write it up in the document as described
            here.

            11) Event Notification Content: Job-State Message and
            Printer-State Message will be UTF-8 encoded ISO10646
            characters in the human language negotiated.

            12) Document Format: Change "mimeType" to "MediaType" and
            reference RFC2046.

            13) user-human-language: should be renamed to job-user-
            human-language? - No -  This is a job template attribute
            which we currently plan to use information from the HTTP
            headers (general or application/IPP?) to set this value.
            Steve Zilles will write this up for inclusion in the model
            document.

            printer-name: need not be translated (set by admin)
            printer-location: need not be translated (set by admin)
            printer-description: need not be translated (set by admin)
            printer-make-and-model: should be translated (set by mfg)
            printer-state-message: translated (computed)
            job-name: not translated (set by user)
            job-state-message: translated (computed)
            job-message-from-operator: need not be translated (set by
            oper)

            The typical internationalization religious discussion
            ensued.  Scott will update the model document to change the
            definition of attribute syntax type text and name to include
            a "language tag" (RFC2184) to precede the actual body of the
            text returned.  This is for both server and client created
            text and names.  The client will be able to ask for a
            certain language from the server using the accept header
            from HTTP.  Implementations may need to remember the
            language request so that notification or an event is
            returned in the requested language.

            14) time-since-pending/processing/completed -- perform the
            editing change suggested and time will be in seconds and not
            ticks.

            Lunch Break:  11:30 - 1:00

            Job-URI versus Job-id

            At 1:00 we began the conference call to discuss the issues
            of Job-URI versus Job-ID issue.  Some of the issues were
            listed:

            1) Existing, job-id oriented APIs
            2) Potential Object-oriented APO
            3) Gateways
                 - IPP client <-> legacy system
                 - Legacy client <-> IPP Printer
            4) Redirection
            5) Scalability
            6) "Helper" Attribute could return the numeric job id

            The issue of the value of being able to see jobs submitted
            via some legacy means as well as IPP submitted jobs using
            IPP was discussed.  Some participants felt that it is
            necessary to expose all jobs submitted from any means while
            others believed that this need was only temporary until
            clients moved to IPP from the legacy environment.

            How do we resolve the difference between the way the Job MIB
            reports jobs versus a Job-URI?

            Since the Job MIB provides more information such as which
            page of the current job is printing, a client might want to
            use the Job MIB to get these details that are not available
            using IPP.  How do you correlate the Job-URI with the JOB
            ID?

            We could add an attribute to the JOB MIB that would be the
            JOB-URI -- Hastings

            We could mandate a job id to be a part of the Job-URI using
            some delimiters - P. Moore

            For the cancel job case, the client must know how to build
            the URI for the job if the URI is not retained just the
            numeric job id - P. Moore

            What if we provided two ways to identify the job:

            1) job-URI
            2) Printer-URI plus job-id

            job-URI Discussion Conclusion:

            All IPP printers shall generate, store (with the job
            information) and return both the job-URI and a 32-bit job-id
            on Print-Job, Print-URI or Create-Job.  It will accept all
            job operations (cancel-job, send-document, send-uri, and
            get-attributes) on either the job-URI or on the Printer-URI
            plus the job-id.  Clients can utilize either method, i.e.
            they can reference a job using the job-URI or the Printer-
            URI plus the job-id.  IDs are only meaningful in the context
            of the Printer-URI to which it was originally submitted.
            Get-Jobs will have to return both job-URI and job-ID as the
            default.  Scott will write this up in the model document.
            If an "IPP printer" also implements the Job MIB, then the
            job-id will be the same between the MIB and IPP.

            - After the conclusion of the job-URI discussion, we
            reviewed some of the
            directions set during the morning session with those on the
            conference call.

            - While the conference call was still open, we discussed the
            use of a port besides 80.  It was the consensus that we
            would not mandate an alternative port number but we would
            not preclude some implementations from using alternative
            ports.  The protocol document should make a statement that
            by default IPP should be supported by servers and clients
            over port 80.

            Model Issues:

            15) Change PDL Override back to Boolean -- no

            16) Covered by #13

            17) Delete appendix C and reference IANA MIME registry: yes,
            but include a couple of examples in the actual attribute
            section.

            18) Addition of document-formats-detected: No - if the
            client knows the document format then it should use that
            attribute and not depend on auto-sensing.

            19) If Create-Job is supported then Send-Document must be
            supported and Send-URI is optional.

            20) No document level attributes - yes

            21) Delete orientation as a job attribute - no - we will add
            reverse landscape -- these only apply to the case of simple
            text.

            22) Compression - IPP will support none, compress, gzip and
            deflate

            23) Any character from ISO10646 (level 2) will be encoded in
            UTF-8.

            24) What does the server do when a time-out occurs after a
            create-job?
                 - delete? (This action could depend on the fidelity
setting)
                 - close and hold?
                 - close and schedule?
            Scott will document these cases and the ramifications.

            25) Is any notion of time (absolute, relative) mandatory?
                 - absolute time is not mandatory
                 - relative time is mandatory

            26) "media-ready" versus "media-supported"

            There was a long discussion on the value of a "media-
            supported" attribute so that a media that could be loaded by
            an operator would be available to the client to choose from.
            If a job is submitted with FIDELITY=TRUE and the media
            requested is not in either list (media-ready or media-
            supported) then the job would be rejected.  If the media is
            supported and not ready, the job would be held until the
            media is loaded.  If FIDELITY is not TRUE, the job would be
            printed on the best available media.  Scott will write this
            up for immediate review.

            27) Delete syntax for "copies-supported" - We will leave it
            as it is and add an attribute "collated-copies-supported"
            that would be available if the printer supported collating
            copies.

            28) Support for ftp and http schemes are required for all
            IPP printers that implement Send-URI and Print-URI.
            Document-URI-schemes-supported will not be implemented for
            V1.  User name and password from the ftp URL will be used if
            provided otherwise anonymous will be used.  The printer
            should check for a supported scheme and reject unsupported
            ones (a new error code is needed.)

            29) Confusion over the group "printer-description" versus
            the actual "printer-description" attribute.  Scott will
            document a change to remove the ambiguity.

            30) Change "color-supported" to provide more information --
            no change for V1.

            31) Editorial:  operations are changed to be like type2
            enums and the pseudo-keywords will follow the keyword
            syntax.

            32) Status Codes and Operations will look like a type2 enum
            but the name space will be managed separately from other
            type2 enums.  Scott will clean up this and #31 in the next
            document.

            33) Job-URI versus Job-id : see discussion and conclusions
            above.

            34) Need some text distinguishing minor version number
            versus major version number.  A change in the major version
            implies a significant structural change while a minor
            version can be parsed around and properly ignored.  Steve
            Zilles will submit some proposed wording for inclusion.

            35) See #28 above.

            36) Document attributes: document attributes are gone.

            37) Default Job Template Attributes should not be treated as
            PDL overrides.

            38) If Fidelity is false and attributes are ignored, should
            the response indicate what attributes were ignored?  Yes -
            document in the model document.

            39) Same as #38.

            40) See #19.

            41) What should be used for media type when PDL is
            automatic?
                 * When document format is missing then default is used.

                 * When application/octet-stream is sent to the printer the
                      printer does its best to figure it out and print it.
                 * Application/octet-stream is valid as the default and
                      means use the auto-sensing mechanism.

            42) The last-sent document can be an empty document.  In
            fact any document can be empty.  An empty document does not
            print a blank sheet; however it will cause a partial sheet
            to be printed.

            43) The last-document attribute (either true or false) must
            be included in any send-document or send-uri and is an error
            if omitted.

            44) If the printer implements the job-state-message then it
            must return it in the Create-Job, Send-Job, and Send-URI
            response.

            45) "message-to-operator" operational attribute: keep

            46) -- This number was skipped --

            47) Document attribute issue - all document attributes
            removed

            48) Attribute Syntax assignments:  Scott will not have
            assignments in the model document.  They will be in the
            protocol document.

            49) Delimiter Tag enums: These will also be in the protocol
            document.

            The meeting adjourned at 5:35PM

            The meeting resumed at 8:30AM, working through the Model
            issues.

            50) Should the enum values be in decimal or hex. -- leave
            them in hex.

            51) Resolution attribute syntax: Will be fixed by Scott.

            52) Does '1setOfX' attribute syntax need to indicate whether
            order is important? : Yes, a statement will be added

            53) Does 'rangeOfX' need to specify that lower is first: yes

            54) Should notify-addresses have a default value? NO

            55) printer-resolution should be of type resolution: Yes

            56) Should compression have a default value? Don't need it;
            client specifies any compression, default doesn't make
            sense.

            57) Job-sheets: When the client provided job-sheets is
            invalid and FIDELITY is true then the printer will reject
            the job.

            58) Add printer-state-message as an optional field in event
            notification content: OK

            59) Event Notification Content -- What printable format is
            time in?  Scott will reference the RFC which defines an
            ASCII format for time.  Scott will move this to the optional
            items at the end of the list.

            60) Event Notification Content needs to be
            internationalized: All 'text' and 'name' will be
            internationalized with the language tag at the front of the
            string.

            61) 'multiple-document-handling' and slip sheets:  Job-
            sheets will be multi-valued.  We will not, at this time, add
            slip-sheets since this is type4 but it could be added later.

            62) 'number-up' will be changed to a type 'setof' integers.
            The lower bound will be 1.  Borders on n-up images will be
            implementation dependent.  Scott will clean up the
            definition of what 'logical' pages are based upon a
            suggestion from Steve Zilles.  Interaction of n-up,
            orientaton, duplex and finishing need to be discussed in the
            document -- Steve Zilles will send a draft to the list for
            review.

            63) IPP should explain printer resolution rather depending
            upon the MIB - Yes

            64) print-quality: Change to say that the value of the
            attribute SHALL be used for the job -- ok

            65) In the orientation section, change langSimpleText to the
            right MediaType -- ok

            66) orientation -- added reverse landscape and see Tom
            Hasting write-up sent on 9/16, subject: MOD - ISSUES in
            09/03 Model document.

            67) "document-name" mandatory? - no document attributes

            68) Should job-URI be a Job Status Attribute? -- It is now
            returned as an operation attribute.  Scott will change this
            and add job-id to be just a job attribute that is returned.

            Add 'number of intervening jobs' as an optional attribute
            returned on the create request.

            69) Generic Alerts from the Printer MIB - Peter will list
            them and Scott will add these as additional printer events.

            70) What about Media-Ready:  covered as #26

            71) Compression: covered as #22

            72) Job URI versus job-id: covered in conference call on
            Wednesday.

            73) job-name versus job-user-label: No, we will have no job-
            user-label

            74) "user-human-language" fixed yesterday as #13.

            75) New 'processing' description: New proposal from Tom
            Hastings to be added with some additional clarification.

            76) Show partitioning of state reasons with states -- No

            77) see #76.

            78) printer-up-time mandatory - yes

            79) Proposal to fold the security document into the model
            document - Scott will merge the documents and the result
            reviewed by the working group.  We will state that an IPP
            printer must support all required authentication security
            specified in HTTP/1.1 (change in protocol document).  (Carl-
            Uno reported that TLS will probably become a proposed
            standard in the next few weeks.)  After some discussion, the
            group came around to the fact that in order to read what
            security means are supported, you must already have made a
            connection to the printer because the security mechanisms
            are at the HTTP level or below and not at the IPP level. The
            group did not want to include a mandate for TLS or TLS
            framing as a part of IPP.  The attribute "security-
            mechanism-supported" is removed.  We will add an attribute
            "printer-tls-uri" which will have the uri for accessing the
            printer in a TLS secure mode.  If a server does any
            security, it SHALL support TLS.  If additional security
            means are provided, we must add additional attributes.
            Randy Turner will investigate and report on the
            interoperability between SSL and TLS.

            The security document mentions that the IPP printer must be
            aware that a virus could be contained in the print job.  How
            that is to be prevented is not addressed by IPP.  The
            document should make this clear.

            80) server-error-device-error:   This error would only be
            returned if the device error prevents the create from
            happening.  For example, if a printer doesn't spool and has
            a limited buffer and the create can't happen because of a
            device error (e.g. paper jam) then this error would be
            returned.  In the case of an IPP Printer with spooling, this
            error would not be returned.

            81) langAuto -- covered in #41.

            82) Relationship to Printer MIB: If an implementation
            chooses to have both IPP and the Printer MIB, a specified
            set of attributes/object shall be identical.  Harry Lewis
            will draft this wording.

            83) Relationship to Job MIB: If an implementation chooses to
            have both IPP and the Job MIB, a specified set of
            attributes/object shall be identical.  Harry Lewis will
            draft this wording.

            Lunch break:  11:45 until 1PM

            84) Proposal on tags (Attribute, Parameter, Data) in the
            protocol now that Parameters are gone. -- After discussion,
            we felt it was cleaner to have separate tags to divide up
            the various sections of attributes:

                 - Operation Attribute Tag
                 - Printer Attribute Tag
                 - Job Attribute Tag
                 - Unsupported Job Attribute Tag
                 - Data Tag

            By having separate printer-attribute and job-attribute tag
            we can add a document-attribute tag or something else later.
            This strategy will make parsing easier.  Any Data-Tag would
            be last; any Operational-Tag would be first.  Each operation
            will explicitly list the order of the tags.  Scott will
            document this approach and include explanation of why
            various attributes are in each category.

            More issues from Tom Hastings iss-903a.doc file.  Starting
            with issues 34.

            TH34) Finishing and orientation:  Will be covered by Steve
            Zilles in his orientation, n-up, etc. document.

            TH34a1) See RFC2046

            TH34a2) Not applicable

            TH35) user-human-language -- already covered in #13

            TH36) job-id: will be positive number

            TH37) user-human-language -- already covered in #13

            TH38) job-state -- leave as type 1

            TH39) time-x-x change from milliseconds to seconds - yes,
            already decided

            TH40) number-of-intervening-jobs: align with JOB MIB - yes

            TH41) We will align k-octets, impressions and sheets with
            the Job MIB.

            TH42) Change the name of printer-description to printer-info
            as decided in #29 above.

            TH43) Copy some language from printer-driver-installer to
            printer-make-and-model & others: Yes

            TH44) Add text to indicate there should be an error reason
            when the printer is "stopped."

            TH45) Scott will add text to the document.

            TH46) We have previously agreed not to align with the JOB
            MIB in the area of defining what an active job is.  See #5.

            TH47) printer-human-language:  Already decided in #13

            TH48) Color: Already decided as #30

            TH49) Internationalization: already decided in #13

            TH50) Indicate that supported values might require human
            (i.e. operator) action.  An example of this should be
            included in the completed description. -- OK

            TH51) Add a suffix to some attributes (-supported) to make
            it clear whether an attribute is default or supported -- OK
            When we add this suffix, the base attribute name will not be
            changed for grammatical reasons.

            SECURITY

            There are reserved port numbers for TLS & SSL on HTTP (port
            443)

            TLS is backwards compatible with SSL3.  Actually TLS is
            SSL3.1  The TLS I-D describes how to support SSL3
            interoperability.

            The group then discussed wording choices for stating the
            security protocol requirements (SSL3, TLS, etc.)  There were
            four wording alternatives explored:

            1) IPP Client/Servers must implement TLS with SSL3
                compatibility
            2) IPP Client/Servers shall be interoperable with a TLS
                communicant
            3) IPP Client/Servers must be TLS compliant.
            4) #2 above plus "with SSL3 backward compatibility"

            Decision: #1 with some section talking about a transition to
            TLS.

            PAGE FORMATING (N-UP, ORIENTATION, Etc.)

            Steve Zilles presented material on this subject.  Steve will
            detail this more and post to the mailing list. Because all
            the interactions with finishing will not be defined for V1,
            the following enums for finishing were removed:
            5,6,7,8,9,10.  These values could be added back in for V2
            when more work has been done to define them.  The values for
            punch, cover and bind will be moved up.  While some
            languages bind on the right and others bind on the left, we
            will leave this as site specific.  Bind-left and bind-right
            could be added later.

            MEDIA TYPES

            Registration of printer datastreams -- Harald A. believes
            that the only way to make sure it gets done is to do it
            ourselves.  Alternatives for registration:

            1) application/print.xxx    (application/print.ipds)
            2) application/vnd.xxx      (application/vnd.ppds)
            3) application/vnd.company.xxx
            (application/vnd.adobe.printgear)
            4) application/xxx          (application/postscript)

            Anything that this group registers could include versions
            and level but it is unclear if level and version could be
            added to something that is already registered.  The group
            unanimously believed that it must do the registration and
            would try to do #1 above with #2 as a fall-back.

            MODEL

            Add a new type called "range-of-int" that would be 8 bytes,
            4 bytes for the low end and 4 bytes for the high end of the
            range. -- YES, this would clearly differentiate range from
            setof.  We can now remove range-of-x since integer is the
            only one we use.

            SZ1) "Instance of a Printer", "Printer Object", "IPP
            Printer" and "Instance of Printer Object" are all used to
            mean the same thing.  We should use only one -- "Printer
            Object" - once the model document has introduced the concept
            of an object.

            SZ2) 3.2.1 needs more clarification in the area of Validate-
            Job: Scott will
            clarify this text.

            SZ3) When is Job-name generated: The name is generated
            before the response on the create is returned.

            SZ4) "snapshot" for all job status attribute is taken at the
            same time.

            SZ5) How unsupported attributes are returned needs some
            clarifications.  Scott and Steve Zilles will work out this
            wording.

            SZ6) Section 3.3.4.1 change "_names (without values) or
            attribute groups_" to and/or.

            SZ7) Section 4.2 - Interaction of defaults with other values
            -- no simple solution -- ignore for now.  Default should be
            described as the most likely value.  For example is the
            default is 2-sided but the media selected is transparency
            then 2-sided does not apply.

            SZ8)  Section 4.2.17 - clarification is needed that only the
            document data is compressed.

            SCHEDULE

            Carl-Uno reviewed the schedule --

            There are now only two standards tracks documents -- "Model"
            and "Protocol."
            Informational documents -- "Requirements," "Rationale" and
            "LPR Mapping"

            When all these documents are published, Carl-Uno will issue
            a last call for the working group.  These comments get
            reflected into the documents.  The documents are then sent
            to the IESG for a last call to the area directors.  Once
            they are turned over to the Area Directors much of the
            control is removed from the hands of the working group.

            After the documents have been turned over to the IETF, the
            PWG group can continue to work on:

            1) Interoperability testing
            2) V2 requirements
            3) Prototyping
            4) etc.

            The meeting adjourned at 5:20 PM.

---

From: [email-masked]
Date: Tue, 23 Sep 1997 09:25:38 -0700 (PDT)

>           by default IPP should be supported by servers and clients

I think that this is a serious mistake.  What is happening here is you
are adding required functionality to a HTTP port service without
coordinating this with the folks doing the HTTP stuff.

In addition,  you are requiring non-printer vendors to supply
a HTTP server that will not only do regular HTTP functionality
but also provide support for IPP as well if they want to do GATEWAY
support for the IPP protocol to other print systems.

This is the part where I disagree strongly.

If you have a separate port for IPP,  then the IPP server and the HTTP
server can be separate;  if you (and ALL HTTP server implementations
that I have looked at support this) support an 'alternate' port
or range of ports, then this can be easily supported.  Note: it is
common to use port 8080 for 'test' purposes in many HTTP servers,
and to allow 'CGI' type of applications to 'check' on the type
of connection allowed. This has to do with firewalls, and internal
versus external connections,  where only INTERNAL hosts can access
via port 8080 and EXTERNAL hosts cannot.

If the IPP protocol is only going to be implemented for NON-GATEWAY
type applications,  i.e. - where you are NOT going to add IPP functionality
to a host for system managment purposes,  then I think this would
be supportable.   But since there is constant and concerning discussion
about Gateways,  and the problems of Gateways,  then we MUST make gateways
as simple and trivial to implement,  independent of the HTTP server.

So the argument about needing all HTTP or similar protocols to go to port 80
(i.e. - HTTP server is misleading) if not downright fallacious.

I apologize for such strong language, but I feel that this statement
must be made.

Patrick Powell

PHILOSOPHICAL STATEMENT

I think that one of the things to keep in mind is separation of functionality
in the TCP/IP world was/is done by PORT number,  NOT overloading a
protocol and server with new/different required functionality.

Example: SSH and RSERVICES use different ports - even though it is
possible to have the RSERVICES server (rlogin, etc.) distinguish
between the type of protocol.

In fact,  pushing this to an extreme,  you could even have FTP/SNMP
on the same port,  and have the functionality distinguished by the
initial connection conversation.

The TCP/IP design was based on using port numbers to distinguish the
type of service,  even if the 'application protocol level' was different.

I think that you will encounter a great deal of opposition if you try
to push this through.