attachment-0001

Very good comments, Shawn. The ISTO Printer Working Group shares your desire to eliminate redundancy in the industry by harmonizing standards efforts, where appropriate. This is the main reason we are now formalizing a "Common Semantic Model". This effort spawned from the recognition that the Java Print API, UPnP Printing and Bluetooth Printing all leveraged concepts from IPP but each with somewhat different interpretations. This gave us a signal that the MODEL represented by IPP is applicable to a wide variety of print environments. The first true instance of a print solution based on the PWG Semantic Model will be the Print Services Interface, also coming from the PWG. We hope that OpenPrinting will leverage the Semantic Model and feel there is quite good harmony between the two... largely because of the FSG choice of IPP using CUPS and PAPI. Initially, the Common Semantic Model is largely derived from IPP. In our efforts to document a working version of the SM we have not taken the time to properly address either Job Ticket or Capabilities Object. So far, we have consciously postponed these topics while we lay in other parts of the framework. We have NOT excluded these concepts and fully expect to address them in the future. One of the items the PWG has also been working on is the Universal Printer Description Format (UPDF) which may make an excellent capabilities object describing not only device capabilities but constraints among features as well (can't duplex transparency, for example).   I don't think the FSG has made a bad choice with IPP. To the contrary, there has been enough investment in IPP over the past couple years that you should get a lot of leverage in terms of shortened development cycles and wide product support. I think the PWG Semantic Model can probably benefit more than we realize from experience in the OpenPrinting group with some of our outstanding issues (JT and Capabilities)... albeit perhaps not until v2. PSI is also a good candidate for FSG to leverage if you want to address the web services environment. Your initial focus on IPP (and it's high correlation with the Semantic Model) should give you a head start in this direction.   As for Scan and Fax, the PWG, like any organization, has had to work within our limitations. Our scope is probably in need of expansion in these areas. As you have observed, we do have an IPP-FAX group who are closing in on a universal image format that will allow fax-like operations over IPP. This image format can easily be leveraged by other solutions such as PSI. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- <table width=100%> <tr valign=top> <td> <td>"PRATT,SHAWN (HP-Boise,ex1)" <shawn_pratt@hp.com> 10/11/2002 09:27 AM <td>                To:        "TAYLOR,BOB (HP-Vancouver,ex1)" <robert_b_taylor@hp.com>, "'Hastings, Tom N'" <hastings@cp10.es.xerox.com>, Harry Lewis/Boulder/IBM@IBMUS         cc:        "McDonald, Ira" <imcdonald@sharplabs.com>, "Zehler, Peter" <PZehler@crt.xerox.com>, sm@pwg.org, printing-jobticket@freestandards.org         Subject:        RE: [printing-jobticket] RE: SM> Job "Actual" attributes        </table> <tt>So in reading all of this as well as undertanding the work going on in OpenPrinting, I have a general questions that may be obvious to others but not to me yet.  The assumed communication link for this work has been IPP.   IPP allows for:                 a)  Query printer capabilities,                 b)  Submit print jobs,                 c)  Inquire about the status of print jobs and printers,                 d)  Cancel print jobs.                 e)  Runs on top of HTTP 1.1.   IPP does not currently allow for:                 a)  Support for scan or fax.  There is an active effort (PWG-IFX)          to use IPP for Internet fax, though it's incomplete right now.                     You could probably fake fax through IPP, but I don't know if          anybody has done it.  Scan definitely isn't supported.                 b)  Does not support Job tickets.  I know a lot of these discussion          is about determined what to do for IPP to support job tickets.            We need to determine this in our work as well as see what is          being done elsewhere.                 c)  The format of printer capabilities is all done with          independently defined attributes - you query individually by          attribute.  They are vendor extensible, but you need to          register them through IANA.                 d)  IPP has the concept of an intent ticket, but it is not XML          based, and not easily extensible.                 e)  The model is also primarily enterprise oriented.  What would          need to be done to support the consumer space. Am I correct in these observations? For the Linux standard print model work that the FSG OpenPrinting WG is doing, our goals are not to "reinvent the wheel" and not simply patch the current solutions.  Our objectives are to work with the standards working groups that are already working on various parts of the print model puzzle to ensure that said standards work well for the Linux environment.  In order to do this correctly, first, we need to define the basic print path and the components/standards used along that path.  Second, we need to identify what is missing from those components and standards.  Finally, we need to be working with those owners to make the improvements and/or implementing Linux specific APIs/components.  As well, the OpenPrinting WG is also about looking forward.  Questions we need to answer are:  What is the print model solution we would like for the future?  How can we best provide an architecture and solution that:                 a)  Is scalable to allow solution providers (print vendors,          distributors, and even users) ensure a basic print model,          but also build on it easily to extend the model is the          direction suited for their business.                 b)  Makes it easy for a print vendor to have a solution for          their product.  What I mean here is at a basic print          model level, the vendor does not have to apply many, if          any, resourses to supporting their product.  They can          then focus on the extensibility for their products if          required for their business model needs.                 c)  Is consistent for end-users so they get a consistent print          experience across the different distributions they may be          using. For IPP, I am wondering if we have chosen the correct communication link.  I know this has been the standard used in Linux for sometime, but it seems to be missing some pretty major parts that we would need.  As well, there are other standards being developed such as UPnP and PSI that seem to be working in this same space and seem to be already addressing those needs. I am not trying to create headaches for everyone.  I just want to make sure we are looking at all of our options.   Comments? _____________________________ Shawn Pratt Manager Client Software for Device Enablement and Usage Hewlett-Packard 11311 Chinden Blvd., MS 235, Boise, ID 83714 Phone: 208-396-4628 Email: shawn.pratt@hp.com -----Original Message----- From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:robert_b_taylor@hp.com] Sent: Thursday, October 10, 2002 5:55 PM To: 'Hastings, Tom N'; Harry Lewis Cc: McDonald, Ira; Zehler, Peter; sm@pwg.org; printing-jobticket@freestandards.org Subject: [printing-jobticket] RE: SM> Job "Actual" attributes Since Tom brought up the idea of storing results in the job ticket, we've been thinking of this as "logging annotations" - i.e., you push these "actuals" as logging elements that are added to the ticket as it's processed.  This would look something like: <?xml version="1.0" encoding="UTF-8"?> <ticket>    <mediaSize>A4 </mediaSize>    <logging timestamp="10/10/2002 4:50pm PDT" logger=252.15.43.255>        <mediaSize>US_Letter</mediaSize>      </logging> </ticket> With this, you don't have to redefine elements, even if the service changed them (the "actual" is implied by the <logging/> structure), and you can attach other attributes to the log timestamps, logger IDs, etc.  You have both the original intent and the logging information in the same ticket for archival/audit/accounting, but it's simple to strip all the logging out and re-use the ticket if you want to. thoughts? bt -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Thursday, October 10, 2002 4:38 PM To: Harry Lewis; TAYLOR,BOB (HP-Vancouver,ex1) Cc: McDonald, Ira; Zehler, Peter; sm@pwg.org; printing-jobticket@freestandards.org Subject: RE: SM> Job "Actual" attributes I like Bob Taylor's idea of using the same PWG Semantic Model Job and Document Processing attributes (probably not PWG SM Description attributes) in a different context to indicate what really happened, rather than inventing more xxx-actual attributes.  The PWG Semantic Model already uses this approach for Job Creation, in that Document Processing attributes can be supplied at the Job Level in the Create-Job operation and in each Send-Document operation.  The IPP Document object extension proposes re-using the same IPP Job Template attributes as Document Template attributes, rather than inventing new "document-xxx" Document Template attributes.  (Also the IPP "document-overrides" and "page-overrides" collection attributes re-use the existing Job Template attributes for each override collection value, rather than inventing new name mangling for them). However, I'd also like to suggest a streamlining, by having the new Job Processing Actuals be only the ones that deferred from the ones submitted in the Job Creation Request.  This would do two good things:  Be much more compact and provide a useful indication to the user about what happened differently from what he requested.  I suspect that any defaulting that the Printer supplied would wind up in the Actuals group, but be of the form "xxx", not "xxx-default".  If the PDL had a different value and the Printer didn't override the PDL, then the actual should be the value from the PDL.   Of course, the Job Processing, Job Description, Document Processing, and Document Description attributes that the user submitted should also be in the Job History in just the form that he submitted (as in the current IPP Job History for Job Template attributes and soon to be Document Template attributes - see RFC 2911 section 4.3.7.2). The FSG Job Ticket API wants to store results in the Job Ticket eventually as well. Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Thursday, October 03, 2002 09:37 To: TAYLOR,BOB (HP-Vancouver,ex1) Cc: McDonald, Ira; Zehler, Peter; sm@pwg.org Subject: RE: SM> Job "Actual" attributes I'm not opposed to new operations but I'll observe that multiple attributes is in keeping with the way IPP is currently structured. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "TAYLOR,BOB (HP-Vancouver,ex1)" <robert_b_taylor@hp.com> 10/03/2002 09:42 AM                To:        "Zehler, Peter" <PZehler@crt.xerox.com>, Harry Lewis/Boulder/IBM@IBMUS, "McDonald, Ira" <imcdonald@sharplabs.com>, sm@pwg.org        cc:                Subject:        RE: SM> Job "Actual" attributes       I think I prefer the more "operations" or structurally-oriented approach. The model of having multiple attributes that describe the same "feature" in multiple states (capabilities, intent, process, logging/audit), etc.  seems fragile and error-prone (hence the current "process" vs. "product" discrepancies in CIP4 ...).  I'd rather have us define the feature once, and then define operations or structures that apply the workflow stage semantics.     bt -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Thursday, October 03, 2002 4:43 AM To: 'Harry Lewis'; McDonald, Ira Cc: sm@pwg.org Subject: RE: SM> Job "Actual" attributes Harry,   I like the concept.  I prefer "actual" to "chosen".  Have you considered new operations (e.g. "GetActualJobAttributes"  "GetJobsHistory") to accomplish the same thing.  It would make Printers that implement a job receipt more explicit.  There would be no need for all the new attributes (i.e. "ZZZ-actual").  On the other hand using attributes instead of new operations does have the benefit of being able to retrieve both the requested and actual attributes together and having a static representation that differentiates the two.  Perhaps using both the "actual" attributes and new operations might be more explicit.     Of course there will probably need to be some housekeeping attributes added to the printer for history management/configuration.  I would prefer that something like this be documented separately and referenced in the PWG Semantic Model.  The document would probably be an extension to IPP.   Pete   Peter Zehler XEROX Xerox Architecture Center Email: PZehler@crt.xerox.com Voice:    (585) 265-8755 FAX:      (585) 265-8871 US Mail: Peter Zehler        Xerox Corp.       800 Phillips Rd.       M/S 128-30E       Webster NY, 14580-9701 -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, October 02, 2002 11:57 PM To: McDonald, Ira Cc: sm@pwg.org Subject: RE: SM> Job "Actual" attributes I'm fine with "chosen" vs. "actual"... not as concerned about the name as the concept. In this case, actual might differ from requested due to something like a PDL override (so "chosen" seems to fit) or it COULD differ due to some circumstance (like the job was aborted prior to all copies completing) in which case "actual" seems more apropos. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" <imcdonald@sharplabs.com> 10/02/2002 07:30 PM               To:        Harry Lewis/Boulder/IBM@IBMUS, sm@pwg.org       cc:               Subject:        RE: SM> Job "Actual" attributes       Hi Harry, For what it's worth... Printer MIB used (from DPA I think...) the terminology of 'Declared' or 'Requested' (for the input) and 'Chosen' (for what you're calling 'Actual' below). Cheers, - Ira McDonald -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, October 02, 2002 5:56 PM To: sm@pwg.org Subject: SM> Job "Actual" attributes In IPP, PWG Semantic Model and PSI we have Job Template attributes with "sister" (supported, default and ready) Printer Description attributes. When discussing the purpose of a "Job Ticket" in the semantic model, we often refer to Job Template attributes as the "job ticket" as these carry production intent. By definition, when queried, Job Template attributes must return the value associated with each attribute during submission. Thus, there is no way to query a job (or document) and learn WHAT ACTUALLY HAPPENED w.r.t. any particular attributed (ex. copies). This is covered by the JDF job ticket but we have said JDF is too workflow oriented for (initial) inclusion into the PWG Semantic Model. I would like to propose a solution - the addition of a group of Job Description attributes referred to as "-actual". These could be extensions to the group of Job Progress attributes or a separate grouping of Job Actual (or "Job Completion") attributes. I know, in IPP proper, we don't have the notion of job "history" (the job "disappears" as soon as it has completed) so "actuals" would not be very useful. But in the semantic model and PSI we're trying to overcome this. To the extent that we are reluctant to embrace a full fledged job ticket, the addition of "-actual" attributes should go a long way toward providing much of the essential JT functionality that was previously missing for non-produciton environments. For example: +===================+======================+ | Job Template      |Job Description:Actual| |   Attribute       |   Value Attribute    | +===================+======================+ | copies            | copies-actual        | | (integer (1:MAX)) | (integer (1:MAX))    | +-------------------+----------------------+ | finishings        | finishings-actual    | |(1setOf type2 enum)|(1setOf type2 enum)   | +-------------------+----------------------+ | sides             | sides-actual         | | (type2 keyword)   | (type2 keyword)      | +-------------------+----------------------+ | number-up         | number-up-actual     | | (integer (1:MAX)) | (integer (1:MAX))    | +-------------------+----------------------+ | orientation-      |orientation-requested-| |  requested        |  actual              | |   (type2 enum)    |  (type2 enum)        | +-------------------+----------------------+ | media             | media-actual         | | (type3 keyword |  | (type3 keyword |     | |    name)          |    name)             | +-------------------+----------------------+ | printer-resolution| printer-resolution-  | | (resolution)      |  actual             | |                   | (resolution)         | +-------------------+----------------------+ | print-quality     | print-quality-actual | | (type2 enum)      | (type2 enum)         | +-------------------+----------------------+ ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- </tt>