Subject: IPP> MOD - 5/14 mintues

From: Scott Isaacson <[email-masked]>
Date: Wed, 21 May 1997 12:25:25 -0600

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

ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.txt

The text version is below:

--------------
IPP Model Meeting 5/14/97

            Attendees:

            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
            Lewis

            Agenda

            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
                 xxx-available
            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?

            Discussion

            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
            Service

            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
            protocol.

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

            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
            attributes).

            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
            mandatory.

            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.

            ACTIONS
            -------------

            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-
            supported"
            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: [email-masked]
W: http://www.novell.com
************************************************************

---

From: Tom Hastings <[email-masked]>
Date: Wed, 21 May 1997 21:33:26 PDT

I have several questions and comments on the detailed minutes that Scott
wrote.  Thanks for being so thorough, Scott.

Tom

>            that are not to be implemented in v1.0 of the protocol.

What concepts are these?  
Shouldn't they either be labeled as beyound V1.0 or removed?

>            open the option of Unicode or other DBCS in the actual

Why can't we specify UTF8 (not Unicode) in the Model document as the
coded character set for values?  Then we avoid a lot of messy coded
character set mapping rules in the encoding and protocol documents.
Believe me coded character set mapping is very hard!  Most character sets
don't have all the same characters, and/or have over lapping characters.  
Lets avoid character set mapping altogether in our documents.
We specify USASCII for the attribute name keywords in the model document,
why not specify UTF8 as well (and follow the recommendations of the IETF here).

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

You mean no leading digits; embeded digits are ok, correct?

So need to change the values for the "sides" attribute which are: '1-sided',
'2-sided-long-edge', and '2-sided-short-edge'.
How about 'one-sided', 'two-sided-long-edge', and 'two-sided-short-edge'.

Also the values of the "number-up" attribute which are: '1', '2', and '4'.

Two alternative: 'one-up', 'two-up', 'four-up'.

Or actual integers, but the number-up-supported would be a setOf Integer.
Then there would be no need to register additional values.
Perhaps we'd need to introduce a new datatype: integerMember for the job
attribute, so that we could continue an algorithmic mapping from the data
type of the job attribute to the data type of the xxx-supported, which in this
case would be integerMember to 1SetOf Integer.

>            NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP

Just a nit, but so far keywords have been all lower case with hyphens, except
for acronyms, so here too.  Also we have been using full words, so how about:
'shall-honor-IPP-attributes', 'should-honor-IPP-attributes',
'need-not-honor-IPPP-attributes'?

>            the Printer Job Template attributes to get defaults.

We need to clarify in the above that:
The Printer object applies the default values when there is no value supplied by
either the client in the IPP protocol or by the document in the PDL.
Presumably when the Printer object applies the defaults is implementation
dependent.  Some implementations for some attributes may scan the PDL at job 
submission time, shortly thereafter, or just before processing.  Some 
implementations may wait until during interpretation of the PDL. Some
implementations may set the output device to the default values just prior
to sending the document PDL to the output device.  If the PDL changes the
output device, the PDL overrode the defaults.

>            decision on this.  These are mandatory

Processing to completed is what we already have in the "completion-time"
attribute, so its not new.

I think that we did not agree to add "time-since-processing" on the grounds
that that is an attribute in the Job Monitoring MIB for accounting and
system utilization, so we didn't need to add it to IPP, since IPP isn't
for accounting and utilization analysis.

I think we agreed to change the "completion-time" attribute to
"time-since-completion" to follow the "submission-time" change to
"time-since-submission".

This gets rid of the difficult dateTime data type.

My notes said the units were milliseconds.  But wouldn't seconds be
sufficient?

Nit: should they both be "time-since-submitted" and "time-since-completed" or
"time-since-submision" and "time-since-completion"?

[The attribute table that I sent you had the latter]

>            document-format values.  I didn't capture a final decision

My recollection was that we decided to go with MIME registered types,
insted of the Printer MIB and Job Monitoring MIB Interpreter Language
Family enums.  However, this means that our Printer MIB and Job Monitoring
MIB are different from IPP (so there may be other members of PWG that
disagree with this decision made in the Modeling sub-group of IPP).

>            7. Define SHALL and SHOULD get rid of NEED_NOT

Why get rid of "need not"?  It needed when the standard has to say that an
implementor does not need to do something.  Its too confusing to say 
"may not", since it sounds like a prohibition, rather than a relaxation
of requirements.  POSIX and ISO standards are quite clear on this terminology. 
You even have the value for best-effort with the 'need-not'
value?  

On the other hand, when you find the RFC for IETF conformance
terminology, they may have covered this point.

>            8. Create a table of attributes

Done and sent to Scott, 5/20/97.  Scott said he'd post after reviewing
it for accuracy and comparison with his notes.

---

From: [email-masked] (Robert Herriot)
Date: Thu, 22 May 1997 14:51:08 -0700

> From [email-masked] Wed May 21 21:42:58 1997
> 
> 

It is the duty of the encoding to specify the encoding. In the model,
we could say any character in Unicode and in the encoding document we
could specify the UTF-8 encoding of the Unicode characters.  But in any
case, unless a server supports the entire Unicode character set,
something gets dropped somewhere, and if the server uses some other
encoding, it has to convert at some point and drop whatever characters
the new encoding doesn't support.  So, I am still not sure that all
implementations will want to restrict the protocol to UTF-8 only.  I
could see a Japanese site choosing EUC or SJIS to avoid the conversion
overhead.  It's nice and simple to pick Unicode and UTF-8, but I don't
think it is realistic until Unicode is more pervasive.

> >            NEED_NOT_HONOR_IPP_ATTR (PDL takes precedence over IPP

We dropped NEED_NOT_HONOR_IPP_ATTR because it was the case where a client
could ask for an attribute that the Printer doesn't support. Both the
SHALL_HONOR_IPP_ATTR and SHOULD_HONOR_IPP_ATTR provide for a precedence
of IPP > embedded and embedded > Printer-default. The distinction was
on probability of success.
> The Printer object applies the default values when there is no value supplied 
> by either the client in the IPP protocol or by the document in the PDL.

I think we would specify expected behavior rather that possible implementations.

> for accounting and utilization analysis.

I thought we did agree to have a 'time-since' for each state
attribute.  Though I think that we also agreed that the clock for such
a time stopped when the job moved to the next state. So the name should
be time-<job-state-name>, that is:  time-pending (i.e. time that the
job was in the pending state), time-processing, time-completed,
time-aborted, time-canceled.

> My notes said the units were milliseconds.  But wouldn't seconds be

We picked milliseconds so that a server with many jobs arriving at
subsecond intervals could distinguish order.

> of requirements.  POSIX and ISO standards are quite clear on this terminology.

See my comment above for why to get rid of "need not".