From PZehler at crt.xerox.com Mon Jan 6 08:42:24 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:29 2009 Subject: SM> This week's SM teleconference agenda and information Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. The teleconference is one hour long. It will be run using both phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is 1) Adjust agenda 2) Collect comments and issues on version 17 of the Semantic Model Specification (ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf ) Maui version of the document needs to be final this week. Version with revision marks available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-17-021207-rev.pd f 3) Review schema reorganization. (Latest schema (v0.91) to be published soon under http://www.pwg.org/schemas/sm/latest/ ) Local version available for download at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Schema/latestLocalVersion.zip 4) Plan Maui Semantic Model meeting 5) Next steps Pete All, 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 PS to Bob Taylor: Let me know if there is any problem with Webex for this week. ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 1/9/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ From PZehler at crt.xerox.com Mon Jan 6 08:55:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:29 2009 Subject: SM> Action Required (comments and issues) Message-ID: All, Please review the PWG Semantic Model Specification version 17 (ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-17-021207.pdf). Send your comments or issues to the Semantic Model mail list by the close of business Thursday January 9. I would like to include them in the version for review at the Maui meeting that is due to be sent out on January 10. A version of the specification with revision marks from version 15 is available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-17-021207-rev.pd f Version 15 was the last released version of the document before version 17. 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 From PZehler at crt.xerox.com Tue Jan 7 09:10:34 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:29 2009 Subject: SM> RE: PWG Pattern vs. QName Message-ID: Bob, The only reason I know of now for the patterns is to keep the types used in the union the same. As I recall HP had some problem with a union of two different types. The pattern is defining a QName. (When defining the schema I was focused in reducing the number of types used and overlooked QName) I have no objection to going with QName wherever we are doing extensions federated by a namespace. The elements to be changed are MediaNsExtensionPattern, KeywordExtensionPattern and StringNsExtensionPattern and all the elements that use them. Any objections to making the change? 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: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com] Sent: Thursday, December 19, 2002 8:16 PM To: Peter Zehler [Xerox] (E-mail) Subject: FW: PWG Pattern vs. QName Hi Pete, I got pinged on this internally, and didn't have a good answer. Do we just have these patterns declared to avoid doing a union of NMTOKEN & QName? If not, these patterns look a lot like they are just restricting NMTOKEN to a qualified name. thanks, bt -----Original Message----- From: JARVIS,DAN (HP-Boise,ex1) Sent: Thursday, December 19, 2002 1:03 PM To: TAYLOR,BOB (HP-Vancouver,ex1) Cc: SCHMELING,GARTH (HP-Boise,ex1); HELMS,JANINE (HP-Boise,ex1); FOSTER,WARD (HP-Boise,ex1) Subject: PWG Pattern vs. QName Bob- The following two simple types in the PWG schemas define a pattern that appears to be describing a QName: * MediaNsExtensionPattern (in MediaWellKnownValues.xsd) * KeywordNsExtensionPattern (in PwgWellKnownValues.xsd) Is this pattern intended to be a QName? If so, why is a seemingly complex pattern being used rather than QName? -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030107/e2d188f9/attachment.html From dhall at hp.com Tue Jan 7 18:34:56 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:29 2009 Subject: SM> Union construct for 0.95 Message-ID: <77261E830267D411BD4D00902740AC250DB4C400@xvan01.vcd.hp.com> Hey All During todays PSI meeting, the issue of toolkit support for the union construct in schema definitions came up. In general, one of our goals for the PSI spec is to provide a specification that has a high probability of interoperatibility between different vendors. There are three options available to address the union construct: 1) Leave it as it is, and deal with the toolkits lack of support on a case by case basis. This has the advantage of keeping the specification "pure", but has the dis-advantage of near term interop problems. 2) For the interim, modify the Common Semantic Model to not utilize the union construct. As the toolkits add support, eventually roll the union construct back into the semantic model. This gets us better interop in the near term, but may add turmoil when we re-introduce the union construce. 3) In PSI, duplicate the object defnintions that contain the element refences to the types that are defined by union, and define them directly as an NMTOKEN. In otherwords, create a PSI_DocumentDescription.xsd that has: instead of: This has the advantage of keeping the semantic model "pure", but has the dis-advantage of duplicated container object definitions.. Thoughts / Opinions? Dave From PZehler at crt.xerox.com Wed Jan 8 13:26:00 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:29 2009 Subject: SM> The latest PWG Semantic Model Schema is now available Message-ID: All, The latest PWG Semantic Model Schema (v0.91) is available on the PWG Web site. The Semantic Model web page has been updated (thanks Gail) and is located at . As agreed the namespace for the schema is . The intent of this schema is to provide the latest version of the PWG schema. The contents of this schema may change at any time. Numbered versions, such as v0.90 below, are formal checkpoints and will not be modified. The schemas themselves are located at . For example the Printer Status schema is located at . See the web page for a list of all the schemas. One major change is that there is no longer a single file containing the master list of semantic elements. The semantic elements are now contained in the file that references them. The PwgCommon.xsd file contains elements that are referenced by more than one file. The PWG Semantic Model Schema v0.90 is still available on the PWG Web site. The namespace for this schema is . The schemas themselves are located at . For example the semantic element master list is located at . See the web page for a list of all the schemas. 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 From hastings at cp10.es.xerox.com Wed Jan 8 14:13:39 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> SM/CIP4/PODi/FSG Color & Imaging telecon: Thur, Jan 9, 12:30-3:30 EST (9:30-12:30 PST) Message-ID: For the PWG Semantic Model WG. We're hoping to finish up the review of the IPP color and imaging attributes in the context of JDF. Unfortunately, the time of this three hour meeting overlaps with the regular SM WG Thursday one hour meeting. I'm sorry for the conflict for those who want to attend both. Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, January 07, 2003 19:28 To: printing-jobticket@freestandards.org Cc: 'thor.olsen@efi.com'; 'NIELSEN,MARY (HP-Boise,ex1)'; 'ted_podelnyk@hp.com'; 'Rick.Keeney@efi.com'; Hastings, Tom N Subject: CIP4/PODi/FSG Color & Imaging telecon: Thur, Jan 9, 12:30-3:30 EST (9:30-12:30 PST) Meeting Date: January 09, 2003 Start Time (hh:mm) 9:30 AM PST 10:30 AM America/Denver 12:30 AM EST MeetingPlace Telephone numbers: US and International Calls: 1+ 650-690-9367 Telnet Number (HP employees only): T348-9367 Meeting ID: 2474 Meeting Password: 123 Meeting Name: NIELSEN,MARY Meeting Length: 3 hours We'll also use HP webex: http://hp.webex.com Agenda: Resolve subset of the 70 issues in JDF subset mapping table and JDF/1.1a updated with proposed extensions. Tom to make an agenda with list of ISSUES in order to be processed. I've updated the documents from the last telecons in December. They are available as previously announced: Finish reviewing the color and imaging attribute subset of JDF and mapping from IPP: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c and the JDF/1.2 extensions: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip The detailed IPP Color and Imaging attributes spec that the table references is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg-ipp-color-and-imaging-latest-rev .zip Tom P.S. As we have agreed, for each "latest" version, I also store an identical copy with the date in the title. Here are the correspondences between the "latest" version and the titled files: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev.doc ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.zi p ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev.zip I've also stored the .pdf with just color and with all of the attributes: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev-color-only.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev-all-attrs.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-030107.zip ----- This message was submitted by Tom Hastings (Xerox) Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=4408 Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=7 From dhall at hp.com Thu Jan 9 11:50:14 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:29 2009 Subject: SM> Semantic Model Review Comments Message-ID: <77261E830267D411BD4D00902740AC250DB4C429@xvan01.vcd.hp.com> Hey Pete.. Here is my feedback for the specification. It's looking really good! :) Dave Page 7: Document definition - do we need a mention of multiple files? Document Description Elements - Need to add? Page 11: 4.1.2: The PrinterDescriptionElements contains many *Supported. A short discussion about the differences between the *Supported and the ProcessingSupported object would be helpful. Page 12: Line 256 - Five groups? Add ProcessingActual? Page 14: Line 299 - Four groups? Add DocumentProcessingActual? From hastings at cp10.es.xerox.com Tue Jan 14 01:13:09 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> Joint telecon: Fri, Jan-17, CIP4/PODi/FSG Color and Imaging attri butes Message-ID: Teleconference: Friday, January 17, 2003 650-690-9367 (T348-9367 inside HP) Meeting ID: 2474 (spelled cip4 on a phone) NO password https://hp.webex.com/ Meeting Number: 21162802 Meeting Password: colors Agenda: 6. Address 18 ISSUES in JDF spec with the proposed color extensions. Those issues that don't have anything to do with color will be left for Digital Printing WG and CIP4 to resolve. 7. Address 70 ISSUES in the IPPJDF mapping table document. Those issues that don't have anything to do with color will be left for Digital Printing WG and CIP4 to resolve. I've down loaded a January 13, version of these two specs: Finish reviewing the color and imaging attribute subset of JDF and mapping from IPP: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c and the JDF/1.2 extensions: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip The detailed IPP Color and Imaging attributes spec that the table references is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg-ipp-color-and-imaging-latest-rev .zip Tom P.S. As we have agreed, for each "latest" version, I also store an identical copy with the date in the title. Here are the correspondences between the "latest" version and the titled files: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev.doc ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.zi p ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev.zip I've also stored the .pdf with just color and with all of the attributes: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev-color-only.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev-all-attrs.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-030113.zip From PZehler at crt.xerox.com Tue Jan 14 12:54:06 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:29 2009 Subject: SM> No teleconference on 1/16 or 1/23 Message-ID: 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 From PZehler at crt.xerox.com Tue Jan 14 13:04:37 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:29 2009 Subject: SM> Semantic Model Document v0.18 for review at Maui meeting availabl e Message-ID: All, The latest version of the Semantic Model document is available at . This is version 0.18 of the document and is dated January 13, 2003. This document will be used during the section by section review at the Maui meeting. Please bring any comments, issues or complaints with you to Maui. Those not attending can send them to the Semantic Model mailing list. After the Maui meeting a new version will be published for last call moving the specification from a working document to a PWG draft. As always red-lined versions and .docs are available at the following URLs 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 From PZehler at crt.xerox.com Tue Jan 14 13:58:17 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:29 2009 Subject: SM> Agenda for Semantic Model Face to Face Message-ID: All, Here is what I have so far for the face to face. Let me know if you have any additions. 1) Introductions and Agenda bashing 2) PWG Semantic Model section by section review to prepare for last call work through simple issues, defer ones that take too long 3) Schema overview of changes Discuss organization issues and type/element naming 4) Document Object Close outstanding issues to prepare for last call 5) Processing Actual Close any outstanding issues review schema representation 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 From hastings at cp10.es.xerox.com Fri Jan 17 05:46:16 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> Version 0.6 of the IPP Document object specification is available Message-ID: I've stored version 0.6 of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .doc Version 0.6 contains the agreements reached at the last PWG face to face and on the SM telecons. Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just posted. The issues will be reviewed during the PWG Semantic Model face to face meeting, Thursday, 23. Is this specification ready for Last Call? Here are 9 ISSUES: ISSUE 01: It is the [override] specification the allowed these four "compression", "document-format", "document-name", and "document-natural-language" operation attributes to be supplied in the Create-Job request. There needs to be a way for a client to query to see what was submitted. Possible solutions: a. OK to have the exception to the no copy down rule for these four which do not have any corresponding Job Description attributes to hold them? Otherwise, there would be no queriable record of what the client had supplied when the client only supplies them in the Create-Job operation. b. Or would it be better, simpler, and more consistent to define the four corresponding Job Description attributes and have the Printer just copy the operation attributes to them, like most other operation attributes? c. Or should we forget the [override] extension and go back to the RFC2911 Create-Job definition (see [RFC2911] section 3.2.4) which does not allow these four operation attributes to be submitted in the Create-Job, but requires that the client supply them each time in each Send-Document and Sent-URI operation, if the client wants to submit them at all. Then the Printer just copies them to the corresponding Document Description attributes and there is no inheritance problem between the Job and Document level for these four attributes. ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 04: Is the definition of "document-format-detail" OK? ISSUE 05: Should we call this member attribute "os-type", instead of "platform", in order to agree with the PWG Printer Installation Extension (see draft-ietf-ipp-install-04.txt)? ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 06: This is a change from [override], OK? ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 07: This is a change from [override], OK? ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? Version 0.6, 13 January 2003, agreements from New Orleans October PWG meeting and subsequent telecons: 1. Deleted the Cancel-Current-Document and Validate-Document operations. 2. Deprecated the "input-document-number" operation attribute from the Document Creation operations. 3. Deleted the "document-mandatory-attributes" operation attribute to align with the PWG Semantic model. So both specifications have only the "job-mandatory-attributes" operation attribute. The client can only supply at the Job Level. The Document Level inherits from the Job Level. 4. Increased "document-message" operation attribute length from 127 to MAX (1023) octets. 5. Clarified that "ipp-attribute-fidelity" and "job-mandatory-attributes" can only be supplied at the Job Level; the Document level inherits their values. 6. Added "ipp-attribute-fidelity" and "job-mandatory-attributes" Job Description attributes. 7. Added the "media-size-name" as a member attribute of "media-col" and as a separate Job Template attribute as used by UPnPv1 and UPnPv2. 8. Added the "media-type" as a Job and Document Template attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as a member attribute of the "media-col" Job and Document Template attributes). 9. Renamed "document-printer-up-time" Document Description attribute to simply "printer-up-time". 10. Added the following Job Description attributes: "ipp-attribute-fidelity", and "job-mandatory-attributes". 11. Removed the following Document Description attributes: "ipp-attribute-fidelity". 12. Added the following Document Description attributes: "document-format-detail", "document-format-detected", "job-id", "job-printer-uri", "job-uri", "output-device-assigned". 13. Defined all of the Document Description attributes, often with references to other specifications, so that they appear in the table of contents. Send comments to the mailing list. Thanks, Tom P.S. I'll not be attending the meeting. From hastings at cp10.es.xerox.com Fri Jan 17 16:55:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> IPP/SM ISSUE 10: Name of JobMandatoryElements Message-ID: Here is ISSUE 10 to be added to the 9 ISSUE. This one affects both the IPP Document object spec and the PWG Semantic Model document. Version 0.6 of the IPP Document object specification aligns with the attributes of the Semantic Model version 0.18. The Semantic Model has the Job Description Element: JobMandatoryElements The values are a list of Element names of the Job Processing and Document Processing Elements that the submitter wants to be Mandatory, else the provider MUST reject the request. The IPP Document object spec has the "job-mandatory-attributes" (1setOf type2 keyword) operation attribute which the Printer copies to the corresponding "job-mandatory-attributes" Job Description attributes. The values are a list of the keyword names of the Job Template and Document Template attributs that the submitter wants to be Mandatory, else the provider MUST reject the request. Neither spec allows this same Element/attribute to also be a Document Description Element/attribute. This simplification is fine. So whatever Job and Document Elements/attributes are declared to be mandatory at the Job level must be mandatory at the Document level as well. A possible extension in the future might be to allow the submitted to submit this Element/Attribute in a Document Creation request. If that ever happens, we will regret that its name started with "Job"/"job-", because we have to invent a new name with the "Job"/"job-" prefix either removed or change to something else, like "Document"/"document-". Since the values are already contaiing both job and document attributes, I don't see any problem with just dropping the "Job"/"job-" prefix now. But I'm not suggesting that the renamed Element/attribute can be submitted at the Document level. A further agrument of removing the "Job"/"job-" prefix is that a closely relate Element/attribute: ElementFidelity/"ipp-attribute-fidelity" is also limited to being a Job level attribute by being a Job Description attribute and not a Document Description attribute. However, it too also affects both job and document attributes making them all mandatory. Comments? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, January 17, 2003 02:46 To: sm@pwg.org Subject: SM> Version 0.6 of the IPP Document object specification is available I've stored version 0.6 of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .doc Version 0.6 contains the agreements reached at the last PWG face to face and on the SM telecons. Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just posted. The issues will be reviewed during the PWG Semantic Model face to face meeting, Thursday, 23. Is this specification ready for Last Call? Here are 9 ISSUES: ISSUE 01: It is the [override] specification the allowed these four "compression", "document-format", "document-name", and "document-natural-language" operation attributes to be supplied in the Create-Job request. There needs to be a way for a client to query to see what was submitted. Possible solutions: a. OK to have the exception to the no copy down rule for these four which do not have any corresponding Job Description attributes to hold them? Otherwise, there would be no queriable record of what the client had supplied when the client only supplies them in the Create-Job operation. b. Or would it be better, simpler, and more consistent to define the four corresponding Job Description attributes and have the Printer just copy the operation attributes to them, like most other operation attributes? c. Or should we forget the [override] extension and go back to the RFC2911 Create-Job definition (see [RFC2911] section 3.2.4) which does not allow these four operation attributes to be submitted in the Create-Job, but requires that the client supply them each time in each Send-Document and Sent-URI operation, if the client wants to submit them at all. Then the Printer just copies them to the corresponding Document Description attributes and there is no inheritance problem between the Job and Document level for these four attributes. ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 04: Is the definition of "document-format-detail" OK? ISSUE 05: Should we call this member attribute "os-type", instead of "platform", in order to agree with the PWG Printer Installation Extension (see draft-ietf-ipp-install-04.txt)? ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 06: This is a change from [override], OK? ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 07: This is a change from [override], OK? ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? Version 0.6, 13 January 2003, agreements from New Orleans October PWG meeting and subsequent telecons: 1. Deleted the Cancel-Current-Document and Validate-Document operations. 2. Deprecated the "input-document-number" operation attribute from the Document Creation operations. 3. Deleted the "document-mandatory-attributes" operation attribute to align with the PWG Semantic model. So both specifications have only the "job-mandatory-attributes" operation attribute. The client can only supply at the Job Level. The Document Level inherits from the Job Level. 4. Increased "document-message" operation attribute length from 127 to MAX (1023) octets. 5. Clarified that "ipp-attribute-fidelity" and "job-mandatory-attributes" can only be supplied at the Job Level; the Document level inherits their values. 6. Added "ipp-attribute-fidelity" and "job-mandatory-attributes" Job Description attributes. 7. Added the "media-size-name" as a member attribute of "media-col" and as a separate Job Template attribute as used by UPnPv1 and UPnPv2. 8. Added the "media-type" as a Job and Document Template attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as a member attribute of the "media-col" Job and Document Template attributes). 9. Renamed "document-printer-up-time" Document Description attribute to simply "printer-up-time". 10. Added the following Job Description attributes: "ipp-attribute-fidelity", and "job-mandatory-attributes". 11. Removed the following Document Description attributes: "ipp-attribute-fidelity". 12. Added the following Document Description attributes: "document-format-detail", "document-format-detected", "job-id", "job-printer-uri", "job-uri", "output-device-assigned". 13. Defined all of the Document Description attributes, often with references to other specifications, so that they appear in the table of contents. Send comments to the mailing list. Thanks, Tom P.S. I'll not be attending the meeting. From hastings at cp10.es.xerox.com Fri Jan 17 23:01:12 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> FW: Completed JDF Color extension spec and IPP mapping specs, 17- Jan-2003, available Message-ID: -----Original Message----- From: Hastings, Tom N Sent: Friday, January 17, 2003 20:00 To: 'color_workflow@cip4.org' Subject: Completed JDF Color extension spec and IPP mapping specs, 17-Jan-2003, available The joint Digital Printing and Color Workflow WG project to add more color and imaging to JDF/1.2 based after reviewing the IPP Color and Imaging attributes has completed its proposed set of updates. I've down loaded a January 17, version of these two specs: The mapping of IPP color and imaging to JDF: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f and the JDF/1.2 extensions: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip The detailed IPP Color and Imaging attributes spec that the table references is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg-ipp-color-and-imaging-latest-rev .zip The .doc file has the non-color attributes as hidden text. To see go into MS-WORD and display hidden text (Tools/Options/View/Display Hidden Text). The .pdf versions don't show the non-color attributes. Tom P.S. As we have agreed, for each "latest" version, I also store an identical copy with the date in the title. Here are the correspondences between the "latest" version and the titled files: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-17-Jan-20 03-rev.doc ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-17-Jan-20 03-rev.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.zi p ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-17-Jan-20 03-rev.zip From imcdonald at sharplabs.com Mon Jan 20 14:47:59 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:29 2009 Subject: SM> IPP/SM ISSUE 10: Name of JobMandatoryElements Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE8E@mailsrvnt02.enet.sharplabs.com> Hi Tom, Agreed - please drop the "job-" prefix throughout (SM and IPP). Cheers, - Ira -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, January 17, 2003 3:55 PM To: sm@pwg.org Subject: SM> IPP/SM ISSUE 10: Name of JobMandatoryElements Here is ISSUE 10 to be added to the 9 ISSUE. This one affects both the IPP Document object spec and the PWG Semantic Model document. Version 0.6 of the IPP Document object specification aligns with the attributes of the Semantic Model version 0.18. The Semantic Model has the Job Description Element: JobMandatoryElements The values are a list of Element names of the Job Processing and Document Processing Elements that the submitter wants to be Mandatory, else the provider MUST reject the request. The IPP Document object spec has the "job-mandatory-attributes" (1setOf type2 keyword) operation attribute which the Printer copies to the corresponding "job-mandatory-attributes" Job Description attributes. The values are a list of the keyword names of the Job Template and Document Template attributs that the submitter wants to be Mandatory, else the provider MUST reject the request. Neither spec allows this same Element/attribute to also be a Document Description Element/attribute. This simplification is fine. So whatever Job and Document Elements/attributes are declared to be mandatory at the Job level must be mandatory at the Document level as well. A possible extension in the future might be to allow the submitted to submit this Element/Attribute in a Document Creation request. If that ever happens, we will regret that its name started with "Job"/"job-", because we have to invent a new name with the "Job"/"job-" prefix either removed or change to something else, like "Document"/"document-". Since the values are already contaiing both job and document attributes, I don't see any problem with just dropping the "Job"/"job-" prefix now. But I'm not suggesting that the renamed Element/attribute can be submitted at the Document level. A further agrument of removing the "Job"/"job-" prefix is that a closely relate Element/attribute: ElementFidelity/"ipp-attribute-fidelity" is also limited to being a Job level attribute by being a Job Description attribute and not a Document Description attribute. However, it too also affects both job and document attributes making them all mandatory. Comments? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, January 17, 2003 02:46 To: sm@pwg.org Subject: SM> Version 0.6 of the IPP Document object specification is available I've stored version 0.6 of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .doc Version 0.6 contains the agreements reached at the last PWG face to face and on the SM telecons. Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just posted. The issues will be reviewed during the PWG Semantic Model face to face meeting, Thursday, 23. Is this specification ready for Last Call? Here are 9 ISSUES: ISSUE 01: It is the [override] specification the allowed these four "compression", "document-format", "document-name", and "document-natural-language" operation attributes to be supplied in the Create-Job request. There needs to be a way for a client to query to see what was submitted. Possible solutions: a. OK to have the exception to the no copy down rule for these four which do not have any corresponding Job Description attributes to hold them? Otherwise, there would be no queriable record of what the client had supplied when the client only supplies them in the Create-Job operation. b. Or would it be better, simpler, and more consistent to define the four corresponding Job Description attributes and have the Printer just copy the operation attributes to them, like most other operation attributes? c. Or should we forget the [override] extension and go back to the RFC2911 Create-Job definition (see [RFC2911] section 3.2.4) which does not allow these four operation attributes to be submitted in the Create-Job, but requires that the client supply them each time in each Send-Document and Sent-URI operation, if the client wants to submit them at all. Then the Printer just copies them to the corresponding Document Description attributes and there is no inheritance problem between the Job and Document level for these four attributes. ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 04: Is the definition of "document-format-detail" OK? ISSUE 05: Should we call this member attribute "os-type", instead of "platform", in order to agree with the PWG Printer Installation Extension (see draft-ietf-ipp-install-04.txt)? ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 06: This is a change from [override], OK? ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 07: This is a change from [override], OK? ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? Version 0.6, 13 January 2003, agreements from New Orleans October PWG meeting and subsequent telecons: 1. Deleted the Cancel-Current-Document and Validate-Document operations. 2. Deprecated the "input-document-number" operation attribute from the Document Creation operations. 3. Deleted the "document-mandatory-attributes" operation attribute to align with the PWG Semantic model. So both specifications have only the "job-mandatory-attributes" operation attribute. The client can only supply at the Job Level. The Document Level inherits from the Job Level. 4. Increased "document-message" operation attribute length from 127 to MAX (1023) octets. 5. Clarified that "ipp-attribute-fidelity" and "job-mandatory-attributes" can only be supplied at the Job Level; the Document level inherits their values. 6. Added "ipp-attribute-fidelity" and "job-mandatory-attributes" Job Description attributes. 7. Added the "media-size-name" as a member attribute of "media-col" and as a separate Job Template attribute as used by UPnPv1 and UPnPv2. 8. Added the "media-type" as a Job and Document Template attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as a member attribute of the "media-col" Job and Document Template attributes). 9. Renamed "document-printer-up-time" Document Description attribute to simply "printer-up-time". 10. Added the following Job Description attributes: "ipp-attribute-fidelity", and "job-mandatory-attributes". 11. Removed the following Document Description attributes: "ipp-attribute-fidelity". 12. Added the following Document Description attributes: "document-format-detail", "document-format-detected", "job-id", "job-printer-uri", "job-uri", "output-device-assigned". 13. Defined all of the Document Description attributes, often with references to other specifications, so that they appear in the table of contents. Send comments to the mailing list. Thanks, Tom P.S. I'll not be attending the meeting. From hastings at cp10.es.xerox.com Tue Jan 21 21:06:10 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> Adding 4 more member attributes to "document-format-detail" (coll ection) attribute Message-ID: PWG Semantic Model folks (and IPP WG folks), This is a similar mail message that I've send to the CIP4 JDF Capabilities WG. The IPP Document object spec has a "document-format-detail" (collection) attribute which contains member attributes that give more information about a document, such as "document-format-version", "document-format-natural-language", "platform", "device-id", and a recursive "document-format-details" (collection) to describe the unique Parts of an application/zip or multipart/related file. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf The IPP "document-format-details" (collection) attribute is much like the FileSpec resource in JDF. So I've downloaded a comparison of the IPP document format attributes including the proposed "document-format-detail" (collection) attribute and the JDF/1.1 FileSpec resource. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentParts. and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application", "application-version", "platform-version" (or "os-version"), "user-file-name" in order to align both of them and to take the features of one and make them available in the other. I'll be glad to write up the new JDF FileSpec attributes (if the CIP4 Capabilities WG likes the proposed semantics) and update the IPP Document object spec (if the PWG Semantic Model WG likes the proposed semantics). Comments? Thanks, Tom From imcdonald at sharplabs.com Wed Jan 22 16:44:06 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:29 2009 Subject: SM> Adding 4 more member attributes to "document-format-detai l" (coll ection) attribute Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE8F@mailsrvnt02.enet.sharplabs.com> Hi Tom, There's some confusion in your proposal below. The current "document-format-detail" member attribute "platform" and the proposed additional member attribute "platform-version" (or "os-version") are likely to be redundant. The only standardized source of values for all these attributes is the IANA registry of operating system names - it contains BOTH OS and version as a single string (e.g., "WINDOWS-95") and generally does NOT contain the simple name (e.g., there is no registered "WINDOWS" operating system). See: ftp://ftp.iana.org/assignments/operating-system-names In the IPP Driver Installation spec we have a single attribute "os-type" (with the values normalized to lowercase for IPP). See: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-install-04.txt Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, January 21, 2003 8:06 PM To: sm@pwg.org Cc: ipp@ipp.org Subject: SM> Adding 4 more member attributes to "document-format-detail" (coll ection) attribute PWG Semantic Model folks (and IPP WG folks), This is a similar mail message that I've send to the CIP4 JDF Capabilities WG. The IPP Document object spec has a "document-format-detail" (collection) attribute which contains member attributes that give more information about a document, such as "document-format-version", "document-format-natural-language", "platform", "device-id", and a recursive "document-format-details" (collection) to describe the unique Parts of an application/zip or multipart/related file. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf The IPP "document-format-details" (collection) attribute is much like the FileSpec resource in JDF. So I've downloaded a comparison of the IPP document format attributes including the proposed "document-format-detail" (collection) attribute and the JDF/1.1 FileSpec resource. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentParts. and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application", "application-version", "platform-version" (or "os-version"), "user-file-name" in order to align both of them and to take the features of one and make them available in the other. I'll be glad to write up the new JDF FileSpec attributes (if the CIP4 Capabilities WG likes the proposed semantics) and update the IPP Document object spec (if the PWG Semantic Model WG likes the proposed semantics). Comments? Thanks, Tom From hastings at cp10.es.xerox.com Wed Jan 22 21:20:34 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> Adding 4 more member attributes to "document-format-detai l" (coll ection) attribute Message-ID: For the Semantic Model face to face on Thursday: Ira and I talked today and we propose the following tweaks to the IPP and JDF proposals: 1. Don't use the term "platform" in the attribute name, use "os" or "operating-system (OS or OperatingSystem in JDF). The term "platform" often means the middleware. What we want here is the operating system. Also the IANA Registry is called Operating System Names. See: http://www.iana.org/assignments/operating-system-names 2. The IANA Registry has token strings without spaces that include the base operating system name and the version. Examples are: 'linux', 'linux-2.2', 'os/2', 'mac', 'mac-x', 'sun-os-4.0', 'unix', 'unix-bsd', 'win32', 'windows-95', 'windows-98', 'windows-ce', 'windows-nt', 'windows-nt-4', 'windows-nt-5', 'windows-2000', and 'unknown'. However, it is useful for software to determine the base operating system independent of the version and to also determine the version. To get both, it is simpler to have two attributes. We also propose that the second attribute (the one that includes the version), be the complete IANA registry entry, rather than just the version and be named: "os-name-and-version". Applications can then choose which attribute to match on and no parsing is needed. I've downloaded an updated proposal for IPP and JDF which in summary is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentPart. and clarify that and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application-name", "application-name-and-version", "os-name-and-version", and "user-file-name" in order to align both of them and to take the features of one and make them available in the other. Comments? Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, January 22, 2003 13:44 To: 'Hastings, Tom N'; sm@pwg.org Cc: ipp@ipp.org Subject: RE: SM> Adding 4 more member attributes to "document-format-detai l" (coll ection) attribute Hi Tom, There's some confusion in your proposal below. The current "document-format-detail" member attribute "platform" and the proposed additional member attribute "platform-version" (or "os-version") are likely to be redundant. The only standardized source of values for all these attributes is the IANA registry of operating system names - it contains BOTH OS and version as a single string (e.g., "WINDOWS-95") and generally does NOT contain the simple name (e.g., there is no registered "WINDOWS" operating system). See: ftp://ftp.iana.org/assignments/operating-system-names In the IPP Driver Installation spec we have a single attribute "os-type" (with the values normalized to lowercase for IPP). See: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-install-04.txt Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, January 21, 2003 8:06 PM To: sm@pwg.org Cc: ipp@ipp.org Subject: SM> Adding 4 more member attributes to "document-format-detail" (coll ection) attribute PWG Semantic Model folks (and IPP WG folks), This is a similar mail message that I've send to the CIP4 JDF Capabilities WG. The IPP Document object spec has a "document-format-detail" (collection) attribute which contains member attributes that give more information about a document, such as "document-format-version", "document-format-natural-language", "platform", "device-id", and a recursive "document-format-details" (collection) to describe the unique Parts of an application/zip or multipart/related file. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf The IPP "document-format-details" (collection) attribute is much like the FileSpec resource in JDF. So I've downloaded a comparison of the IPP document format attributes including the proposed "document-format-detail" (collection) attribute and the JDF/1.1 FileSpec resource. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentParts. and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application", "application-version", "platform-version" (or "os-version"), "user-file-name" in order to align both of them and to take the features of one and make them available in the other. I'll be glad to write up the new JDF FileSpec attributes (if the CIP4 Capabilities WG likes the proposed semantics) and update the IPP Document object spec (if the PWG Semantic Model WG likes the proposed semantics). Comments? Thanks, Tom From hastings at cp10.es.xerox.com Thu Jan 23 00:33:28 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:29 2009 Subject: SM> FW: PWG-IPP> Last Call Comments on IPP "-actual" Attributes Docum ent Message-ID: For the Semantic Model Team meeting on Thursday. Ron, Do you have a document the covers "ISTO requirements"? Harry had said a while ago that the ISTO was working on a revised template and/or requirements. Has any progress been made on that? Ira, Dennis, and I thought that it would be better to have the Abstract and names of the authors on the first page, in case the ISTO is accepting suggestions on their format. Tom -----Original Message----- From: Ron.Bergman@hitachi-ps.us [mailto:Ron.Bergman@hitachi-ps.us] Sent: Wednesday, January 22, 2003 15:37 To: pwg-ipp@pwg.org Subject: PWG-IPP> Last Call Comments on IPP "-actual" Attributes Document Technically the document looks very sound. The following comments are primarily editorial. 1. RFC 2565 and 2566 are obsolete. It is not appropriate to reference obsolete documents, especially as a normative reference. See Line 146 (in section 1 Introduction) Line 228 (in section 3 -actual attributes) Line 331 - 336 (in section 7.1 Normative References 2. In lines 151 & 152 recommend changing "(or are going to print)" to "(or are expected to be printed)" to be more consistent with the example in section 3.3. 3. In line 239 remove "that has the" and all of the text in the following line. This additional text adds nothing and results in a sentence that is very difficult to read. 4. In lines 279 and 280 there is a strange split (by WORD) of the string "-attribute". 5. The formatting of the document is not per ISTO requirements. Specifically page numbering and headers. Is there a procedure for format review prior to final publication? I propose that this needs to be established. Ron Bergman Hitachi Printing Solutions From imcdonald at sharplabs.com Sat Jan 25 19:59:04 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:29 2009 Subject: SM> draft-mcdonald-cip4-jdf-mime-00.txt (25 Jan 2003) Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE99@mailsrvnt02.enet.sharplabs.com> Copies: PWG Semantic Model FSG Job Ticket Tom Hastings Ira McDonald Hi folks, Saturday (25 January 2003) I've just sent 'The MIME application/vnd.cip4-jdf+xml Content-Type' to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions' in the files: - IETF-style plaintext - HTML w/ live TOC - PDF w/ live TOC Cheers, - Ira McDonald (editor of IANA Charset MIB) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ Copies: Internet Drafts Editor Tom Hastings Ira McDonald I-D Editor, Saturday (25 January 2003) Please place this document in the Internet-Drafts repository named: Abstract The International Cooperation for the Integration of Processes in Prepress, Press, and Postpress (CIP4) is an international worldwide standards body located in Switzerland. The purpose of CIP4 is to encourage computer based integration of all processes that have to be considered in the graphic arts industry. CIP4 has defined two document formats that are encoded in W3C Extensible Markup Language (XML): (1) CIP4 Job Definition Format (JDF) - an open standard for integration of all computer aided business and production processes around print media; (2) CIP4 Job Messaging Format (JMF) - an open standard for job messaging using Hyper Text Transport Protocol/1.1 (HTTP/1.1, RFC2616) that defines Query, Command, Response, Acknowledge, and Signal message families. This document defines two new MIME sub-types for IANA registration: (1) 'application/vnd.cip4-jdf+xml' for CIP4 Job Definition Format; (2) 'application/vnd.cip4-jmf+xml' for CIP4 Job Messaging Format. Thanks very much, - Ira McDonald (co-editor) High North Inc imcdonald@sharplabs.com From harryl at us.ibm.com Tue Jan 28 17:15:52 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:29 2009 Subject: SM> D.C. Friday schedule Message-ID: In D.C. , Semantic Model is on Friday. We should plan ahead when we plan to end the meeting. Most meetings go until 5pm but some end at 3pm on Friday so people can catch flights. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030128/d1e69e1b/attachment.html From harryl at us.ibm.com Wed Jan 29 00:09:13 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:30 2009 Subject: SM> Updated Process Message-ID: In prep for a discussion during the SM call, tomorrow, I've updated the PWG process document. ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.doc This is a one-time notification to both reflectors. Further on-line discussion of the PWG process with occur ONLY on pwg@pwg.org ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030128/04779ac9/attachment.html From imcdonald at sharplabs.com Wed Jan 29 13:59:55 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:30 2009 Subject: SM> [PDF of] Updated Process Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE9C@mailsrvnt02.enet.sharplabs.com> Hi folks, I ran the PWG process document through Acrobat Distiller to make a PDF version for those who don't have MS Word or Star Office installed: ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, January 28, 2003 11:09 PM To: pwg@pwg.org Cc: sm@pwg.org Subject: SM> Updated Process In prep for a discussion during the SM call, tomorrow, I've updated the PWG process document. ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.doc This is a one-time notification to both reflectors. Further on-line discussion of the PWG process with occur ONLY on pwg@pwg.org ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From hastings at cp10.es.xerox.com Wed Jan 29 17:19:11 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Strawman for a PWG IEEE-ISTO Template for PWG Proposed Standards Message-ID: In case there is time at the end of the SM telecon tomorrow, Thursday, Jan 30, 1-2 PM EST (10-11 PST) after we discuss the PWG Process, here is a Strawman for a PWG IEEE-ISTO Template for PWG Proposed Standards. This is a one-time notification to both reflectors. Further on-line discussion of the PWG Template with occur ONLY on pwg@pwg.org, NOT on the sm@pwg.org (same as for any other PWG process discussion). Dennis Carney, Ira McDonald, Ron Bergman, and I have been working on an MS-WORD template for PWG IEEE-ISTO standards for use by all the PWG WGs doing IEEE-ISTO standards. Here is version 0.2 as a strawman. ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-lates t.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-lates t.doc ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf Ira and I made some simplifications in it as part of making version 0.2 over the IEEE-ISTO style as documents below in Appendix C which also described why we made each change. Ira and I haven't had a chance to talk to anyone else about many of these simplifications. ISSUE: So an imporant issue is whether these simplifications are OK or do we need to rigorously follow the IEEE-ISTO standard style? The rest of version 0.2 is incorporating the detailed commens that Dennis Carney had made as a result of trying to use a template while he wrote up his "-actuals" IPP specification. There is a companion document: "Tips for Good Technical Writing" which I moved from the Appendix to a separate document available at: ftp://ftp.pwg.org/pub/pwg/general/templates/good-writing-tips-latest.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/good-writing-tips-latest.doc ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf Please send comments. Thanks, Tom Appendix C Differences between this Template and the IEEE-ISTO standard style This Appendix lists the differences between this Template and the IEEE/ISTO standard style and explains why. The IEEE-ISTO standard style is represented in the IEEE/ISTO 5101.1 Media Name Standard. These differences have evolved after experience using the IEEE/ISTO standard style for online viewing and printing with Adobe Acrobat. The differences are (working top to bottom): 1. Merged the redundant second page (which had the Abstract) onto the first page and got rid of the second page. Our understanding is that having two title pages comes from publishing the document in printed form, where the first page is like a cover. Most standards bodies have eliminated the cover so that the Abstract appears on the first page. 2. Added "(PWG)" after "The Printer Working Group" in the title. 3. Removed the redundant indications of whether this version is a Working Draft, a Proposed Standard, a Draft Standard, or a Standard from the Header. Only the title indicates the status. A Working Draft has: "Working Draft for a PWG Proposed Standard". A Proposed Standard after passing WG Last Call will have: "PWG Proposed Standard". A Draft Standard after passing WG Last Call will have: "PWG Draft Standard". A Standard after passing PWG Last Call will have: "PWG Standard" 4. Added the URL for the document on the first page, so that it is easy to find. 5. Added Editor's name(s) to the first page, so that proper credit is given as is common in some standards bodies. 6. Simplified the headers and footers, so that the headers are all the same except for the first page. Keeping the headers and footers simple will reduce errors in producing drafts and allow editor's to focus on content more and format less. 7. The Left side of the Header is blank for Working Drafts, then gets IEEE-ISTO 51nn.n after the Working Draft passes WG Last Call. Thus the editor only changes the Header once, when the specification passes Last Call. 8. In the Header, the Title is centered with most of the fixed parts removed. 9. In the Header, the page number is always on the right. The IEEE-ISTO format did not have the page number on the top at all, which has proved a problem when viewing the specification with Adobe Acrobat, when the user can only see part of the page at one time. Also scrolling upwards and downwards needs the page numbers to be at the top and bottom. 10. The Footer follows the IEEE-ISTO style, except the page number is always centered, instead of alternating left and right. This makes it easier to spot the page number when viewing it on the screen. 11. Page numbers in the Header and Footer, start at 1 with the first page. No Roman numerals are used. This makes it easier to relate pages as numbered by Adobe Acrobat and those printing on each page and in the Table of Contents. Also when printing out selected pages, the page number used by the Printer driver agree with the printed page numbers. 12. Defined the Body Text style to use ragged right, rather than justified, in order to make the document more readable by people when printed or displayed though it may not look as pretty. 13. Added editor names for PWG standards in the References section, as is practice in some standards bodies and most technical publications. 14. Removed the first initials from references and used only family names as is becoming practice to avoid the cultural confusion about whether family names come first or last. Here is the change log: Changes to make version 0.2, January 27, 2003 The following changes were made to create version 0.2, January 27, 2003 after careful review by Dennis Carney and Ira McDonald: 1. Generalized the template so that it can be for any PWG standard, not just IPP. 2. Simplified the template so that as few fields as possible have to be updated as the specification progresses through the process - otherwise everyone does it differently. 3. Follow the IEEE-ISTO style with the exceptions listed in Appendix C derived from experience viewing and printing on-line versions using Adobe Acrobat. 4. Explained the file naming scheme for PWG WGs. 5. Added the requirements for a Logical Diagram and a Configuration Diagrams and showed some IPP examples. 6. Highlighted IPP specific instructions and examples in green, like this, in order to give real examples, but make the Template work for all PWG Working Groups 7. Added RFC 3380, 3381, 3382. 8. Added a number of terms that may be useful to PWG projects other than IPP. 9. Moved the Appendix "Tips for Good Technical Writing" to a separate document available at: ftp://ftp.pwg.org/pub/pwg/general/templates/good-writing-tips-latest.pdf From hastings at cp10.es.xerox.com Thu Jan 30 13:06:49 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: FW: PWG> RE: SM> Updated Process [my comments] Message-ID: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Thursday, January 30, 2003 03:03 To: pwg@pwg.org Subject: PWG> RE: SM> Updated Process [my comments] Harry, Here are my comments: 1. Section 3.3 PWG Proposed Standard and elsewhere: I like your proposed change of terminology from "PWG Working Draft" to "PWG Working Material" for the successive versions of a specification that lead up to a Last Call and a PWG Proposed Standard.. The term "PWG Working Material" can't be confused with the second stage of a PWG standard: a "PWG Draft Standard". I assume that any PWG project that also produces other forms of output in addition to a specification, such as a schema is part of the PWG Proposed Standard, not a separate Standard, right? Also this means that any Schema has to have an accompanying specification. No schemas by themselves. 1a. There are a number of places where the old term "Working Draft" still exists, including Process Summary and Figure in Section 9. All occurrences of "Working Draft" need to be changed to "Working Material". 2. Section 3.5 PWG Staandard and elsewhere: Ira and I would like to propose putting some adjective in front of Standard for the final stage, such as "Final". So instead of having: PWG Proposed Standard PWG Draft Standard PWG Standard, we have: PWG Proposed Standard PWG Draft Standard PWG Final Standard Then the term Standard by itself can be used to discuss any of PWG Proposed Standard, PWG Draft Standard, or PWG Final Standard, rather than being ambiguous as to whether "Standard" means all three or just the last one. 3. Sections 3.3 PWG Proposed Standard, 3.4 PWG Draft Standard, and 3.5 [Final] Standard The comparison with the corresonding IETF standards is very similar as follows: 3.3: PWG Working Material is equivalent to an IETF Internet Draft. A PWG Proposed Standard is equivalent to an IETF Proposed Standard. 3.4: A PWG Draft Standard is equivalent to an IETF Draft Standard. 3.5: A PWG [Final] Standard is equivalent to an IETF Standard. These statements should be made in parallel fashion in sections 3.3, 3.4, and 3.5, preferably in separate paragraphs, so that they aren't mixed in with our descriptions. Or put them together into a separate section, like the deleted section 3.6. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, January 28, 2003 21:09 To: pwg@pwg.org Cc: sm@pwg.org Subject: SM> Updated Process In prep for a discussion during the SM call, tomorrow, I've updated the PWG process document. ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.doc This is a one-time notification to both reflectors. Further on-line discussion of the PWG process with occur ONLY on pwg@pwg.org ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030130/339d7aef/attachment.html From PZehler at crt.xerox.com Tue Feb 4 07:25:27 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Semantic Model teleconference & PWG Process discussion Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. The teleconference is one hour long. It will be run using both phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is 1) Adjust agenda 2) Overview (and short discussion) of Schema changes to replace union scheme representing type 2&3 keyword enumerations. (See below) 3) Continue PWG process discussion from last week. Updated document will be sent out by Wednesday. (objective: closure) 4) Next steps Pete All, 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 __________________________________________________________ webex info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: pwg-sm Date: 2/6/2003 Time: 10:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 23689380 Meeting Password: tempsm __________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# __________________________________________________________ Schema change Info: Old: New: CompressionWKV KeywordNsExtensionPattern (Note: appinfo may also include namespace: ) Supporting enumeration and pattern: __________________________________________________________ From PZehler at crt.xerox.com Tue Feb 4 14:34:13 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Semantic Model meeting minutes Message-ID: All, The meeting minutes for the Semantic Model meeting are available at: ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Minutes/PWG-SM-030123.pdf An updated Semantic Model and Schema will be posted next week. 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 From dhall at hp.com Thu Feb 6 11:26:25 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:30 2009 Subject: SM> Interface / Document revisioning Working Draft Message-ID: <77261E830267D411BD4D00902740AC250DB4C7A9@xvan01.vcd.hp.com> Hey All.. Attached are the notes from Tuesdays PSI meeting.. I apologize for the late publication, but I've been absolutely swamped since Tuesday! Keep in mind that this is a work in progress... Dave <> -------------- next part -------------- A non-text attachment was scrubbed... Name: Spec Stuff.doc Type: application/msword Size: 47104 bytes Desc: not available Url : http://www.pwg.org/archives/sm/attachments/20030206/fe94638c/SpecStuff.doc From PZehler at crt.xerox.com Tue Feb 11 12:51:29 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. The teleconference is one hour long. Hopefully it will be run using both phone and Webex. Information for the phone is included below. Since the Webex information has been rather fluid lately I hope someone from HP (Bob Taylor?) can provide Webex. The agenda for the Semantic Model teleconference is 1) Adjust agenda 2) Discuss Semantic Model document focusing on recent edits (updated version with revision mark will be sent out tomorrow) 3) Next steps Pete All, 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 __________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# Date: 2/13/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) __________________________________________________________ From PZehler at crt.xerox.com Wed Feb 12 13:07:43 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Latest Semantic Model available Message-ID: All, The latest version of the Semantic Model document is available at . This is version 0.20 of the document and is dated February 13, 2003. This document will be used during this weeks teleconference. As always red-lined versions and .docs are available at the following URLs 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 From dhall at hp.com Wed Feb 12 18:10:07 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:30 2009 Subject: SM> Interface / Document revisioning Working Draft Message-ID: <77261E830267D411BD4D00902740AC250DB4C84C@xvan01.vcd.hp.com> One reason that I can think of is that I think of the version as part of the namespace, and the "foo" to be the interface name. / Hence http://www.pwg.org/ps/2003/02/12/JobControlInterface The flip side of the argument is that the namespace is: http://www.pwg.org/ps, and the interface is JobControlInterface/2003/02/12 Giving us: // I'm not sure what the right answer is.. Dave -----Original Message----- From: TAYLOR,BOB (HP-Vancouver,ex1) Sent: Wednesday, February 12, 2003 1:35 PM To: HALL,DAVID (HP-Vancouver,ex1); 'sm@pwg.org'; 'pwg@pwg.org' Subject: RE: SM> Interface / Document revisioning Working Draft Hi all, One question on this since I missed last week's meeting. When we're actually declaring namespaces, the recommendation appeared to be of the style: http://msdn.microsoft.com/2002/04/foo We are right now doing the following: http://msdn.microsoft.com/foo/2002/04/ I.e., pretty much the same model, but put the version/date after the service declaration rather than in the middle of it. I think this makes more sense - was there a specific reason to put the version/date in the middle instead of on the end? bt > -----Original Message----- > From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] > Sent: Thursday, February 06, 2003 8:26 AM > To: 'sm@pwg.org'; 'pwg@pwg.org' > Subject: SM> Interface / Document revisioning Working Draft > > > Hey All.. > > Attached are the notes from Tuesdays PSI meeting.. I > apologize for the late > publication, but I've been absolutely swamped since Tuesday! > > Keep in mind that this is a work in progress... > > Dave > > <> > From PZehler at crt.xerox.com Thu Feb 20 07:31:31 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> No Semantic Teleconference today Message-ID: All, Without any outstanding SM issues or requests for time, there was no agenda and so, no meeting. 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 From PZehler at crt.xerox.com Fri Feb 21 11:02:22 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Latest PWG Schemas (v0.92) available Message-ID: All, The latest PWG schemas have been updated. See "Semantic Model Schema: Latest Version" under "Documents" on the Semantic Model Web page "http://www.pwg.org/sm/index.html" for links to all the schemas. The schema files are all stored under "http://www.pwg.org/schemas/sm/latest/". The schemas do not have the latest version of "DocumentFormatDetails" or "StatusStrings". Other things not included are "CharacterRepertoireSupported" and the color&imaging extensions. Please forward any comments to me and the Semantic Model mailing list. 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 From PZehler at crt.xerox.com Wed Feb 26 09:29:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> No Semantic Teleconference this week Message-ID: > All, > The latest schema has been published. The Semantic Model is waiting on > the Document Object specification before its final edit prior to the start > of Last Call. If we need to have a teleconference for any reason please > let me know. > 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 > From hastings at cp10.es.xerox.com Fri Mar 14 20:59:37 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions Message-ID: We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From PZehler at crt.xerox.com Mon Mar 17 13:17:21 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> PWG Semantic Model Teleconference Information 3/20 Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference will be dedicated to the Document Object > > The teleconference is one hour long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > > The agenda for the Semantic Model teleconference is : > > 1) Adjust agenda > 2) Walk through Document Object Specification Tom Hastings will send out link to specification under separate cover 3) Check out the latest changes to the Semantic Model Specification We will use the version with revision marks. > ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20030317.pdf ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20030317-rev.pdf > 3) Next Steps > > > Pete > All, > > > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 3/20/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) > ___________________________________________________ > > From dhall at hp.com Mon Mar 17 13:55:23 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:30 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABA1@xvan01.vcd.hp.com> Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From hastings at cp10.es.xerox.com Mon Mar 17 19:12:08 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> IPP Document object specification, March 14 2003 version, is avai lable for SM 3/20 telecon Message-ID: I've stored the 14 March 2003 version of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.doc The rest of the email message contains the 18 issues followed by the change log summary. The 14 March 2003 version contains the agreements reached at the last PWG face to face meeting in Maui and on subsequent SM telecons and email threads. This version also aligns with the 17 March 2003 version of the Semantic Model that Pete just posted. The issues will be reviewed during the PWG Semantic Model telecon, Thursday, March 20. There are 18 issues, mostly minor or just making sure you approve of the specific updates. However, issue #9 is significant. Here are the issues that are also embedded in the document: ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? ISSUE 06: OK that "document-container-summary" is only one level deep? ISSUE 07: Is the description of "document-container-summary" attribute OK? ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. Here is the Change Log: Version 0.7, 14 March 2003, agreements from the Maui January PWG meeting and subsequent telecons: 1. Fixed up the file naming and numbering to agree with the latest PWG process agreements. 2. Updated the Abstract and Introduction to reflect the additions. 3. Fixed cross references to use the standard numbers as agreed, rather than mnemonic references. 4. Deprecated the "input-document-number" operation attribute ([pwg5100.4] section 9.2.1 in the Create-Document Requests 5. Renamed Send-Data to Send-Document-Data to more clearly reflect the scope of the operation. 6. Added the REQUIRED Close-Job operation to close a job that contains Document objects. Using "last-document" still works too and the Printer MUST support both ways. 7. Retained the idea that the Printer MUST NOT copy down any attributes supplied in the Job Creation operation to the Document object as observable in Document object query responses. Document objects inherit that effect from the Job object. 8. Added the following operation and Document Description attributes: document-container-summary (collection), document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127). The "document-container-summary" collection attribute may contain them, plus "document-format" and "document-natural-language". 9. REQUIRED Printers to support "document-format-version" Document Description. 10. Deprecated "document-overrides" and indicated that the agreement is to re-issue [pwg5100.4] without "document-overrides". 11. Prefixed the following three Document Description attributes that are copies of Job Description attributes with "document-" so that no Document attribute has a "job-" prefix: "job-printer-uri" becomes "document-job-printer-uri", "job-uri" becomes "document-job-uri", and "job-id" becomes "document-job-id". 12. Added the encoding for the "document-attributes-tag" as 0x09. 13. Updated the IANA Registration section, but still needs more work. Send any comments to the SM mailing list. Thanks, Tom From PZehler at crt.xerox.com Tue Mar 18 09:51:47 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> My response to some of the 18 Document issues...Comments? Message-ID: All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From PZehler at crt.xerox.com Tue Mar 18 10:30:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: Dave, I was under the impression that the reason for defining DeviceId was to establish an unambiguous mapping of a Printer and its associated driver. IPP v1.0 and 1.1 used PrinterMakeAndModel. UPnP felt that that mapping was not sufficiently defined and ambiguous. The IEEE P1284 device registry was utilized with the definition of DeviceId. I believe that the DeviceId provides a more direct and convenient mapping to printer's device driver. It also includes the make and model in a well defined format. I recommend that we do not include PrinterMakeAndModel in the list below. 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: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 17, 2003 1:55 PM To: 'Hastings, Tom N' Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From imcdonald at sharplabs.com Tue Mar 18 10:52:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:30 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF39@mailsrvnt02.enet.sharplabs.com> Hi Pete, Agreed - specifically, Bob Taylor (HP strong voice for document details) has urged the use of DeviceID as the unambiguous identifier. Admittedly that's no help to actually find the driver install for human beings, but that's a separate problem, I think. Cheers, - Ira McDonald -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:31 AM To: 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Dave, I was under the impression that the reason for defining DeviceId was to establish an unambiguous mapping of a Printer and its associated driver. IPP v1.0 and 1.1 used PrinterMakeAndModel. UPnP felt that that mapping was not sufficiently defined and ambiguous. The IEEE P1284 device registry was utilized with the definition of DeviceId. I believe that the DeviceId provides a more direct and convenient mapping to printer's device driver. It also includes the make and model in a well defined format. I recommend that we do not include PrinterMakeAndModel in the list below. 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: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 17, 2003 1:55 PM To: 'Hastings, Tom N' Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From AMcCarthy at crt.xerox.com Tue Mar 18 13:09:13 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:30 2009 Subject: SM> My response to some of the 18 Document issues...Comments? Message-ID: All, WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:52 AM To: Hastings, Tom N; sm@pwg.org Subject: SM> My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Tue Mar 18 14:09:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> IPP Document object specification, March 14 2003 version, is avai lable for SM 3/20 telecon [much smaller zips] Message-ID: For some reason the sizes of the clean version of the .PDF file is huge (3 Mb) while the revision marked .pdf was much smaller. And of course the .doc files are always huge. However, zipping all of them separately helped a lot. Those who have to down load over a phone line this savings is significant. So I've down loaded individual .zip files for each of the four flavors: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-pdf.zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-doc.zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev-pdf.zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev-doc.zip .pdf .doc -rev.pdf -rev.doc which are: 1152KB, 290KB, 694KB, and 307KB, respectively, compared to: 2786KB, 1925KB, 865KB, and 2007KB, respectively. ratio: 59%, 85%, 85%, 20%, respectively Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 17, 2003 16:12 To: sm@pwg.org Subject: SM> IPP Document object specification, March 14 2003 version, is available for SM 3/20 telecon I've stored the 14 March 2003 version of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.doc The rest of the email message contains the 18 issues followed by the change log summary. The 14 March 2003 version contains the agreements reached at the last PWG face to face meeting in Maui and on subsequent SM telecons and email threads. This version also aligns with the 17 March 2003 version of the Semantic Model that Pete just posted. The issues will be reviewed during the PWG Semantic Model telecon, Thursday, March 20. There are 18 issues, mostly minor or just making sure you approve of the specific updates. However, issue #9 is significant. Here are the issues that are also embedded in the document: ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? ISSUE 06: OK that "document-container-summary" is only one level deep? ISSUE 07: Is the description of "document-container-summary" attribute OK? ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. Here is the Change Log: Version 0.7, 14 March 2003, agreements from the Maui January PWG meeting and subsequent telecons: 1. Fixed up the file naming and numbering to agree with the latest PWG process agreements. 2. Updated the Abstract and Introduction to reflect the additions. 3. Fixed cross references to use the standard numbers as agreed, rather than mnemonic references. 4. Deprecated the "input-document-number" operation attribute ([pwg5100.4] section 9.2.1 in the Create-Document Requests 5. Renamed Send-Data to Send-Document-Data to more clearly reflect the scope of the operation. 6. Added the REQUIRED Close-Job operation to close a job that contains Document objects. Using "last-document" still works too and the Printer MUST support both ways. 7. Retained the idea that the Printer MUST NOT copy down any attributes supplied in the Job Creation operation to the Document object as observable in Document object query responses. Document objects inherit that effect from the Job object. 8. Added the following operation and Document Description attributes: document-container-summary (collection), document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127). The "document-container-summary" collection attribute may contain them, plus "document-format" and "document-natural-language". 9. REQUIRED Printers to support "document-format-version" Document Description. 10. Deprecated "document-overrides" and indicated that the agreement is to re-issue [pwg5100.4] without "document-overrides". 11. Prefixed the following three Document Description attributes that are copies of Job Description attributes with "document-" so that no Document attribute has a "job-" prefix: "job-printer-uri" becomes "document-job-printer-uri", "job-uri" becomes "document-job-uri", and "job-id" becomes "document-job-id". 12. Added the encoding for the "document-attributes-tag" as 0x09. 13. Updated the IANA Registration section, but still needs more work. Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Tue Mar 18 14:33:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> RE: My response to some of the 18 Document issues...Comments? [IS SUE 03 "job-mandatory-attributes" = REQUIRED] Message-ID: I agree with Peter's suggested resolutions to ISSUE 03, but need to test our understanding of the terminology, since I think that the spec needs to say that "job-mandatory-attributes" is a REQUIRED attribute in the Document Object spec, not OPTIONAL, in order to agree with Peter's suggestion. Peter wrote: ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. When we say anything is "REQUIRED" in the Document Object spec, we mean it is REQUIRED if the Printer conforms to the Document Object specification, i.e., supports the Document Object. [This semantic for the word REQUIRED is true for any IPP extension specification]. Here is what the Document Object spec says in the Conformance Terminology section to try to make the scope of the term "REQUIRED" clear: 2.1 Conformance Terminology Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance as defined in RFC 2119 [rfc2119] and [rfc2911] section 12.1. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they do not. These terms define conformance to this document (and [rfc2911]) only; they do not affect conformance to other documents, unless explicitly stated otherwise. To be more specific: REQUIRED - an adjective used to indicate that a conforming IPP Printer implementation MUST support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. See [rfc2911] "Appendix A - Terminology for a definition of "support". Since support of this entire Document Object specification is OPTIONAL for conformance to IPP/1.1, the use of the term REQUIRED in this document means "REQUIRED if this OPTIONAL Document Object specification is implemented". RECOMMENDED - an adjective used to indicate that a conforming IPP Printer implementation is recommended to support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. Since support of this entire Document Object specification is OPTIONAL for conformance to IPP/1.1, the use of the term RECOMMENDED in this document means "RECOMMENDED if this OPTIONAL Document Object specification is implemented". OPTIONAL - an adjective used to indicate that a conforming IPP Printer implementation MAY, but is NOT REQUIRED to, support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. It has been suggested (and I put in the proposed PWG Template) that it is not good to repeat the definitions of terms that appear in other specifications, since the definition may inadvertantly be changed. Also we don't need to use the term "NEED NOT" which [rfc2911] introduces and explains in section 12.1. So I'll recast the 5 uses of NEED NOT to be MAY in the next version. So how about this much shorter explanation for the Document Object section 2.1 Conformance Terminology: Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, and OPTIONAL, have special meaning relating to conformance as defined in RFC 2119 [rfc2119]. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they do not. These terms define conformance to this document (and [rfc2911]) only; they do not affect conformance to other documents, unless explicitly stated otherwise. For example, the term REQUIRED in this document means "REQUIRED if this OPTIONAL Document Object specification is implemented". Comments? Tom -----Original Message----- From: Zehler, Peter Sent: Tuesday, March 18, 2003 06:52 To: Hastings, Tom N; sm@pwg.org Subject: My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Tue Mar 18 14:58:14 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: Here is the definition of the "document-format-device-id" proposed in the Document object spec: This OPTIONAL Document Description attribute identifies the type of device for which the document was formatted, including manufacturer and model. This attribute is intended to identify document formats that are not portable, e.g., PDLs that are device dependent. The value of this variable MUST exactly match the IEEE 1284-2000 Device ID string (see [IEEE1284] clause 6), except the length field MUST not be specified. See the Microsoft Universal Plug and Play [upnp] section 2.2.6 DeviceId parameter for details and examples. Here is an example showing only the required fields for a PostScript document: MANUFACTURER:ACME Co.;COMMAND SET:PS;MODEL:LaserBeam 9; And here is the definition of the UPnP DeviceId attribute from the UPnP v1 Printer Template. Note: in UPnP this is a Printer attribute, not an attribute that the submitter includes with his job submission: 2.6.6 DeviceId The value of this variable MUST exactly match the IEEE 1284-2000 Device ID string, except the length field MUST not be specified.. The value is assigned by the Printer vendor and MUST NOT be localized by the Print Service. The IEEE 1284-2000 Device ID is a length field followed by a case-sensitive string of ASCII characters defining peripheral characteristics and/or capabilities. For the purposes of this specification, the length bytes MUST NOT be included. The Device ID sequence is composed of a series of keys and values of the form: key: value {,value} repeated for each key As indicated, each key will have one value, and MAY have more than one value. The minimum necessary keys (case-sensitive) are MANUFACTURER, COMMAND SET, and MODEL. (These keys MAY be abbreviated as MFG, CMD, and MDL respectively.) Each implementation MUST supply these three keys and possibly additional ones as well. Each key (and each value) is a string of characters. Any characters except colon (:), comma (,), and semi-colon (;) MAY be included as part of the key (or value) string. Any leading or trailing white space (SPACE[x'20'], TAB[x'09'], VTAB[x'0B'], CR[x'0D'], NL[x'0A'], or FF[x'0C']) in the string is ignored by the parsing program (but is still counted as part of the overall length of the sequence). An example ID String, showing optional comment and active command set keys and their associated values (the text is actually all on one line): MANUFACTURER:ACME Manufacturing; COMMAND SET:PCL,PJL,PS,XHTML-Print+xml; MODEL:LaserBeam 9; COMMENT:Anything you like; ACTIVE COMMAND SET:PCL; (See IEEE 1284-2000 clause 7.6) Note: One of the purposes of the DeviceId variable is to select a printer driver for those UCPs that need a printer driver. The values of the COMMAND SET key are interpreted by the printer driver provided by the vendor and so are vendor-defined, rather than being standardized. TH Observations: 1. The Note is part of the definition of the UPnP DeviceId Printer attribute showing the intent to relate to the driver needed. 2. Because the keyword fields also have shorter forms, the string: MFG:ACME Manufacturing;CMD:PCL,PJL,PS,XHTML-Print+xml;MDL:LaserBeam 9; is also conforming for the UPnP DeviceId Printer Attribute. 3. This alternate form for the keyword fields means that the Printer will either have to include both forms in its "document-format-device-id-supported" Printer attribute (if we decide to have one) or have a more sophisticated matching algorithm. 4. The UPnP DeviceId attribute is a Printer Attribute that describes the Printer's capabilities. Unlike the IPP "document-format-device-id", the UPnP DeviceId attribute is not submitted by the clent to tell the printer what the document format is that the client is submitting. 5. For our use as an attribute that the client submits as a value of "document-format-device-id", presumably there would only be one value of the COMMAND SET, e.g.,: MFG:ACME Manufacturing;CMD:PS;MDL:LaserBeam 9; Right? Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, March 18, 2003 07:53 To: 'Zehler, Peter'; 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Hi Pete, Agreed - specifically, Bob Taylor (HP strong voice for document details) has urged the use of DeviceID as the unambiguous identifier. Admittedly that's no help to actually find the driver install for human beings, but that's a separate problem, I think. Cheers, - Ira McDonald -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:31 AM To: 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Dave, I was under the impression that the reason for defining DeviceId was to establish an unambiguous mapping of a Printer and its associated driver. IPP v1.0 and 1.1 used PrinterMakeAndModel. UPnP felt that that mapping was not sufficiently defined and ambiguous. The IEEE P1284 device registry was utilized with the definition of DeviceId. I believe that the DeviceId provides a more direct and convenient mapping to printer's device driver. It also includes the make and model in a well defined format. I recommend that we do not include PrinterMakeAndModel in the list below. 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: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 17, 2003 1:55 PM To: 'Hastings, Tom N' Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From hastings at cp10.es.xerox.com Tue Mar 18 21:31:32 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> JDF FileSpec/@FileFormatVersion and IPP "document-format-version" for PDF/X and TIFF/IT Message-ID: I did a google search to find out what the ISO designation is for the PDF/X-1 and TIFF/IT ISO standards. We're trying to define which values should be used for JDF FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that we've collapsed FileFormatStandard into FileFormatVersion as suggested. Same question for IPP "document-format" (mimeMediaType) and "document-format-version" (text(127)) attributes, assuming that we've collapsed "document-format-standard" into "document-format-version" (text(127)) as suggested. This is what I found from google: 1. PDF/X: ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) So this sounds great to use the value of "ISO 15930-1:2001" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec instead of "PDF/X-1:2001". And the MimeType attribute value will be "application/pdf". ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish them in either the MimeType or FileFormatVersion attribute? 2. TIFF/IT: ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag image file format for image technology (TIFF/IT). So use the value "ISO 12639-1998" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec Since TIFF/IT doesn't yet have a MIME type registered, the JDF FileSpec/@MimeType attribute will be omitted and the IPP "document-format" attribute will be omitted, OK? Tom -----Original Message----- From: McCarthy, Ann L Sent: Tuesday, March 18, 2003 10:09 To: Zehler, Peter; Hastings, Tom N; sm@pwg.org Subject: RE: SM> My response to some of the 18 Document issues...Comments? All, WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:52 AM To: Hastings, Tom N; sm@pwg.org Subject: SM> My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From AMcCarthy at crt.xerox.com Wed Mar 19 10:19:10 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:30 2009 Subject: SM> RE: JDF FileSpec/@FileFormatVersion and IPP "document-format-vers ion" for PDF/X and TIFF/IT Message-ID: Tom, I am rethinking the recommendation to use the ISO standard name. When we established that idea originally we were dealing with media standards. Media measurement standards and other physical system standards can be designated by the ISO or other selected standard name. I now realize that file formats need to be treated differently. In the file format case - each file format standard itself specifies a conformance string value that must be used in the file to identify the specific standard to which the file conforms. JDF should use those same conformance identifier strings. So for PDF/X the conformance values are: PDF/X-1:2001 PDF/X-1a:2001 PDF/X-2:2001 PDF/X-3:2001 One of these string values will appear in the PDF/X key "GTS_PDFXVersion" (with the exception of PDF/X-1a:2001). If the PDF/X file is X-1a conforming then 'PDF/X-1:2001' will appear in the "GTS_PDFXVersion" key and the 'PDF/X-1a:2001' string will appear in the additional key "GTS_PDFXConformance". So X-1a pdf files are identified by a combination of these two keys within the pdf file. JDF should be able to use a single string. TIFF/IT files also have several possible conformance levels. TIFF/IT conformance strings (given in section 5 of ISO 12639) are: TIFF/IT TIFF/IT-CT TIFF/IT-LW TIFF/IT-HC TIFF/IT-MP TIFF/IT-BP TIFF/IT-BL TIFF/IT-P1 TIFF/IT-CT/P1 TIFF/IT-LW/P1 TIFF/IT-HC/P1 TIFF/IT-MP/P1 TIFF/IT-BP/P1 TIFF/IT-BL/P1 Each of these informs the reader of specific constraints or file interpretation requirements. We may be able to reduce the list of TIFF/IT strings if someone more familiar with the exchange of TIFF/IT can identify a case that never occurs. Absent that - JDF should duplicate the conformance level identifiers given in the ISO 12639 standard. My apologies for the back-and-forth on this. After looking at the file format standards I think that one consistent way of specifying all standards is less important than adhering to previously defined conformance identification methods when they are available. Best regards, Ann -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Hastings, Tom N Sent: Tuesday, March 18, 2003 9:32 PM To: McCarthy, Ann L; sm@pwg.org Cc: CIP4 Capabilities WG [capabilities@cip4.org]; Masinter, Larry at Adobe Subject: JDF FileSpec/@FileFormatVersion and IPP "document-format-version" for PDF/X and TIFF/IT I did a google search to find out what the ISO designation is for the PDF/X-1 and TIFF/IT ISO standards. We're trying to define which values should be used for JDF FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that we've collapsed FileFormatStandard into FileFormatVersion as suggested. Same question for IPP "document-format" (mimeMediaType) and "document-format-version" (text(127)) attributes, assuming that we've collapsed "document-format-standard" into "document-format-version" (text(127)) as suggested. This is what I found from google: 1. PDF/X: ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) So this sounds great to use the value of "ISO 15930-1:2001" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec instead of "PDF/X-1:2001". And the MimeType attribute value will be "application/pdf". ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish them in either the MimeType or FileFormatVersion attribute? 2. TIFF/IT: ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag image file format for image technology (TIFF/IT). So use the value "ISO 12639-1998" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec Since TIFF/IT doesn't yet have a MIME type registered, the JDF FileSpec/@MimeType attribute will be omitted and the IPP "document-format" attribute will be omitted, OK? Tom -----Original Message----- From: McCarthy, Ann L Sent: Tuesday, March 18, 2003 10:09 To: Zehler, Peter; Hastings, Tom N; sm@pwg.org Subject: RE: SM> My response to some of the 18 Document issues...Comments? All, WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:52 AM To: Hastings, Tom N; sm@pwg.org Subject: SM> My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Thu Mar 20 10:35:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> RE: JDF FileSpec/@FileFormatVersionand IPP "document-format-versi on"for PDF/X and TIFF/IT Message-ID: Here are some really good comments from Martin Bailey about a number of recent emails about the FileSpec proposal for JDF from Ann McCarthy, Bob Taylor, and myself. Martin, One thing I left out of the proposal by mistake was how to indicate which types of fonts: "Type 1" "TrueType" "OpenType" ... I think we should just add another attribut to FileSpec, say, FontType (string) that has meaning when FileClass = Font. I like yours and Ann's suggestion not to use the ISO standard designation ("ISO nnnn-part:year") when the ISO standard has a versioning mechanism specified as part of it, as does TIFF/IT and PDF/X (see below). Also I forgot to include DCS (Desktop Color Separation version 2). It doesn't have an ISO standard, right? Tom -----Original Message----- From: Martin Bailey [mailto:Martin.Bailey@globalgraphics.com] Sent: Thursday, March 20, 2003 03:03 To: hastings@cp10.es.xerox.com Subject: CIP4 Forum Capabilities: Re:JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Hi Tom Responses in-line. At 02:37 19/03/2003, Tom Hastings wrote: >I did a google search to find out what the ISO designation is for the >PDF/X-1 and TIFF/IT ISO standards. > >We're trying to define which values should be used for JDF >FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that >we've collapsed FileFormatStandard into FileFormatVersion as suggested. > >Same question for IPP "document-format" (mimeMediaType) and >"document-format-version" (text(127)) attributes, assuming that we've >collapsed "document-format-standard" into "document-format-version" >(text(127)) as suggested. > > >This is what I found from google: > >1. PDF/X: > >ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use >of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) > >So this sounds great to use the value of "ISO 15930-1:2001" for the value >of: > > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >instead of "PDF/X-1:2001". And the MimeType attribute value will be >"application/pdf". > >ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish >them in either the MimeType or FileFormatVersion attribute? I would go back to the suggestion that I originally made, which matches the strings that are used inside the file to uniquely identify the conformance level: "PDF/X-1a:2001", "PDF/X-3:2002", etc. At 19:02 19/03/2003, Tom Hastings wrote: >1. Should we also list in JDF the "PDF/X-1:1999" value as well? Its mention >in the 2001 ISO standard as an "older version". Given that the list we will include in the standard is, almost by definition, incomplete, no - I would not include that. It's an obsolete file format, defined in a standard that has been withdrawn. If somebody really wants to include it they could figure out from the other values in the list what the right string should be. >2. TIFF/IT: > >ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag >image file format for image technology (TIFF/IT). > >So use the value "ISO 12639-1998" for the value of: That would be "ISO 12639:1998", colon rather than hyphen. > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >Since TIFF/IT doesn't yet have a MIME type registered, the JDF >FileSpec/@MimeType attribute will be omitted and the IPP "document-format" >attribute will be omitted, OK? OK, but how do you plan to distinguish between the sub-file types (FP, CT, LW, HC) and between baseline TIFF/IT and TIFF/IT-P1? Those are important questions when it comes to capabilities reporting because many tools will only read P1, and not baseline, and many can't read all of the sub-file types. I made some suggestions for those in my original mail. At 15:27 19/03/2003, Ann McCarthy wrote: >TIFF/IT files also have several possible conformance levels. >TIFF/IT conformance strings (given in section 5 of ISO 12639) >are: >TIFF/IT >TIFF/IT-CT >TIFF/IT-LW >TIFF/IT-HC >TIFF/IT-MP >TIFF/IT-BP >TIFF/IT-BL >TIFF/IT-P1 >TIFF/IT-CT/P1 >TIFF/IT-LW/P1 >TIFF/IT-HC/P1 >TIFF/IT-MP/P1 >TIFF/IT-BP/P1 >TIFF/IT-BL/P1 > >Each of these informs the reader of specific constraints or file >interpretation requirements. > >We may be able to reduce the list of TIFF/IT strings if someone >more familiar with the exchange of TIFF/IT can identify a case >that never occurs. Absent that - JDF should duplicate the >conformance level identifiers given in the ISO 12639 standard. Ann's suggested list is almost what we need: - I'm not sure what "TIFF/IT" on its own means in that context - did you mean 'FP'? I know FP isn't normative in the 1998 standard (it is in the 2003 revision), but that doesn't stop people using it :-) - there's a 2003 revision of 12639 in ballot at the moment, so we need a date suffix on all of the above. In theory the P1 subset has not been changed in that revision (we tried not leave it unchanged, anyway), but I'd feel safer with a date suffix still, although that might complicate capabilities reporting somewhat. The revision also adds a new file subtype (SD), and a new conformance level (P2). The full list therefore gets a bit long: TIFF/IT-FP:1998 TIFF/IT-CT:1998 TIFF/IT-LW:1998 TIFF/IT-HC:1998 TIFF/IT-MP:1998 TIFF/IT-BP:1998 TIFF/IT-BL:1998 TIFF/IT-FP/P1:1998 TIFF/IT-CT/P1:1998 TIFF/IT-LW/P1:1998 TIFF/IT-HC/P1:1998 TIFF/IT-MP/P1:1998 TIFF/IT-BP/P1:1998 TIFF/IT-BL/P1:1998 TIFF/IT-FP:2003 TIFF/IT-CT:2003 TIFF/IT-LW:2003 TIFF/IT-HC:2003 TIFF/IT-MP:2003 TIFF/IT-BP:2003 TIFF/IT-BL:2003 TIFF/IT-SD:2003 TIFF/IT-FP/P1:2003 TIFF/IT-CT/P1:2003 TIFF/IT-LW/P1:2003 TIFF/IT-HC/P1:2003 TIFF/IT-MP/P1:2003 TIFF/IT-BP/P1:2003 TIFF/IT-BL/P1:2003 (no P1 conformance level of SD) TIFF/IT-FP/P2:2003 TIFF/IT-CT/P2:2003 TIFF/IT-LW/P2:2003 TIFF/IT-HC/P2:2003 TIFF/IT-MP/P2:2003 TIFF/IT-BP/P2:2003 TIFF/IT-BL/P2:2003 TIFF/IT-SD/P2:2003 But, as I commented above, the list in the spec can only be regarded as incomplete, so it might be better to explicitly make it a set of examples and include only some of these? At 07:32 19/03/2003, Bob Taylor wrote: > >I would think we'd just use the TIFF MIME type for these (application/TIFF >?). > No, because most TIFF/IT subfile types are not valid TIFF. Martin >Tom > > > >-----Original Message----- >From: McCarthy, Ann L >Sent: Tuesday, March 18, 2003 10:09 >To: Zehler, Peter; Hastings, Tom N; sm@pwg.org >Subject: RE: SM> My response to some of the 18 Document >issues...Comments? > > >All, > >WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. > >-------------------------------------------------------------------- >Ann L. McCarthy >XIG/SSTC Imaging Systems Architect >Internal:8*221-8701 External: 585-231-8701 >FAX: 585-265-8871 Mailcode: B128-30E > > >-----Original Message----- >From: Zehler, Peter [mailto:PZehler@crt.xerox.com] >Sent: Tuesday, March 18, 2003 9:52 AM >To: Hastings, Tom N; sm@pwg.org >Subject: SM> My response to some of the 18 Document issues...Comments? > >All, > >I saw many of the issues as "low hanging fruit". I have my responses to >issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on >and issues 14 to 17 are basically work to be done. This leaves issues 9 and >11. These involve how to represent the supported values for the document >format detail attributes. I think we will need to dedicate a large chunk of >time for this issue in Thursday's teleconference. > >Are there any comments on these issues or my responses? > >Pete > >ISSUE 00: Or should we just delete "input-document-number" operation >attribute when we republish pwg5100.4 without "document-overrides? >Delete "input-document-number". Document numbers start at 1 and >monotonically increment as documents are added to the Job. > >ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the >object on which it operates? >No, keep it Send-Data. I see no reason for the longer name. The only >data we send is associated with a Document. We don't have >CreateJob-Document >or Create-Printer-Job. > >ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support >it, since PSI is using it? >Yes > >ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute >for a Printer to support (if it supports the Document object)? Otherwise, >clients won't support it and will be stuck with the "ipp-attribute-fidelity" >attribute? >It should be an OPTIONAL Operation Attribute that a Printer MUST support >if the Printer supports the Document Object. > >ISSUE 04: The "document-overrides" attribute is also useful in combination >with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the >Input Page stream concatenated across the Input Documents into separate >Output Documents. For example, making every 10 Input Pages be a separate >Output Document but the client only wants to staple the first Output >Document. ISSUE 04: But what about Subset Finishing? Can we it be done >without "document-overrides"? >Get rid of "document-overrides" in favor of the Document. Place the >burden of the example corner case on the Client. The results can be easily >achieved through the use of Documents and page-overrides. > >ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE >the Printer to continue to support the "page-overrides" as an operation >attribute in Send-Document and Send-URI as well as a Document Template >attribute? >Yes > >ISSUE 06: OK that "document-container-summary" is only one level deep? >Yes, this information is not a manifest of the contained documents. >It is used to determine if a Printer can process the Document. Clients >are free to send individual compressed Documents if a manifest of a Job's >contents is required. > >ISSUE 07: Is the description of "document-container-summary" attribute OK? >Clarify that a manifest can be accomplished by the Client sending >individually compressed Documents. > >ISSUE 08: Are the conformance requirements for the >"document-container-summary" attributes OK? >No opinion > >ISSUE: 09: How can a Printer indicate which combinations of >document-creator-application-name (name(MAX)), >document-creator-application-version (text(127)), document-creator-os-name >(name(40)), document-creator-os-version (text(40)), >document-format-device-id (text(127)), document-format-version (text(127), >document-format (mimeMediaType) and "document-natural-language >(naturalLanguage) are supported? > >ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to >support? >Yes > >ISSUE: 11: The problem with separating "document-format" and >"document-format-version" is how can a Printer describe what versions are >supported, since the versions have to be associated with the document >format. > >ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. >ISSUE 12: Or should the official ISO standard number, part number and date, >be used instead, e.g., "ISO nnnnn.n-2001"? >No opinion > >ISSUE 13: The definition of "document-natural-language" in [rfc2911] >?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document >Description attribute isn't 1setOf? Or should we extend >"document-natural-language" to 1setOf naturalLanguage) and keep the same >name? Or change the name to "document-natural-languages"? >Keep single-valued. It will handle the vast majority of cases and >keep things simple > >ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table >14 that go with the Document Template attributes. >OK > >ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Document Template attributes. >OK > >ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Job Template attributes being defined. >OK > >ISSUE 17: TBD - Need to list the keyword attribute values in the IANA >Registration section. Do so by reference to the values registered for >corresponding attributes. >OK > >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 > > > >ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf > >Send any comments to the SM mailing list. > >Thanks, >Tom > > >----- >This message was submitted by Tom Hastings (Xerox) >Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5383 >Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 ----- This message was submitted by Martin Bailey (Global Graphics Software) Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5407 Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 From hastings at cp10.es.xerox.com Thu Mar 20 10:51:21 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> FW: JDF FileSpec/@FileFormatVersionand IPP "document-format-versi on"for PDF/X and TIFF/IT Message-ID: For the PWG Semantic telecon today (10:00 AM PST, 1:00 PM EST): For PWG Semantic folks who want to understand the parallel semantics being developed for JDF, here is the proposed additions to the JDF FileSpec resource and a direct comparison with the IPP Document Object attributes that we are reviewing today at the SM call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030318-rev. pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030318-rev. doc.zip I also suspect that the details of which values for non-MIME type documents are not going to be so interesting to IPP/SM/PSI. Tom P.S. The JDF Capabilities WG will be reviewing the FileSpec proposal at a CIP4 telecon that starts in 10 minutes (8:00 AM PST, 11:00 AM EST). Bob Taylor and I will bring any late developing ideas to the SM telecon today if it might affect what we want to do in the IPP Document Object spec. -----Original Message----- From: Hastings, Tom N Sent: Thursday, March 20, 2003 07:36 To: 'capabilities@cip4.org' Cc: 'sm@pwg.org'; 'Masinter, Larry at Adobe' Subject: RE: JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Here are some really good comments from Martin Bailey about a number of recent emails about the FileSpec proposal for JDF from Ann McCarthy, Bob Taylor, and myself. Martin, One thing I left out of the proposal by mistake was how to indicate which types of fonts: "Type 1" "TrueType" "OpenType" ... I think we should just add another attribut to FileSpec, say, FontType (string) that has meaning when FileClass = Font. I like yours and Ann's suggestion not to use the ISO standard designation ("ISO nnnn-part:year") when the ISO standard has a versioning mechanism specified as part of it, as does TIFF/IT and PDF/X (see below). Also I forgot to include DCS (Desktop Color Separation version 2). It doesn't have an ISO standard, right? Tom -----Original Message----- From: Martin Bailey [mailto:Martin.Bailey@globalgraphics.com] Sent: Thursday, March 20, 2003 03:03 To: hastings@cp10.es.xerox.com Subject: CIP4 Forum Capabilities: Re:JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Hi Tom Responses in-line. At 02:37 19/03/2003, Tom Hastings wrote: >I did a google search to find out what the ISO designation is for the >PDF/X-1 and TIFF/IT ISO standards. > >We're trying to define which values should be used for JDF >FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that >we've collapsed FileFormatStandard into FileFormatVersion as suggested. > >Same question for IPP "document-format" (mimeMediaType) and >"document-format-version" (text(127)) attributes, assuming that we've >collapsed "document-format-standard" into "document-format-version" >(text(127)) as suggested. > > >This is what I found from google: > >1. PDF/X: > >ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use >of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) > >So this sounds great to use the value of "ISO 15930-1:2001" for the value >of: > > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >instead of "PDF/X-1:2001". And the MimeType attribute value will be >"application/pdf". > >ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish >them in either the MimeType or FileFormatVersion attribute? I would go back to the suggestion that I originally made, which matches the strings that are used inside the file to uniquely identify the conformance level: "PDF/X-1a:2001", "PDF/X-3:2002", etc. At 19:02 19/03/2003, Tom Hastings wrote: >1. Should we also list in JDF the "PDF/X-1:1999" value as well? Its mention >in the 2001 ISO standard as an "older version". Given that the list we will include in the standard is, almost by definition, incomplete, no - I would not include that. It's an obsolete file format, defined in a standard that has been withdrawn. If somebody really wants to include it they could figure out from the other values in the list what the right string should be. >2. TIFF/IT: > >ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag >image file format for image technology (TIFF/IT). > >So use the value "ISO 12639-1998" for the value of: That would be "ISO 12639:1998", colon rather than hyphen. > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >Since TIFF/IT doesn't yet have a MIME type registered, the JDF >FileSpec/@MimeType attribute will be omitted and the IPP "document-format" >attribute will be omitted, OK? OK, but how do you plan to distinguish between the sub-file types (FP, CT, LW, HC) and between baseline TIFF/IT and TIFF/IT-P1? Those are important questions when it comes to capabilities reporting because many tools will only read P1, and not baseline, and many can't read all of the sub-file types. I made some suggestions for those in my original mail. At 15:27 19/03/2003, Ann McCarthy wrote: >TIFF/IT files also have several possible conformance levels. >TIFF/IT conformance strings (given in section 5 of ISO 12639) >are: >TIFF/IT >TIFF/IT-CT >TIFF/IT-LW >TIFF/IT-HC >TIFF/IT-MP >TIFF/IT-BP >TIFF/IT-BL >TIFF/IT-P1 >TIFF/IT-CT/P1 >TIFF/IT-LW/P1 >TIFF/IT-HC/P1 >TIFF/IT-MP/P1 >TIFF/IT-BP/P1 >TIFF/IT-BL/P1 > >Each of these informs the reader of specific constraints or file >interpretation requirements. > >We may be able to reduce the list of TIFF/IT strings if someone >more familiar with the exchange of TIFF/IT can identify a case >that never occurs. Absent that - JDF should duplicate the >conformance level identifiers given in the ISO 12639 standard. Ann's suggested list is almost what we need: - I'm not sure what "TIFF/IT" on its own means in that context - did you mean 'FP'? I know FP isn't normative in the 1998 standard (it is in the 2003 revision), but that doesn't stop people using it :-) - there's a 2003 revision of 12639 in ballot at the moment, so we need a date suffix on all of the above. In theory the P1 subset has not been changed in that revision (we tried not leave it unchanged, anyway), but I'd feel safer with a date suffix still, although that might complicate capabilities reporting somewhat. The revision also adds a new file subtype (SD), and a new conformance level (P2). The full list therefore gets a bit long: TIFF/IT-FP:1998 TIFF/IT-CT:1998 TIFF/IT-LW:1998 TIFF/IT-HC:1998 TIFF/IT-MP:1998 TIFF/IT-BP:1998 TIFF/IT-BL:1998 TIFF/IT-FP/P1:1998 TIFF/IT-CT/P1:1998 TIFF/IT-LW/P1:1998 TIFF/IT-HC/P1:1998 TIFF/IT-MP/P1:1998 TIFF/IT-BP/P1:1998 TIFF/IT-BL/P1:1998 TIFF/IT-FP:2003 TIFF/IT-CT:2003 TIFF/IT-LW:2003 TIFF/IT-HC:2003 TIFF/IT-MP:2003 TIFF/IT-BP:2003 TIFF/IT-BL:2003 TIFF/IT-SD:2003 TIFF/IT-FP/P1:2003 TIFF/IT-CT/P1:2003 TIFF/IT-LW/P1:2003 TIFF/IT-HC/P1:2003 TIFF/IT-MP/P1:2003 TIFF/IT-BP/P1:2003 TIFF/IT-BL/P1:2003 (no P1 conformance level of SD) TIFF/IT-FP/P2:2003 TIFF/IT-CT/P2:2003 TIFF/IT-LW/P2:2003 TIFF/IT-HC/P2:2003 TIFF/IT-MP/P2:2003 TIFF/IT-BP/P2:2003 TIFF/IT-BL/P2:2003 TIFF/IT-SD/P2:2003 But, as I commented above, the list in the spec can only be regarded as incomplete, so it might be better to explicitly make it a set of examples and include only some of these? At 07:32 19/03/2003, Bob Taylor wrote: > >I would think we'd just use the TIFF MIME type for these (application/TIFF >?). > No, because most TIFF/IT subfile types are not valid TIFF. Martin >Tom > > > >-----Original Message----- >From: McCarthy, Ann L >Sent: Tuesday, March 18, 2003 10:09 >To: Zehler, Peter; Hastings, Tom N; sm@pwg.org >Subject: RE: SM> My response to some of the 18 Document >issues...Comments? > > >All, > >WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. > >-------------------------------------------------------------------- >Ann L. McCarthy >XIG/SSTC Imaging Systems Architect >Internal:8*221-8701 External: 585-231-8701 >FAX: 585-265-8871 Mailcode: B128-30E > > >-----Original Message----- >From: Zehler, Peter [mailto:PZehler@crt.xerox.com] >Sent: Tuesday, March 18, 2003 9:52 AM >To: Hastings, Tom N; sm@pwg.org >Subject: SM> My response to some of the 18 Document issues...Comments? > >All, > >I saw many of the issues as "low hanging fruit". I have my responses to >issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on >and issues 14 to 17 are basically work to be done. This leaves issues 9 and >11. These involve how to represent the supported values for the document >format detail attributes. I think we will need to dedicate a large chunk of >time for this issue in Thursday's teleconference. > >Are there any comments on these issues or my responses? > >Pete > >ISSUE 00: Or should we just delete "input-document-number" operation >attribute when we republish pwg5100.4 without "document-overrides? >Delete "input-document-number". Document numbers start at 1 and >monotonically increment as documents are added to the Job. > >ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the >object on which it operates? >No, keep it Send-Data. I see no reason for the longer name. The only >data we send is associated with a Document. We don't have >CreateJob-Document >or Create-Printer-Job. > >ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support >it, since PSI is using it? >Yes > >ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute >for a Printer to support (if it supports the Document object)? Otherwise, >clients won't support it and will be stuck with the "ipp-attribute-fidelity" >attribute? >It should be an OPTIONAL Operation Attribute that a Printer MUST support >if the Printer supports the Document Object. > >ISSUE 04: The "document-overrides" attribute is also useful in combination >with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the >Input Page stream concatenated across the Input Documents into separate >Output Documents. For example, making every 10 Input Pages be a separate >Output Document but the client only wants to staple the first Output >Document. ISSUE 04: But what about Subset Finishing? Can we it be done >without "document-overrides"? >Get rid of "document-overrides" in favor of the Document. Place the >burden of the example corner case on the Client. The results can be easily >achieved through the use of Documents and page-overrides. > >ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE >the Printer to continue to support the "page-overrides" as an operation >attribute in Send-Document and Send-URI as well as a Document Template >attribute? >Yes > >ISSUE 06: OK that "document-container-summary" is only one level deep? >Yes, this information is not a manifest of the contained documents. >It is used to determine if a Printer can process the Document. Clients >are free to send individual compressed Documents if a manifest of a Job's >contents is required. > >ISSUE 07: Is the description of "document-container-summary" attribute OK? >Clarify that a manifest can be accomplished by the Client sending >individually compressed Documents. > >ISSUE 08: Are the conformance requirements for the >"document-container-summary" attributes OK? >No opinion > >ISSUE: 09: How can a Printer indicate which combinations of >document-creator-application-name (name(MAX)), >document-creator-application-version (text(127)), document-creator-os-name >(name(40)), document-creator-os-version (text(40)), >document-format-device-id (text(127)), document-format-version (text(127), >document-format (mimeMediaType) and "document-natural-language >(naturalLanguage) are supported? > >ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to >support? >Yes > >ISSUE: 11: The problem with separating "document-format" and >"document-format-version" is how can a Printer describe what versions are >supported, since the versions have to be associated with the document >format. > >ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. >ISSUE 12: Or should the official ISO standard number, part number and date, >be used instead, e.g., "ISO nnnnn.n-2001"? >No opinion > >ISSUE 13: The definition of "document-natural-language" in [rfc2911] >?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document >Description attribute isn't 1setOf? Or should we extend >"document-natural-language" to 1setOf naturalLanguage) and keep the same >name? Or change the name to "document-natural-languages"? >Keep single-valued. It will handle the vast majority of cases and >keep things simple > >ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table >14 that go with the Document Template attributes. >OK > >ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Document Template attributes. >OK > >ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Job Template attributes being defined. >OK > >ISSUE 17: TBD - Need to list the keyword attribute values in the IANA >Registration section. Do so by reference to the values registered for >corresponding attributes. >OK > >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 > > > >ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf > >Send any comments to the SM mailing list. > >Thanks, >Tom > > >----- >This message was submitted by Tom Hastings (Xerox) >Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5383 >Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 ----- This message was submitted by Martin Bailey (Global Graphics Software) Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5407 Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 From AMcCarthy at crt.xerox.com Thu Mar 20 11:17:07 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:30 2009 Subject: SM> RE: JDF FileSpec/@FileFormatVersionand IPP "document-form at-versi on"for PDF/X and TIFF/IT Message-ID: Martin, One question: What is FP? I did not see that in the 1998 standard - my impression from reading the spec is that TIFF/IT is the all inclusive designation. Is that not correct? Also, regarding your comment: >But, as I commented above, the list in the spec can only be regarded as >incomplete, so it might be better to explicitly make it a set of examples >and include only some of these? It seems better to me to put the complete list that you have provided into the spec. One benefit is that it clearly warns readers that each of these conformance levels is distinct. Regards, Ann -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E At 15:27 19/03/2003, Ann McCarthy wrote: >TIFF/IT files also have several possible conformance levels. >TIFF/IT conformance strings (given in section 5 of ISO 12639) >are: >TIFF/IT >TIFF/IT-CT >TIFF/IT-LW >TIFF/IT-HC >TIFF/IT-MP >TIFF/IT-BP >TIFF/IT-BL >TIFF/IT-P1 >TIFF/IT-CT/P1 >TIFF/IT-LW/P1 >TIFF/IT-HC/P1 >TIFF/IT-MP/P1 >TIFF/IT-BP/P1 >TIFF/IT-BL/P1 > -----Original Message----- From: Martin Bailey [mailto:Martin.Bailey@globalgraphics.com] Sent: Thursday, March 20, 2003 03:03 To: hastings@cp10.es.xerox.com Subject: CIP4 Forum Capabilities: Re:JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Hi Tom Responses in-line. .... Ann's suggested list is almost what we need: - I'm not sure what "TIFF/IT" on its own means in that context - did you mean 'FP'? I know FP isn't normative in the 1998 standard (it is in the 2003 revision), but that doesn't stop people using it :-) - there's a 2003 revision of 12639 in ballot at the moment, so we need a date suffix on all of the above. In theory the P1 subset has not been changed in that revision (we tried not leave it unchanged, anyway), but I'd feel safer with a date suffix still, although that might complicate capabilities reporting somewhat. The revision also adds a new file subtype (SD), and a new conformance level (P2). The full list therefore gets a bit long: TIFF/IT-FP:1998 TIFF/IT-CT:1998 TIFF/IT-LW:1998 TIFF/IT-HC:1998 TIFF/IT-MP:1998 TIFF/IT-BP:1998 TIFF/IT-BL:1998 TIFF/IT-FP/P1:1998 TIFF/IT-CT/P1:1998 TIFF/IT-LW/P1:1998 TIFF/IT-HC/P1:1998 TIFF/IT-MP/P1:1998 TIFF/IT-BP/P1:1998 TIFF/IT-BL/P1:1998 TIFF/IT-FP:2003 TIFF/IT-CT:2003 TIFF/IT-LW:2003 TIFF/IT-HC:2003 TIFF/IT-MP:2003 TIFF/IT-BP:2003 TIFF/IT-BL:2003 TIFF/IT-SD:2003 TIFF/IT-FP/P1:2003 TIFF/IT-CT/P1:2003 TIFF/IT-LW/P1:2003 TIFF/IT-HC/P1:2003 TIFF/IT-MP/P1:2003 TIFF/IT-BP/P1:2003 TIFF/IT-BL/P1:2003 (no P1 conformance level of SD) TIFF/IT-FP/P2:2003 TIFF/IT-CT/P2:2003 TIFF/IT-LW/P2:2003 TIFF/IT-HC/P2:2003 TIFF/IT-MP/P2:2003 TIFF/IT-BP/P2:2003 TIFF/IT-BL/P2:2003 TIFF/IT-SD/P2:2003 But, as I commented above, the list in the spec can only be regarded as incomplete, so it might be better to explicitly make it a set of examples and include only some of these? At 07:32 19/03/2003, Bob Taylor wrote: > >I would think we'd just use the TIFF MIME type for these (application/TIFF >?). > No, because most TIFF/IT subfile types are not valid TIFF. Martin From hastings at cp10.es.xerox.com Thu Mar 20 18:49:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Document object, Meeting Notes, Thursday, March 20, 2003 Message-ID: Document object, Meeting Notes, Thursday, March 20, 2003 File: document-object-meeting-notes-20030320.doc Attendees: Peter Zehler, Dennis Carney, Gail Songer, Ira McDonald, Bob Tailor, Tom Hastings, Harry Lewis. The notes are edited into Peter's response to the outstanding issues. We resolved all of the issues on the telecon. See the notes below. Please send any comments on these minutes now, so I can reflect in the updated document. [Editor's note: we changed the semantics of the "document-format-details" operation attribute at the end of the telecon from the member attributes being Must Honor to being Best Effort, but didn't revisit the name of the corresponding "document-format-details-allowed" (1setOf collection) Printer attribute. Since the Printer will allow other attributes and values (and ignore them), the "-allowed" suffix is now mis-leading. So Ira and I suggest that we change the suffix from "-allowed" to "-implemented". So change "document-format-details-allowed" to "document-format-details-implemented". OK? I've assumed this change in the following notes.] ACTION ITEM (Tom): Update and post the spec today or tomorrow. ACTION ITEM (Pete): Update and post the Semantic Model to reflect the agreements (probably Monday). Hold a second one hour review, next Thursday, March 27, 2003, same time (10:00 AM PST, 1:00 PM EST). Peter and Bob to setup the teleconference and webex, respectively. Tom From: Zehler, Peter Sent: Tuesday, March 18, 2003 06:52 To: Hastings, Tom N; sm@pwg.org Subject: My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. AGREED. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. AGREED: to keep name as Send-Data ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes AGREED. ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. AGREED: The Printer MUST support the "job-mandatory-attributes" operation attribute, client MAY supply. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. AGREED: Subset finishing is how to staple ranges of pages that cover all of a single document? Do subset finishing with "page-overrides", instead of "document-overrides" (which is being deleted). One possibility is to use "pages-per-subset" (1setOf integer) as one of the member attributes of the "page-overrides" since "pages-per-subset" is a Job Template attribute that applies to an Input Document. Tom to talk to Claudia Alimpich from IBM as well, since the concept of subset finishing is also in the FSG Job Ticket API. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes AGREED: If a Printer supports "page-overrides": a. the Printer MUST support both the "page-overrides" as (1) an operation attribute (for backward compatibility and clients that don't support the Document object) and (2) as a Document Template attribute in Send-Document and Send-URI requests. The client MAY supply "page-overrides" as either a Job Template attribute or an operation attribute in Send-Document and Send-URI requests. b. the Printer MUST support "page-overrides" as a Document Template attribute, not as an operation attribute in Create-Document requests. ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. AGREED: That is it OK to have only one level for the summary details attribute that the Printer uses to accept or reject jobs. 6.1 Should have two separate attributes, one for summary details and one for a "document-manifest" which has a separate entry for each file in a container and needs to allow nesting to be expressed. ACTION (Tom and Bob): Advocate two separate attributes with CIP4, rather than defining one form that tries to do both. 6.2 We'll won't add the manifest attribute to IPP Document object at this point. 6.3 Need a better word than container and a better word than summary. Agreed to go back to "document-format-details" and clarify that it is unordered and applies to a single document file as well as a container file containing multiple files. 6.4 Move the top level operation/Document Description attributes (except "document-format" which remains at both levels) back to be member attributes of the "document-format-details" collection operation/Document Description attribute. So the following Document Description attributes will be the member attributes of the "document-format-details" operation/Document Description attribute: document-creator-application-name (name(MAX)) document-creator-application-version (text(127)) document-creator-os-name (name(40)) document-creator-os-version (text(40)) document-format (mimeMediaType document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) 6.5 Allow, but don't require, the client to supply one of the collection values to describe the details about the top level container format (application/zip and multipart/related) as well. 6.6 Add a "document-format-details-detected" Job Description attribute which the Printer MAY support and fill in with detected values. Keep "document-format-detected" as a separate Job Description attribute, so that collections aren't required by a Printer that only wants to reflect the document format detected. 6.7 The "document-format-details" will remain an operation attribute that the Printer MUST copy to the corresponding Document Description attribute, same as for the "document-format" operation/Document Description attribute. 6.8 Other Document Description attributes that the Printer detects/updates, such as "k-octets", are a separate concept and aren't to be added to "document-format-details" or "document-format-details-detected". ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. AGREED. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion AGREED: A Printer MUST support the "document-format" and the "document-format-version" member attributes, and MAY support any of the other member attributes: document-creator-application-name (name(MAX)) document-creator-application-version (text(127)) document-creator-os-name (name(40)) document-creator-os-version (text(40)) document-format-device-id (text(127)) document-natural-language (naturalLanguage) ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? AGREED: 9.1 Add a "document-format-details-supported" (1setOf type2 keyword) Printer Description attribute which lists the member attributes of "document-format-details" that the Printer supports. Values: document-creator-application-name, document-creator-application-version, document-creator-os-name, document-creator-os-version, document-format, document-format-device-id, document-format-version, and document-natural-language. 9.2 We won't define "xxx-supported" attributes that go with each of the member attributes of "document-format-details", since the member attributes are not orthogonal to each other. Instead, define a "document-format-details-implemented" (1setOf collection) Printer Description attribute whose member attributes show collections of values that go together. The member attributes of "document-format-details-implemented" are: document-creator-application-name-implemented (1setOf name(MAX)) document-creator-application-version-implemented (1setOf text(127)) document-creator-os-name-implemented (1setOf name(40)) document-creator-os-version-implemented (1setOf text(40)) document-format-implemented (1setOf mimeMediaType document-format-device-id-implemented (1setOf text(127)) document-format-version-implemented (1setOf text(127) document-natural-language-implemented (1setOf naturalLanguage) 9.3 Except for "document-format", all other member attributes supplied by a client are supplied as "hints", that is Best Effort (i.e., treat as if fidelity is false), whether the Printer's "document-format-details-implemented" Printer Description attribute has that member attribute or not and whether or not the Printer's "document-format-details-supported" has that keyword for that member attribute. The "document-format" operation attribute and member attribute of "document-format-details" remain as a Must Honor attribute (i.e., treat as if fidelity is true and reject the job if the document-format isn't supported). 9.4 Currently, "ipp-attribute-fidelity" and the new "job-mandatory-attributes" do NOT apply to operation attributes, only to Job Template attributes. However as an exception, "ipp-attribute-fidelity" and the new "job-mandatory-attributes" will be defined to apply to the "document-format-details" operation attribute and all its member attributes. For example, the client can supply the following keyword value for the "job-mandatory-attributes" attribute: 'document-format-details.document-format-os-name' indicating that the Printer MUST honor the OS name or MUST reject the job. The "document-format" member attribute (and operation attribute) will remain forever mandatory (Must Honor) as in [RFC2911], independent of "ipp-attribute-fidelity" and "job-mandatory-attributes". Example of a single set of values for a Printer of "document-format-details-implemented" (1setOf collection): {{document-format=application/ps, document-format-version=1, 2, 3}, {document-format=application/ps, document-format-version=3, document-natural-language=en, fr, de}, {document-format=application/vnd.hp-PCL, document-format-version=5e}, {document-format=application/msword, document-format-version=5.0, 6.0, 2000, document-format-os-name=MACOS, WINDOWS} } Typically, there will only be one value for "document-format" in each collection. However, there can be more than one occurrence of a collection value with the same "document-format". See above example which has two PostScript collection values. ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes AGREED: Printer MUST support the "document-format" and "document-format-version" member attributes if it supports the "document-format-details" collection attribute. The Printer MAY support additional member attributes. ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. AGREED: The "document-format-details-implemented" (1setOf collection) Printer Description attribute describes which versions go with each document format. See ISSUE ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion AGREED: Use examples as agreed in CIP4 from the ISO standard itself, such as 'PDF/X-1:2001' and 'PDF/X-1a:2001' which are from the same ISO standard. ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple AGREED: Clarify that the first language in the document is used as the value. ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK AGREED ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK AGREED ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK AGREED ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK AGREED 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Mon Mar 24 04:07:12 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Updated Comparison of JDF FileSpec and corresponding IPP Document object available Message-ID: The downloaded document starts out with the proposed JDF FileSpec resource additions. Then the second half is a side-by-side comparison of the JDF FileSpec resource with IPP Document object attributes. I've included the changes to the specific IPP "document-format-details" member attributes from the Thursday, 20-March-2003 telecon. The document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030321.doc. zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030321.pdf This document contains proposed additions and clarifications to the JDF FileSpec resource for JDF/1.2 and the corresponding IPP Document Description attribute proposed for the IPP Document object extensions. The reason for showing both in the same document is to try to align the semantics where possible. Some of us believe that there will be significant interworking between JDF and other systems, such as IPP. Having the same values of corresponding attributes will make gateways a lot simpler. Note: There is no need for the names of the attributes to be the same. The real gain is for the values. These proposals build on the proposals from Martin Bailey, Bob Taylor, and Israel Viente in CIP4 and the proposals from Bob Taylor, Dave Hall, and Peter Zehler in the PWG for inclusion in the IPP Document Object, PWG Semantic Model and PWG Print Services Interface (PSI) which is a follow on to Bluetooth. The most recent version results from a telecon on March 21 with Craig Benson, Bob Taylor, Steve Hiebert, and Tom Hastings attempting to accommodate all of the comments received in email. Please send any comments. I'm working on the full IPP Document object spec updating the agreements reached on Thursday, March 20 telecon and will have it out on Monday, March 24. Tom From PZehler at crt.xerox.com Mon Mar 24 12:16:08 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Inconsistent Action, Element, StatusString and Value Message-ID: All, Unless there is any objection I would like to keep the naming convention consistent across the PWG Semantic Model. We recently changed the StatusString to align with the way all the elements and actions are named. While working on appendix B I saw the mapping could be simplified if we apply the same rules to the values of elements as we do to the elements. Therefore I propose that the values for the elements be aligned with our convention of capitalizing the first letter, dropping the '-' and capitalizing the letter that follows it. Of course the values that we reference from non-PWG/IPP sources would remain the same (e.g. mime type names). I would also not change the values used for media types, media color, and media size since they are in a non-IPP specific registry(PWG5101.1) and are in use in other environments. Any objections? 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 From PZehler at crt.xerox.com Mon Mar 24 12:38:51 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Case sensitivity Message-ID: All, In the Semantic Model what is our position on case sensitivity? The Semantic Model and its associated schema use Pascal casing for element names to improve readability. I assume that 1) Semantic elements (actions, elements, keywords) must differ in more than case. That is, we will not define a mew semantic element such " Jobstate" since "JobState" is already defined. Do we mandate that how the equality of tokens (i.e. keywords) is handled in the Semantic Model document? 2) I assume keywords are compared without regard to case in the model and leave it to the mapping to determine what rules will be applied in that particular mapping of the Semantic Model. 2a) Implementations are simplified in low end mappings and in XML if case sensitive mapping is mandated. 2b) Server implementations would be more forgiving if they did case insensitive compares. Any objections to including the 2 statements above in the next SM release? 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 From imcdonald at sharplabs.com Mon Mar 24 12:45:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:30 2009 Subject: SM> Case sensitivity Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF45@mailsrvnt02.enet.sharplabs.com> Hi Pete, I agree with your positions on case sensitivity below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Monday, March 24, 2003 11:39 AM To: PWG Semantic Model WG (E-mail) Subject: SM> Case sensitivity All, In the Semantic Model what is our position on case sensitivity? The Semantic Model and its associated schema use Pascal casing for element names to improve readability. I assume that 1) Semantic elements (actions, elements, keywords) must differ in more than case. That is, we will not define a mew semantic element such " Jobstate" since "JobState" is already defined. Do we mandate that how the equality of tokens (i.e. keywords) is handled in the Semantic Model document? 2) I assume keywords are compared without regard to case in the model and leave it to the mapping to determine what rules will be applied in that particular mapping of the Semantic Model. 2a) Implementations are simplified in low end mappings and in XML if case sensitive mapping is mandated. 2b) Server implementations would be more forgiving if they did case insensitive compares. Any objections to including the 2 statements above in the next SM release? 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 From dhall at hp.com Mon Mar 24 13:13:44 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:30 2009 Subject: SM> Case sensitivity Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABCB@xvan01.vcd.hp.com> I'll second that agreement. Case insensitive compares on keywords is a good thing. However, I would not like to see anyone having to deal with JobState vs. Jobstate as an element declaration (ie, everyone must always use JobState..) Dave -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, March 24, 2003 9:45 AM To: 'Zehler, Peter'; PWG Semantic Model WG (E-mail) Subject: RE: SM> Case sensitivity Hi Pete, I agree with your positions on case sensitivity below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Monday, March 24, 2003 11:39 AM To: PWG Semantic Model WG (E-mail) Subject: SM> Case sensitivity All, In the Semantic Model what is our position on case sensitivity? The Semantic Model and its associated schema use Pascal casing for element names to improve readability. I assume that 1) Semantic elements (actions, elements, keywords) must differ in more than case. That is, we will not define a mew semantic element such " Jobstate" since "JobState" is already defined. Do we mandate that how the equality of tokens (i.e. keywords) is handled in the Semantic Model document? 2) I assume keywords are compared without regard to case in the model and leave it to the mapping to determine what rules will be applied in that particular mapping of the Semantic Model. 2a) Implementations are simplified in low end mappings and in XML if case sensitive mapping is mandated. 2b) Server implementations would be more forgiving if they did case insensitive compares. Any objections to including the 2 statements above in the next SM release? 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 From PZehler at crt.xerox.com Mon Mar 24 14:32:11 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Placeholder for Thursday's Semantic Model Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be cover the Document Object, the Semantic Model and preparing for the upcoming Face-to-Face. The documents are not quite ready yet, but I wanted to make sure to get a meeting reminder out. The teleconference is one hour long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) Adjust agenda 3) Check out the latest changes to the Semantic Model Specification I'll post the latest version on Tuesday 2) Walk through Document Object Specification I'll post the latest version on Tuesday 3) What will be accomplished at the Face-to-Face 4) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 3/27/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From ElliottBradshaw at oaktech.com Mon Mar 24 16:38:05 2003 From: ElliottBradshaw at oaktech.com (ElliottBradshaw@oaktech.com) Date: Wed May 6 14:04:30 2009 Subject: SM> New CR document: Standard for Character Repertoire Interoperabiliy Message-ID: Folks, I have placed an updated version of the Chracter Repertoires document at: ftp://ftp.pwg.org/pub/pwg/Character-Repertoires/wd-pcr10-20030317.html This is a standards track document intended to serve as a reference for the Semantic Model. In addition to Yet Another Name, hightlights of recent changes include: -Changed the title to remove "Preferred" -Marked some sections as Informative -Formatting cleanup; addition of copyright notice, acknowledgements, etc. -Clarification in the Abstract and Introduction of goals and non-goals -More information about how this document relates to the Semantic Model -Changed the details of syntax for repertoire names -More information about rules for matching repertoire names -Clarified the wording regarding font sensitivity -Confirmed use of Unicode code charts for basic non-Asian repertoires -Changed from the notion of "Preferred Repertoire" to "Basic Repertoire"; this emphasizes that the printer is free to advertise additional repertoires -Included Latin-1 Supplement and Latin Extended-A as Basic Repertoires -Added requirement to support the euro character -References Open issues (that I know of) are highlighted in the document. Based on recent meetings I think we are approaching consensus on a number of issues. Some specific things I want to work on next week: -making this suitable for use by SM -applying the appropriate PWG process: name, number, approval, etc. Depending on how our discussion goes we may be able to move to Last Call in the fairly near future. Please send comments ASAP, esp. if you will not be in DC. Thanks, Elliott ------------------------------------------ Elliott Bradshaw Director, Software Engineering Oak Technology Imaging Group 781 638-7534 From hastings at cp10.es.xerox.com Tue Mar 25 05:52:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Updated IPP Document Object spec downloaded for Thur, March 27, S M telecon Message-ID: I've down loaded the updated versions of the IPP Document Object specification with the changes agreed to at the Thursday, March 20, 2003 telecon. They are at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) Change Log: Version 0.8, 24 March 2003, agreements from the March 20 telecon: 1. Changed the name of the Send-Document-Data back to Send-Data to keep the name short. There wasn't support for keeping the name of the object affected in the name of the operation. 2. Changed "job-mandatory-attributes" operation/Job Description attribute so that a Printer MUST support it. 3. Changed the name of the collection attribute back to "document-format-details". 4. Removed the Operation attributes and Document Description attributes that were already in the member attributes of "document-format-details", so that any details must use the "document-format-details" (1setOf collection). 5. Clarified that with the removal of "document-overrides", that the client can achieve subset finishing using "pages-per-subset" and "page-overrides". 6. Clarified that a Printer that supports "page-overrides" Document Template attribute MUST also support it as an Operation attribute in Send-Document and Send-URI, but not Create-Document, for backward compatibility. 7. Clarified that containers may contain containers, but that the "document-format-details" MUST be flattened, if present. 8. Clarified that the collection values MAY describe the container format itself, in which case, it must be the first collection value. 9. Added "document-format-details-detected (1setOf collection) Document Description attribute. 10. Clarified that "document-natural-language" identifies the primary or first language if a Document contains more than one language. 11. Added document-format-details-supported (1setOf type2 keyword) Printer Description attribute. 12. Added document-format-details-implemented (1setOf collection) Printer Description attribute. 13. Clarified that a Printer MUST support the "document-creation-attributes-supported" (1setOf type2 keywords) Printer Description attribute. One ISSUE remaining: Values of the "document-creator-application-version: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)"'V3.0.', 'V6.0' ISSUE: OK that the purpose of "document-creator-application-version is human consumption, instead of program consumption and that it be the same as the application shows in its help message? Tom From imcdonald at sharplabs.com Tue Mar 25 12:18:24 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:30 2009 Subject: SM> document-id-uri semantics Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF47@mailsrvnt02.enet.sharplabs.com> Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 16:48:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> document-id-uri semantics Message-ID: Is there any experimental scheme that we could use, so we don't have to muck with the "ipp:" scheme? If there is, we could just mention what that scheme is in the spec. Or since this is a URI data type, is there some URN form that we could use to give each document a unique identifiers? All we want is a unique identifier across that one Printer. Its doesn't have to be unique across all Printers, right? We also need to agree as to over what time period the ID has to be unique? If the Printer is powered off and comes back again, does it have to continue to generate unique URIs that it never generated before? Or don't we have to be that strict. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, March 25, 2003 09:18 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> document-id-uri semantics Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 17:31:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Message-ID: Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From PZehler at crt.xerox.com Wed Mar 26 08:13:01 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Updated IPP Document Object spec downloaded for Thur, Mar ch 27, S M telecon Message-ID: Tom, Section 8.2.10 should reference section 6.1.2 for the definition of member attributes and semantics. 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: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 5:52 AM To: sm@pwg.org Subject: SM> Updated IPP Document Object spec downloaded for Thur, March 27, S M telecon I've down loaded the updated versions of the IPP Document Object specification with the changes agreed to at the Thursday, March 20, 2003 telecon. They are at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) Change Log: Version 0.8, 24 March 2003, agreements from the March 20 telecon: 1. Changed the name of the Send-Document-Data back to Send-Data to keep the name short. There wasn't support for keeping the name of the object affected in the name of the operation. 2. Changed "job-mandatory-attributes" operation/Job Description attribute so that a Printer MUST support it. 3. Changed the name of the collection attribute back to "document-format-details". 4. Removed the Operation attributes and Document Description attributes that were already in the member attributes of "document-format-details", so that any details must use the "document-format-details" (1setOf collection). 5. Clarified that with the removal of "document-overrides", that the client can achieve subset finishing using "pages-per-subset" and "page-overrides". 6. Clarified that a Printer that supports "page-overrides" Document Template attribute MUST also support it as an Operation attribute in Send-Document and Send-URI, but not Create-Document, for backward compatibility. 7. Clarified that containers may contain containers, but that the "document-format-details" MUST be flattened, if present. 8. Clarified that the collection values MAY describe the container format itself, in which case, it must be the first collection value. 9. Added "document-format-details-detected (1setOf collection) Document Description attribute. 10. Clarified that "document-natural-language" identifies the primary or first language if a Document contains more than one language. 11. Added document-format-details-supported (1setOf type2 keyword) Printer Description attribute. 12. Added document-format-details-implemented (1setOf collection) Printer Description attribute. 13. Clarified that a Printer MUST support the "document-creation-attributes-supported" (1setOf type2 keywords) Printer Description attribute. One ISSUE remaining: Values of the "document-creator-application-version: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)"'V3.0.', 'V6.0' ISSUE: OK that the purpose of "document-creator-application-version is human consumption, instead of program consumption and that it be the same as the application shows in its help message? Tom From PZehler at crt.xerox.com Wed Mar 26 11:30:49 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Updated SM spec for Thur, March 27, S M telecon Message-ID: All, Here is the document we will use for the Semantic Model teleconference this week. ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030326.pdf I Highlighted the sections in the table of contents and in the body of the document that we will cover. As usual both word and pdf file formats are provided as well as "-rev" version of the document in both formats. Below are March's change log entries from the document. 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 3/26/03 PJZ Updated with changes from Document Object Specification 3/21/03 PJZ Added Character Repertoire 3/17/03 PJZ Removed PSI specific actions, corrected list of excluded elements in appendix B 3/16/03 TNH/PJZ Updated with the Document Object specifications. Added CloseJob that PSI is using. Renamed SendData to SendDocumentData to indicate what data. Prefixed JobId, JobPrinterUri, and JobUri Document Description elements with Document, so no Document attributes have a Job prefix. Added the following Document Description elements: DocumentContainerSummary, DocumentCreatorApplicationName, DocumentCreatorApplicationVersion, DocumentCreatorOsName, DocumentCreatorOsVersion, DocumentFormatDetected, DocumentFormatDeviceId, DocumentFormatVersion, DocumentIdUri, DocumentMessage, ElementNaturalLanguage. From PZehler at crt.xerox.com Wed Mar 26 11:34:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Complete information for Thursday's Semantic Model Teleconference Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference will be cover the Document Object, the Semantic > Model and preparing for the upcoming Face-to-Face. The documents > are not quite ready yet, but I wanted to make sure to get a meeting > reminder out. > > The teleconference is one hour long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > > The agenda for the Semantic Model teleconference is : > > 1) Adjust agenda > 3) Check out the latest changes to the Semantic Model Specification > ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030326.pdf > 2) Walk through Document Object Specification > ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip > 3) What to do now that the Face-to-Face is canceled > 4) Next steps > > > Pete > > PS: Bob, Let me know if you can not host the Webex. > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > > Webex MEETING SUMMARY > ------------------------- > Name: PWG Semantic Model > Date: 3/27/2003 > Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) > 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) > Meeting Number: 21366675 > Meeting Password: pwg_sm > Host: > Bob Taylor (HP) > > ___________________________________________________ > > > > > 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 > > From hastings at cp10.es.xerox.com Wed Mar 26 18:05:00 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Message-ID: Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From PZehler at crt.xerox.com Mon Mar 31 09:26:27 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Semantic Model Teleconference 4/3 Message-ID: All, The Semantic Model group will be holding a teleconference on Thursday April 3. The primary focus of the teleconference is to complete the review of the Document Object Specification. The current plan is to hold the teleconference from 12:00 to 3:00 eastern (9:00 to 12:00 Pacific). The first hour we will discuss the latest schema (version 0.91) which will be posted some time this week. The agenda and teleconference information is included below. Will anyone be able to host a Webex for this teleconference? ___________________________________________________ Agenda: 12:00 to 12:10 EST (9:00 to 9:10 PST): Intros & adjust agenda 12:10 to 1:00 EST (9:10 to 10:00 PST) : Schema review Overview of changes Discuss any issues Schema structure and tool issues Schema reuse discussion Next steps 1:00 to 1:10 EST (10:00 to 10:10 PST): Intros & adjust agenda for Document Object 1:10 to 3:00 EST (10:10 to 12:00 PST): Document Object review Priority issue discussion Page turn review Next steps ___________________________________________________ Dial in info: Dial-In #: +1 719-457-0335 Participant Password: 400908# ___________________________________________________ Webex info: TBD ___________________________________________________ Document Links: Document Object Specification: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip PWG Semantic Model Schema v0.91 (To be posted this week): http://www.pwg.org/sm/index.html PWG Semantic Model v0.27 (To be posted later today): ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030331.pdf ___________________________________________________ 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 From hastings at cp10.es.xerox.com Tue Apr 1 21:46:05 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From PZehler at crt.xerox.com Wed Apr 2 07:34:16 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> Semantic Model Teleconference 4/3 (Complete Information) Message-ID: All, The Semantic Model group will be holding a teleconference on Thursday April 3. The primary focus of the teleconference is to complete the review of the Document Object Specification. The current plan is to hold the teleconference from 12:00 to 3:00pm eastern (9:00am to 12:00 Pacific). The first hour we will discuss the latest schema (version 0.93). The agenda and teleconference information is included below. ___________________________________________________ Agenda: 12:00 to 12:10pm EST (9:00am to 9:10am PST): Intros & adjust agenda 12:10pm to 1:00pm EST (9:10am to 10:00am PST) : Schema review Overview of changes Discuss any issues Schema structure and tool issues Schema reuse discussion Next steps 1:00pm to 1:10pm EST (10:00am to 10:10am PST): Intros & adjust agenda for Document Object 1:10pm to 3:00pm EST (10:10am to 12:00 PST): Document Object review Priority issue discussion Process 9 outstanding issues Page turn review Next steps ___________________________________________________ Dial in info: Dial-In #: +1 719-457-0335 Participant Password: 400908# ___________________________________________________ Webex info: https://hp.webex.com/join/ Name: Semantic Model Date: 4/3/2003 Time: 12:00 EST(9:00am PST) Meeting Number: 29039952 Meeting Password: pwg_sm ___________________________________________________ Document Links: Document Object Specification: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip Document Object Outstanding Issues (9) http://www.pwg.org/hypermail/sm/0179.html PWG Semantic Model Schema v0.93: http://www.pwg.org/sm/index.html PWG Semantic Model v0.27: ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030331.pdf ___________________________________________________ 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 From hastings at cp10.es.xerox.com Wed Apr 2 21:23:31 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document obj ect tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: And a 10th issue for the Document Object spec: 10. At today's IPPFAX telecon, we discussed the following IPPFAX Printer Description attribute: digital-signatures-supported (1setOf type2 keyword) This attribute identifies which digital signatures technologies are supported by the Receiver. A Receiver MUST support this Printer Description attribute. TODO: Get list of keywords; can be found in "IPP driver install" spec We agreed that it should go in the IPP Document object spec, and that it should have a "digital-signature" (type2 keyword) operation/Document Description attribute that the client submits in a Document Creation operation as well. And therefore, the spelling of the corresponding "digital-signature-supported" (1setOf type2 keyword) Printer Description attribute should be without the "s". The description from the "IPP Driver Install" (IPP Printer Installation Extension) spec is: "digital-signature" One REQUIRED LOWER-CASE 'keyword' string identifying the mechanism used to ensure the integrity and authenticity of this set of Client Print Support Files. Standard values are: 'smime', 'pgp', 'dss', and 'xmldsig' which are defined in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively. In addition, the special keyword value: 'none' is valid. The 'none' value MUST be supported if this attribute is supported. Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 01, 2003 18:46 To: sm@pwg.org Cc: ps@pwg.org Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From hastings at cp10.es.xerox.com Thu Apr 3 20:16:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:30 2009 Subject: SM> Minutes of the IPP Document object spec call Message-ID: Here are the minutes of today's IPP document object spec call. I'll update the spec with these agreed changes and issue early next week for a telecon next Thursday, April 10, at the usual time. We'll do a page by page of the document. I'll highlight the changed sections (rather than using revision marks) to make it easier to read. Please read the document ahead of time, since you won't be able to read the document during the one hour telecon. Also send comments that you find to the mailing list. That will help speed up the discussion and resolution. Thanks, Tom <> <> -------------- next part -------------- A non-text attachment was scrubbed... Name: Minutes-IPP Document object telecon Thur Apr 3.doc Type: application/msword Size: 87040 bytes Desc: not available Url : http://www.pwg.org/archives/sm/attachments/20030403/f4d6fd9c/Minutes-IPPDocumentobjectteleconThurApr3.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Minutes-IPP Document object telecon Thur Apr 3.pdf Type: application/octet-stream Size: 62950 bytes Desc: not available Url : http://www.pwg.org/archives/sm/attachments/20030403/f4d6fd9c/Minutes-IPPDocumentobjectteleconThurApr3.obj From PZehler at crt.xerox.com Fri Apr 4 09:37:17 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:30 2009 Subject: SM> SM Meeting Minutes posted Message-ID: All, The meeting minutes for yesterday's teleconference are available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Minutes/PWG-SM-030403.pdf Send me any comments you have and I'll update the minutes. Pete PS to Gail Could you link the meeting minutes into the SM web page when you have a chance? Thanks 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 From PZehler at crt.xerox.com Tue Apr 8 12:43:25 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> PWG Semantic Model Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object. The document is not quite ready yet, but I wanted to make sure to get a meeting reminder out. Tom should be sending the document out later today. The teleconference is one hour long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) Page turner review of the Document Object specification Link to be provided by Tom later today 2) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY (Need comfirmation from Bob) ------------------------- Name: PWG Semantic Model Date: 4/10/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 (Need comfirmation from Bob) Meeting Password: pwg_sm (Need comfirmation from Bob) Host: Bob Taylor (HP) ___________________________________________________ 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 From imcdonald at sharplabs.com Tue Apr 8 14:49:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> PWG Semantic Model Teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF75@mailsrvnt02.enet.sharplabs.com> Hi Pete and Tom, Unfortunately, I will be out on the highway all day Thursday, so I'll miss the Document Object review. Darn. Cheers, - Ira PS - I'll also miss the next PSI last call telecon next Tuesday. -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, April 08, 2003 11:43 AM To: PWG Semantic Model WG (E-mail) Subject: SM> PWG Semantic Model Teleconference All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object. The document is not quite ready yet, but I wanted to make sure to get a meeting reminder out. Tom should be sending the document out later today. The teleconference is one hour long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) Page turner review of the Document Object specification Link to be provided by Tom later today 2) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY (Need comfirmation from Bob) ------------------------- Name: PWG Semantic Model Date: 4/10/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 (Need comfirmation from Bob) Meeting Password: pwg_sm (Need comfirmation from Bob) Host: Bob Taylor (HP) ___________________________________________________ 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 From hastings at cp10.es.xerox.com Wed Apr 9 07:54:04 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) Message-ID: I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From don at lexmark.com Wed Apr 9 16:07:59 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:31 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From harryl at us.ibm.com Wed Apr 9 18:45:51 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:31 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In-Reply-To: Message-ID: We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030409/e4cf8fd8/attachment.html From hastings at cp10.es.xerox.com Thu Apr 10 11:59:48 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030410/2bfcca2a/attachment.html From don at lexmark.com Thu Apr 10 14:07:58 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:31 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Tom: ANY use of the PWG machines for "production" purposes by either the printer itself, an application running on a computer platform or by an end-user administrator/installer is not something we (me or Lexmark) can support. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "Hastings, Tom N" on 04/10/2003 11:59:48 AM To: Harry Lewis , don@lexmark.com cc: ps@pwg.org, sm@pwg.org Subject: RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom (See attached file: C.htm) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030410/b322230e/iso-8859-1QC.html From PZehler at crt.xerox.com Fri Apr 11 15:03:06 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Extended PWG Semantic Model(Document Object) Teleconference Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference will cover the Document Object. The document we will use is unchanged from last week. It is available at > The teleconference is two hours long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > Please take the time to review this document so we can finish this document up. The changed text and current issues are highlighted in the document. Send any issues you uncover to the SM mail list. The 5 known issues will be sent out under separate cover on Monday. > The agenda for the Semantic Model teleconference is : > > 1) Page turner review of the Document Object specification > 2) Next steps > > > Pete > > PS: Bob, Let me know if you can not host the Webex. > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > > Webex MEETING SUMMARY (Need comfirmation from Bob) > ------------------------- > Name: PWG Semantic Model > Date: 4/10/2003 > Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) > 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) > Meeting Number: 21366675 (Need comfirmation from Bob) > Meeting Password: pwg_sm (Need comfirmation from Bob) > Host: > Bob Taylor (HP) > > ___________________________________________________ > > > > > 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 > > From PZehler at crt.xerox.com Tue Apr 15 10:41:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> My responses to existing issues and a reminder to be ready for Th ursday Message-ID: All, I hope you all are reading the Document Object specification and preparing for Thursday's teleconference. The Document Object specification we will use for review is still: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB Please forward any new issues or comments to the list. Below are my opinions on the 5 outstanding issues. Pete __________________________________________________________________________ ISSUE 1: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? Yes ISSUE 2: If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? It should also be valid to abort the job. In any event the JobState and JobStateReasons should give an indication to the client. I think we will need a new JobStateReason such as InvalidSignature. How does this apply to documents within a job? Do we (1) ignore the signature and print the document and job, (2) Put the job on hold and wait for human intervention (and what about partially printed jobs?) (3) abort the document and continue printing the job (4) abort the document and job (once again what about partially printed jobs. This would be cleaned up if we mandated that document-signatures are evaluated at submission time. This may not be practical given the latency involved in contacting the certificate authority ISSUE 3: This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The digital-signature should be treated as any other mandatory value with an invalid value. The job should be rejected, Document-signature and its value should be returned. This assumes the signature is evaluated at submission time. ISSUE 4: The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? I never thought that schemas would be retrieved real time from printers and print clients. I assumed that the namespace would indicate the schema used. Clearly Printers would not need to access the schema since it already knows what it has implemented and the instance document would be valid for the schema. Print clients do not need to know all the possible semantic elements and values. It only needs the elements and values for the target Printer. The client would have built in support for the PWG schema to validate a Printer's instance document against. That leaves a general purpose web service client that will somehow be able to derive and present the semantic meaning behind the PWG schema in a user friendly way. (yeah there are a lot of those out there) ISSUE 5: from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. These seem most useful for transformation services such as a PSI Server. Printers would probably try and describe the document formats they support in the most generic way. A transformation service may want to be very explicit about the source document formats it is able to transform into printer ready formats. Tom 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 From dcarney at us.ibm.com Tue Apr 15 19:16:28 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:31 2009 Subject: SM> Integrate "-actual" attributes into the document object spec Message-ID: In "Appendix A: Change Log" of the IPP "-actual" attributes extension (ftp://ftp.pwg.org/pub/pwg/ipp/new_ACT/pwg-ipp-actual-attrs-latest.pdf), is the following text: Version 0.3, 16 December 2002, as a result of the PWG Semantic Model telecon, December 12, 2002: 1. Removed all references to the document object. Extending this concept to the document object will be done in the document object specification only. In this way, moving this specification forward on the standards track will not be held up. As far as I can see, the concept of the "-actual" attributes has not been extended to the Document object in the latest version of the Document Object spec. I assume we still want to do this--is there any feeling otherwise among the group? If we *do* want to do this, how to do it? In fact, I'm not sure in reading the spec (maybe I missed it?) that it is ever made clear that Document Template attributes have corresponding "xxx-default" and "xxx-supported" attributes--is that because all Document Template attributes are also Job Template attributes and as such have "xxx-default" and "xxx-supported" attributes by definition (from 2911)? However, the "-actual" attributes are a bit different. For every *Document Template* attribute, there would be a corresponding *Document Description* "-actual" attribute. This fact cannot, I don't think, be considered to be implied by 2911 or by the "-actual" spec (which as shown above does not even mention the document object). So: ISSUE 1: In chapter 7, OK to add a mention of the extension of the "-actual" concept to the Document object? ISSUE 2: In addition, does the way that "xxx-default", "xxx-supported", and "xxx-ready" apply to the Document object need to be made more clear? In addition, in Table 7, which lists all the Operation attributes, there are columns for "xxx-default" and "xxx-supported". I guess the concept is to extend the concept of "xxx-default" and "xxx-supported" to certain Operation attributes, instead of simply having those concepts apply to Template attributes. ISSUE 3: In this case, would we want to do the same for "-actual"s? This is a complicated situation, I believe, since we already have two cases: 1) For job-impressions, job-k-octets, and job-media-sheets, we already have the concept that these are copied to Job Description attributes and that these three (and *only* these three, I believe) can be updated by the printer to contain a "more accurate" (see 2911, section 4.3.17) value than was provided. So for these, they are sort-of their own "actual" attribute. 2) For document-format and document-format-version, we have created new attributes to essentially be "actual" values: document-format-detected and document-format-version-detected. We created the "detected" name to make sure it was not confused with the "-actual"s, since the "-actual" concept (as written) doesn't extend to Operation attributes. My personal vote is to *not* extend the concept of "-actual"s to Operation attributes, but I wanted to bring it up to see what others think. My reason for not extending them is to keep the concept "clean"--it only applies to Template attributes, not to all Template attributes, plus those Operation attributes that have currently been identified as having them. Also, extending the concept to Operation attributes conflicts somewhat with the situation in #1 above--2911 says that those three *are* some sort of "actual"s. If we extend the concept, do we deprecate that behavior? But then clients that don't implement the document object will no longer get the same "results" from servers that do implement it. Comments anyone? Dennis Carney IBM Printing Systems From dhall at hp.com Wed Apr 16 13:53:38 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:31 2009 Subject: SM> Where to publish xsd / wsdl Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC70@xvan01.vcd.hp.com> Hey All.. As we create new WSDL and XSD documents, and their "simple" counterparts, where should we publish the schemas? I would propose the following: * The schemas should have the EXACT SAME NAMESPACE - this is required if the "on the wire" envelopes should look the same. * The Full schemas should be published where they are currently being published: (http://www.pwg.org/schemas//) * The simple schemas should be published at: (http://www.pwg.org/schemas//) What do you think? Dave From hastings at cp10.es.xerox.com Wed Apr 16 20:56:07 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> Integrate "-actual" attributes into the document object s pec Message-ID: Dennis, Thanks for the comments. Briefly: 1. I agree with you that the Document Template attributes need to be clarified that they share the same "xxx-default" and "xxx-supported" Printer attributes with the corresponding Job Template attributes. 2. I agree that we want the spec to extend Document Template attributes to have corresponding OPTIONAL "xxx-actual" Document Description attributes. 3. I agree that we don't want to extend the -actual concept to the Operation attributes that have corresponding "xxx-default" and "xxx-supported" Printer Description attributes. See my detailed replies bracked by and below. Tom -----Original Message----- From: Dennis Carney [mailto:dcarney@us.ibm.com] Sent: Tuesday, April 15, 2003 16:16 To: sm@pwg.org Cc: Harry Lewis Subject: SM> Integrate "-actual" attributes into the document object spec In "Appendix A: Change Log" of the IPP "-actual" attributes extension (ftp://ftp.pwg.org/pub/pwg/ipp/new_ACT/pwg-ipp-actual-attrs-latest.pdf), is the following text: Version 0.3, 16 December 2002, as a result of the PWG Semantic Model telecon, December 12, 2002: 1. Removed all references to the document object. Extending this concept to the document object will be done in the document object specification only. In this way, moving this specification forward on the standards track will not be held up. As far as I can see, the concept of the "-actual" attributes has not been extended to the Document object in the latest version of the Document Object spec. I assume we still want to do this--is there any feeling otherwise among the group? Yes, I would think we should extend the Document object to have "xxx-actual" Job Description attributes. If we *do* want to do this, how to do it? In fact, I'm not sure in reading the spec (maybe I missed it?) that it is ever made clear that Document Template attributes have corresponding "xxx-default" and "xxx-supported" attributes--is that because all Document Template attributes are also Job Template attributes and as such have "xxx-default" and "xxx-supported" attributes by definition (from 2911)? Yes, the spec could be clearer that Document Template attributes are just the same as Job Template attributes and share the same "xxx-supported", "xxx-default", and "xxx-ready" Document Template Printer attributes with the Job Template attributes. However, the "-actual" attributes are a bit different. For every *Document Template* attribute, there would be a corresponding *Document Description* "-actual" attribute. This fact cannot, I don't think, be considered to be implied by 2911 or by the "-actual" spec (which as shown above does not even mention the document object). Agree, so need to add some statement to the Document Description Attributes section about there being corresponding "xxx-actual" Document Description attributes for each Document Template attribute. So: ISSUE 1: In chapter 7, OK to add a mention of the extension of the "-actual" concept to the Document object? Yes. ISSUE 2: In addition, does the way that "xxx-default", "xxx-supported", and "xxx-ready" apply to the Document object need to be made more clear? Yes. In addition, in Table 7, which lists all the Operation attributes, there are columns for "xxx-default" and "xxx-supported". I guess the concept is to extend the concept of "xxx-default" and "xxx-supported" to certain Operation attributes, instead of simply having those concepts apply to Template attributes. Yes. ISSUE 3: In this case, would we want to do the same for "-actual"s? But I don't think that we want to extend these Operation attributes that have "xxx-default" and "xxx-supported" to also have "xxx-actual" Document Description attributes. The one that we do have is "document-format-details-detected", so named since it isn't a -actual, just as we have done for the "document-format" operation attribute with "document-format-detected". This is a complicated situation, I believe, since we already have two cases: 1) For job-impressions, job-k-octets, and job-media-sheets, we already have the concept that these are copied to Job Description attributes and that these three (and *only* these three, I believe) can be updated by the printer to contain a "more accurate" (see 2911, section 4.3.17) value than was provided. So for these, they are sort-of their own "actual" attribute. True. 2) For document-format and document-format-version, we have created new attributes to essentially be "actual" values: document-format-detected and document-format-version-detected. We created the "detected" name to make sure it was not confused with the "-actual"s, since the "-actual" concept (as written) doesn't extend to Operation attributes. Yes. My personal vote is to *not* extend the concept of "-actual"s to Operation attributes, but I wanted to bring it up to see what others think. My reason for not extending them is to keep the concept "clean"--it only applies to Template attributes, not to all Template attributes, plus those Operation attributes that have currently been identified as having them. Also, extending the concept to Operation attributes conflicts somewhat with the situation in #1 above--2911 says that those three *are* some sort of "actual"s. If we extend the concept, do we deprecate that behavior? But then clients that don't implement the document object will no longer get the same "results" from servers that do implement it. I agree with you that we don't want to extend these Operation attributes that have "xxx-default" and "xxx-supported" to also have "xxx-actual" Document Description attributes. The one that we do have is "document-format-details-detected", so named since it isn't a -actual, just as we have done for the "document-format" operation attribute with "document-format-detected". Comments anyone? Dennis Carney IBM Printing Systems From hastings at cp10.es.xerox.com Wed Apr 16 21:20:25 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> document-creator-application-version ISSUE: For human or program consumption? Message-ID: The CIP4 System Behaviour and Interoperability WG reviewed the corresponding FileSpec attributes and pushed back on the equivalent of the "document-creator-application-version" Operation/Document Description attribute as being for human consumption. They thought it would be needed by consuming programs to know how to process the data for those formats which different versions had different semantics. The current spec is as follows: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)" When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "Winzip* 8.1", "Acrobat 5.0", and "Microsoft* Word 2000" as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. The following fix would keep the definitions alligned, if the PWG also agrees that this attribute is for program consumption: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for purpose of affecting the interpreting by the Printer for any formats for which the creator application version might have different semantics. They value MAY include build or service pack numbers. Examples: "8.1 (4331)" for Winzip* , "5.0.5 10/26/2001" for Acrobat*, "2000 (9.0.4119 SR-1)" for Microsoft* Word When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "8.1", "5.0", and "2000", respectively, as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. Comments? Tom From AMcCarthy at crt.xerox.com Thu Apr 17 13:00:42 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:31 2009 Subject: SM> document-creator-application-version ISSUE: For human or program consumption? Message-ID: Tom, I agree with the change you are recommending. Because semantics can change significantly from one version of an application to another - I recommend upgrading this to a required attribute. Regards, Ann -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 16, 2003 9:20 PM To: sm@pwg.org Subject: SM> document-creator-application-version ISSUE: For human or program consumption? The CIP4 System Behaviour and Interoperability WG reviewed the corresponding FileSpec attributes and pushed back on the equivalent of the "document-creator-application-version" Operation/Document Description attribute as being for human consumption. They thought it would be needed by consuming programs to know how to process the data for those formats which different versions had different semantics. The current spec is as follows: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)" When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "Winzip* 8.1", "Acrobat 5.0", and "Microsoft* Word 2000" as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. The following fix would keep the definitions alligned, if the PWG also agrees that this attribute is for program consumption: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for purpose of affecting the interpreting by the Printer for any formats for which the creator application version might have different semantics. They value MAY include build or service pack numbers. Examples: "8.1 (4331)" for Winzip* , "5.0.5 10/26/2001" for Acrobat*, "2000 (9.0.4119 SR-1)" for Microsoft* Word When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "8.1", "5.0", and "2000", respectively, as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. Comments? Tom From hastings at cp10.es.xerox.com Thu Apr 17 17:00:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From harryl at us.ibm.com Fri Apr 18 13:16:11 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:31 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: Message-ID: I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030418/fc1bc6f2/attachment.html From imcdonald at sharplabs.com Fri Apr 18 14:34:17 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8B@mailsrvnt02.enet.sharplabs.com> Hi Michael, Tom's notes are actually incomplete. A conforming implementation MUST support at least one scheme (I suggested we RECOMMEND that 'http:'), but an administrator _at_run_time_ may choose to disable this feature by reconfiguring "reference-uri-schemes-supported". I proposed making this operation (Send-URI) mandatory. But only if ALL implementations MUST support at least one reference scheme and SHOULD support 'http:' (note that PSI servers MUST support 'http:' for the AddDocumentByReference method). I contend that the burden of adding a minimal HTTP client to an existing IPP-based printer is minimal. That's the question. Cheers, - Ira McDonald -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Friday, April 18, 2003 6:50 AM To: Hastings, Tom N Cc: sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec [My initial comments; I still haven't finished going through the document object spec, so I may have more comments early next week] Hastings, Tom N wrote: > ... > 1. Change the Send-URI operation and the corresponding > "reference-uri-schemes-supported" (1setOf uriScheme) Printer > Description attribute from OPTIONAL to REQUIRED for a Printer to > support. We agreed that a conforming implementation MAY have an > empty list for the "reference-uri-schemes-supported" Printer > Description attribute. So in essense you are just changing the status code from server-error-operation-not-supported to client-error-uri-scheme-not-supported. > Reason: PSI requires this operation (and has no OPTIONAL > attributes). Optional operations are much less likely to get support > by clients. It is best practice for an OPTIONAL extension > specification (such as this spec) to have no OPTIONAL operations, so > that user clients will receive the same level of service from all > Printer implementations that support this extension. This reasoning makes no sense since you are also saying that "reference-uri-schemes-supported" can be an empty list, which means that you still have no service from an implementation that doesn't really support Send-URI. Also, I still question the usefulness of Send-URI and Print-URI since security issues (authentication and access control) make implementation for non-trivial URIs difficult, if not impossible. > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... (I didn't get messages about either on the IPP list) > 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for > the "pdl-overrides-supported" Printer Description attribute (REQUIRED > in [rfc2911] section 4.4.28) to augment 'not-attempted', and > 'attempted' values. Also add a REQUIRED > ... OK, no problem with this. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Fri Apr 18 14:38:46 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From dcarney at us.ibm.com Fri Apr 18 16:45:20 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:31 2009 Subject: SM> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: My comments below marked by . A couple overall comments: 1) It seems like the Document object spec is becoming a grab-bag for all the ideas we come up with, whether they make sense as part of the Document object or not--the spec risks becoming a "Here's a bunch of things that we thought of that would make IPP cooler" spec. 2) I don't like the argument that we should not have OPTIONAL things in the Document object spec. Here are some reasons: - Even if we did what was proposed below, there would still be many, many OPTIONALs in the spec. If we really believe in our argument, those should all be REQUIRED, right? No? Why not? Oh, so there *is* a line between what should be OPTIONAL and what should be REQUIRED? Well, if there *is* a line, that sort of invalidates our argument that there shouldn't be any OPTIONALs. - The Document object spec has become more than just an extension. I think it is seriously rivaling RFC2911 in term of complexity (not in pages, but in complexity, with all those tables for example). This is NOT a criticism--having a Document object is a good idea and this spec is a very good one. But once a spec gets as complex as this one, it is unreasonable to consider it as just an extension that can have the "luxury" of not having any OPTIONALs. Dennis Carney IBM Printing Systems -------------------------------------------------- 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. PSI and IPP are different. Look at the PSI "Use Cases" from the Developers Guide--there are no "Joe is at his desk and wants to print to the printer down the hall" use cases. That's not the point of PSI. PSI is very web-oriented, and as such, it makes sense to print by reference. With IPP, printing by reference is really not mainline, so it should be optional. And what does Send-URI have to do with the document object? Ok, it is a way to send a document, but the Document object spec should describe the Document object, NOT try to redefine the way IPP works, imho. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. It seems to have been a long-standing tradition in IPP that the ability to do "Set"s is optional. I don't see why this should change now. What is so special about Set-Document-Attributes? Why aren't we mandating the other "Set" operations as well while we're at it? 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. I have less problem here since we aren't going to REQUIRED, but my last comment is valid here as well. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. The 'guaranteed' value: So you are only listing this value that already exists in another spec in the interest of trying to get the value to be "official" as quick as possible? I guess I can't argue with that, but it does seem a bit strange to me. I guess [ippsave] is going to be updated to refer to the Document object spec rather than define this new value? The "pdl-override-attributes-guaranteed" attribute: I agree that this was a shortcoming of IPP--the printer had no ability to say which attributes it could override and which it couldn't. I wonder about its applicability to the Document object, but... From hastings at cp10.es.xerox.com Fri Apr 18 19:15:18 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From hastings at cp10.es.xerox.com Fri Apr 18 22:10:36 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: Michael, Thanks for your comments. See my replies bracketed by ... Michael wrote: ... > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? (It's Table 6 in the April 7 spec, which regrettably was not announced on the IPP DL, only on the SM and PS DLs. Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip ) Yes, the transition table doesn't allow the client to modify a document with Set-Document-Attributes after the Document has 'completed', 'aborted', or 'canceled'. This same transition table is in the published RFC 3380 for the Set-Job-Attributes operation as well. The reason is that a completed, canceled, or aborted job/document should have the record of what was requested, for accounting and/or the help desk trying to figure out what went wrong. If you want to modify a job and resubmit it as in your example to change the number of copies and reprint: the idea is that the client does a Restart-Job (or Reprocess-Job) with the "job-hold-until" operation attribute supplied (see [RFC 2911] section 3.3.7, Restart-Job(. Then the client can modify it with Set-Document-Attributes while the job is in the 'pending-held' state. Then the client can release the modified job for printing with Release-Job (section 3.3.6). > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Set-Job-Attributes wasn't in the March 24th draft or the April 7 th draft. However, in proposing to REQUIRE the Set-Document-Attributes operation it seemed reasonsable to increase the requirements for the Set-Job-Attributes operation to at lease RECOMMENDED. But that is what we are asking for feed back on. So in order to conform to the IPP Document object spec, it is RECOMMENDED that the Printer also support Set-Job-Attributes. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip There wont' be a new spec either. We're continuing the page by page. Please send any othre comments and/or join the next telecon, Thursday, April 24, 1-3 PM EDT: > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# We're also using webex: > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- The meeting number and password will be announced next week. ... From harryl at us.ibm.com Sat Apr 19 12:03:05 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:31 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Message-ID: 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030419/ba7a2581/attachment.html From imcdonald at sharplabs.com Sat Apr 19 16:57:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8E@mailsrvnt02.enet.sharplabs.com> Hi Harry, 1) Support for modifying document object after submission is present in the FetchJobs interface that can OVERRIDE existing job or document attributes as the job flows from PSI Print Service to PSI Target Device. Whereas IPP Resubmit/Restart do NOT allow the attributes to be modified in the operation but require "job-hold-until" to be set to allow SUBSEQUENT use of the (OPTIONAL) Set-Job-Attributes. But what I meant below was: Send-Document and Send-URI are both OPTIONAL in IPP/1.1, but the AddDocumentByValue and AddDocumentByReference are REQUIRED in PSI/1.0. Since we are only just now adding Document objects to IPP, I simply propose that we offer PSI-equivalent capabilities in the protocol (for implementations of the Document object specification _only_). 2) I agree that PDL override is hard to implement (in _some_ PDLs), but what Tom and I have proposed is to disambiguate _which_ attributes (if any) can be guaranteed to successfully override the PDL. Seems to me like a good clarity enhancement to IPP. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Saturday, April 19, 2003 11:03 AM To: McDonald, Ira Cc: Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From imcdonald at sharplabs.com Sun Apr 20 16:54:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> RE: [SPAM] RE: IPP> 4 significant proposed increases in conforman ce requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF92@mailsrvnt02.enet.sharplabs.com> Hi Michael, Inline comments below. Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:11 PM To: McDonald, Ira Cc: Hastings, Tom N; sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: [SPAM] RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec McDonald, Ira wrote: > ... > Tom's notes are actually incomplete. A conforming implementation > MUST support at least one scheme (I suggested we RECOMMEND that > 'http:'), but an administrator _at_run_time_ may choose to disable > this feature by reconfiguring "reference-uri-schemes-supported". Well, then you will likely find very few implementations. We've been working on Print-URI/Send-URI support for CUPS 1.2 and the authentication/security/performance issues are a real hassle for a real-world implementation. Also, you can be sure that any CUPS implementation of the spec WILL NOT enable print-by-reference by default for serious security reasons, and there will be extremely high barriers in place to limit how and where you can print from. > I proposed making this operation (Send-URI) mandatory. But only > if ALL implementations MUST support at least one reference scheme > and SHOULD support 'http:' (note that PSI servers MUST support > 'http:' for the AddDocumentByReference method). Is there any practical reason why PSI can't just require stricter requirements than the basic IPP mapping? It seems idiotic to require print-by-reference for IPP whose goals are different than PSI. _my_ goal is full-bandwidth application gateways between IPP and PSI. Everywhere that IPP doesn't have a feature at all (the out-of-band push in PSI's AddDocumentByPush) or has made a feature optional (PSI's AddDocumentByReference), the gateway will fail entirely. Note, PSI _is_ sending (over a TLS-secured channel) whatever username and password or certificate necessary to do the SMTP, IMAP, HTTPS, or whatever connection for the AddDocumentByReference, from the client embedded in the PSI Print Service or Target Device. If this is security nightmare for IPP, then the same applies to PSI - why is it so hard if the Print Service simply impersonates the end user? (I know this can't work if the end user's TLS certificate is restricted to access from a pre-configured source FQDN for the end user's system, but that problem _isn't_ soluble.) > I contend that the burden of adding a minimal HTTP client to an > existing IPP-based printer is minimal. That's the question. For a server that will only handle a single connection at a time, and for simple accesses without authentication, it can be implemented fairly easily. However, for any non-trivial implementation there are authentication, security, and performance issues that MUST be dealt with. Consider a typical web application like email which uses HTTP authentication, cookies, encryption, and probably some sort of host/ip-based session key; a print-by-reference approach is doomed to fail even if we can pass all of the required info to the IPP server, since it will somehow have to re-login and go to the right URL. Assuming it *does* work somehow, you need to securely manage this authentication information or risk compromising a remote system. I don't doubt that there is some minimal functionality that can be provided by Print-URI and friends, however the cost/benefit ratio is too high and I believe will hurt adoption of the document object spec. Well, print by reference is the main design center of PSI, so if it will hurt adoption of IPP Document objects, then it will equally hurt PSI adoption. Do you think PSI is in trouble?? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Sun Apr 20 16:44:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF91@mailsrvnt02.enet.sharplabs.com> Hi Michael, Actually scaling, centering, and cropping are all addressed for IPPFAX (extensions that will certainly migrate to general IPP/1.1 implementations). Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:14 PM To: McDonald, Ira Cc: 'Harry Lewis'; Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: Re: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec McDonald, Ira wrote: > ... > 2) I agree that PDL override is hard to implement (in _some_ PDLs), but > what Tom and I have proposed is to disambiguate _which_ attributes > (if any) can be guaranteed to successfully override the PDL. Seems > to me like a good clarity enhancement to IPP. PDL override is not even well-defined; what do you do with a PDF file that was formatted for a different media size? Scale it? Center it? Crop it? What constitutes an override??? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hastings at cp10.es.xerox.com Mon Apr 21 12:08:26 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:31 2009 Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From dcarney at us.ibm.com Mon Apr 21 12:11:46 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:31 2009 Subject: SM> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: This might be an awful idea, so feel free to shoot it down with vicious force... Based on the desire to have extensions that do not include OPTIONAL items, might it make sense to break the current Document object spec into two: - The "Base Document object" spec, which defines the basics of the Document object and has no OPTIONAL items: everything is mandatory. This would make interop a breeze, and would hopefully also encourage adoption since the spec would hopefully be relatively small. - The "Extended Document object" spec, containing all the currently OPTIONAL items. This spec *could* also make all the extensions mandatory (I would think that making absolutely *everything* mandatory would discourage adoption, however). The process of going through the current spec to determine which items are "Base" and which are "Extended" might also result in determining which items aren't "Document object" items at all. Dennis Carney IBM Printing Systems Mike Sweet To: "Hastings, Tom N" Sent by: cc: sm@pwg.org, ps@pwg.org, ipp@pwg.org owner-ipp@pwg.org Subject: Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec 04/19/03 08:54 PM Hastings, Tom N wrote: > ... > 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the > Jobs following the limit requested in a previous request. > > So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. This is a nice addition, but has ABSOLUTELY NOTHING TO DO WITH DOCUMENT OBJECTS. It doesn't belong here. If anything, you should put together a single, small spec that adds this functionality to Get-Jobs separately. A pain, but this single attribute is useful on its own. Also, you probably need to have a way to let the client know that this attribute is supported, e.g. "start-after-job-id-supported (boolean)"... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From dcarney at us.ibm.com Mon Apr 21 18:52:41 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:31 2009 Subject: SM> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: I think that these ideas are good ones. However, I wonder why we didn't do anything about this before. In fact, in 2911, it is specifically called out that we purposely didn't handle this situation (2911, section 3.2.6.1: "There is no mechanism to allow for the next 'M' jobs after the first 'N' jobs."). Does anyone remember whether there was a good reason this issue was sidestepped? I've made 3 specific comments inline below, marked with . Dennis Carney IBM Printing Systems "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: IPP> 2 more significant proposed increases in conformance requirements for the IPP owner-ipp@pwg.org Document object spec 04/18/03 05:15 PM In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. We need to say what happens if job-id M is no longer in the list. I think the answer could be different for the two cases (non-completed vs. completed), making this a bit more complicated. If asking for *non-completed* jobs after job-id M, it is possible that M has completed since the client made the last call and is therefore no longer in the non-completed list. Unfortunately, this gets messy: 1) If M completed successfully, the printer should return the first N non-completed jobs (i.e. the same as if M hadn't been specified at all). 2) If M was canceled/aborted, it seems like the printer should ideally return the next job after M, *if* M hadn't been canceled/aborted. This extra attempt at correctness is, I guess, not really necessary, since the text below states that the caller can get strange results. Otherwise, if asking for *completed* jobs after job-id M, it is possible that M has been managed out of the completed list since the client made the last call. In *this* case, since completed jobs are returned in the opposite order of non-completed jobs, the printer should return an empty list. That is, since completed jobs are returned from newest to oldest, if M was managed out, jobs "after" (but actually printed before!) M are presumably also managed out, so there are actually no jobs "after" M in the completed list. This is the "correctly functioning" case of job-id M not being in the list, but there is also the "error" case where job-id M is just a bad value--it does seem strange to mandate that the printer return an empty list and success whenever the caller sends a bad "start-after-job-id" value. Maybe we want some new status-code: something like client-error-bad-start-id. Or we could possibly reuse client-error-gone or client-error-not-possible or some other existing status-code. Then there is just one answer for all the above cases: if M is not in the list, return an error and let the client decide what to do. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. Editorial: The above paragraph would flow better without the fourth sentence (the one starting "If the client supplies..."). 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Due to the fact that deleted Documents disappear, we have the same problem as discussed above: Document number M might no longer exist. The expected behavior for this should be similar to that decided upon for jobs, I would think; however, for Document objects, the "ideal" behavior would be to return the Documents starting with the first after Document M that hasn't been deleted. Unfortunately, this "pretend like M is still there" strategy doesn't really work as a general solution in the Get-Jobs case. Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From dcarney at us.ibm.com Mon Apr 21 19:14:18 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:31 2009 Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: I'm a bit confused: I had the (apparently flawed) impression that the plan was to deprecate, for a client, using the "last-document" operation attribute entirely--that is, say the "correct" way to say a job was done was to do Close-Job. If we do that, we will by definition deprecate the special case you're discussing below, right? Am I thinking of PSI or maybe SM? Since deprecation is only a suggestion, might it make sense to deprecate "last-document" entirely? (The Printer will still have to support it, but we're encouraging clients to move to Close-Job.) Do we want to make such a stand? Dennis "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec owner-sm@pwg.org 04/21/03 10:08 AM In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From PZehler at crt.xerox.com Tue Apr 22 10:19:38 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Extended PWG Semantic Model(Document Object) Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will continue the review of the Document Object. We will continue to use the April 7 version of the document. It is available at The teleconference is two hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. Please take the time to review this document and comment on the outstanding issues so we can finish this document up. The changed text and current issues are highlighted in the document. Send any issues you uncover to the IPP mail list. The agenda for the Semantic Model teleconference is : 1) Continue page turner review of the Document Object specification 2) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY (Need confirmation from Bob) ------------------------- Name: PWG Semantic Model Date: 4/34/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From PZehler at crt.xerox.com Mon Apr 28 15:33:20 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Extended PWG Semantic Model(Document Object Final) Teleconference Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference should complete the review of the Document Object. > > We will continue to use the April 7 version of the document. It is > available at > > > The teleconference is two hours long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > > The agenda for the Semantic Model teleconference is : > > 1) Finish discussion of any issues raised > > 2) Next steps > > > Pete > > PS: Bob, Let me know if you can not host the Webex. > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > > Webex MEETING SUMMARY (Need confirmation from Bob) > ------------------------- > Name: PWG Semantic Model > Date: 5/1 /2003 > Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) > 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) > Meeting Number: 21366675 > Meeting Password: pwg_sm > Host: > Bob Taylor (HP) > > ___________________________________________________ > > > > > 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 > > > From PZehler at crt.xerox.com Wed May 7 14:32:47 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> No teleconference this week. Message-ID: All, I am busy trying to break the Document Object document into 3 separate documents. I will get them out as soon as possible. The objective is to begin the review next week. 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 From PZehler at crt.xerox.com Fri May 9 13:05:53 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Page Overrides Spec Message-ID: All, Here is the link to the Page Overrides spec that hopefully will supercede the trial use PWG 5100.4. The Document Object specification will take care of overrides at the document level. (I should have that out soon.) This document covers page overrides. I also removed the non-override specific attributes out and will include them in one to the specifications being broken out from the Document Object specification. (I should have that out early next week) Take a look at it. It is 17 pages long including boilerplate. I have 2 issues identified. Any discussion of the specification should take place on the IPP list. Pete ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030509.pdf 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 From PZehler at crt.xerox.com Fri May 9 15:30:37 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> First breakout document for Document Object Message-ID: All, Here is my first installment of splitting the document object up into 3 documents. This document covers the Document Object extension to IPP. I would appreciate any comments since I may have cut out things that shouldn't be, left things in that should be out or made other changes that aren't correct. I hope to have the other main document out early next week that will cover the extensions that were added to the document object but are not critical to its definition, some things cut out of the old overrides document as well as things from IPPFAX and PSI. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509pdf.zip Also available is the doc version with and without revision marks. ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509docrev.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509doc.zip 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: Zehler, Peter > Sent: Friday, May 09, 2003 1:06 PM > To: PWG Semantic Model WG (E-mail); IPP Discussion List (E-mail) > Subject: Page Overrides Spec > > All, > Here is the link to the Page Overrides spec that hopefully will supercede > the trial use PWG 5100.4. The Document Object specification will take > care of overrides at the document level. (I should have that out soon.) > This document covers page overrides. I also removed the non-override > specific attributes out and will include them in one to the specifications > being broken out from the Document Object specification. (I should have > that out early next week) > > Take a look at it. It is 17 pages long including boilerplate. I have 2 > issues identified. Any discussion of the specification should take place > on the IPP list. > > Pete > > ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030509.pdf > > 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 > > From PZehler at crt.xerox.com Mon May 12 08:41:08 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Semantic Model Teleconference (New Document Specification) Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the new Document Object specification. The new Document Object Specification is the first of 3 specifications to be split out from the previous version. This specification is limited to the Document Object extension to IPP. The specification has been available since Friday. This is the first of the documents that has been broken out of the previous specification. There are currently 2 issues in this specification. Please raise any additional issues on the IPP mailing list. The teleconference is scheduled for one hour. If the conversation is productive we can extend the meeting up to 2 hours. The meeting will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509pdf.zip The agenda for the Semantic Model teleconference is : 1) Discuss the new specification a) Collect comments b) Raise issues c) Resolve issues 2) Plan how to drive this and associated documents to closure a) Relationship between this spec (a), the JobX spec (b), the futures spec (c), and the Override spec b) Schedule for closure and dependencies between specs c) Semantic Model and Schema updates d) Work items for Portland Face-to-Face 3) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 4/10/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From imcdonald at sharplabs.com Mon May 12 20:19:41 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> FW: WBMM> XML Schema of RFC 1759 - valid in XMLSPY Message-ID: <116DB56CD7DED511BC7800508B2CA53735CFC8@mailsrvnt02.enet.sharplabs.com> FYI, - Ira McDonald -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, May 12, 2003 8:12 PM To: wbmm@pwg.org Subject: WBMM> XML Schema of RFC 1759 - valid in XMLSPY Hi folks, I've just opened this machine translation of RFC 1759 (Printer MIB v1) with XML SPY and it validated without warnings as a free-standing schema (no imports required). The whole original RFC 1759 text (i.e., all the documentation, Cathy M) is captured in XML comments in this XML schema translation. The XML Schema (.xsd) is 157KB. The ZIP file is 23KB at: ftp://ftp.pwg.org/pub/pwg/wbmm/schemas/rfc1759-20030512.zip Now anyone can define some new grouping or subset grouping of elements from the Printer MIB by simply defining a second XML schema that imports the elements and type definitions from this base schema. I'm still working on the translation tool: 1) I want to add a final object 'Printer-MIB' that is a sequence of: a) all table elements; and b) all scalar elements (not columns in some table definition), which can be keyed by a local key that holds that _value_ of 'hrDeviceIndex' (but _not_ actually import 'hrDeviceIndex' from RFC 2790). Presently the highest containment is at the table level. 2) I want to enhance my translator to accept old-style SMIv1 MIBs as _input_ and translate them also to XML schema (most vendor private MIBs are still written in SMIv1 - some vendors have migrated to SMIv2). This may take some while (SMIv1 is both simpler and _different_ from SMIv2 - less information is available for machine translation). 3) I want to add a verbose symbol map feature to my translator. (The current verbose log covers only errors). 4) I need to test translate a number of other IETF standards track MIBs to catch corner cases in my translator. Comments are welcome. Cheers, - Ira McDonald High North Inc From PZehler at crt.xerox.com Mon May 19 14:25:52 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Semantic Model Teleconference (Document Specification) Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object specification. The Document Object Specification is the first of 3 specifications to be split out from the previous version. This specification is limited to the Document Object extension to IPP. I will post the document shortly. The teleconference is scheduled for one hour. If the conversation is productive we can extend the meeting up to 2 hours. The meeting will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509pdf.zip The agenda for the Semantic Model teleconference is : 1) Discuss the new specification section by section a) Collect comments b) Raise issues c) Resolve issues 3) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 5/22/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From PZehler at crt.xerox.com Mon May 19 15:36:37 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Semantic Model (doc obj) Teleconference (Complete/correct informa tion) Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object specification. The Document Object Specification is the first of 3 specifications to be split out from the previous version. This specification is limited to the Document Object extension to IPP. The teleconference is scheduled for one hour. If the conversation is productive we can extend the meeting up to 2 hours. The meeting will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519pdf.zip Also available are the Word and rev versions and the meeting minutes that were used for the edits. ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519pdf.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519pdfrev.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519doc.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519docrev.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/Minutes-IPP-doc-object-20030501.pdf The agenda for the Semantic Model teleconference is : 1) Discuss the new specification section by section a) Collect comments b) Raise issues c) Resolve issues 3) Next steps Pete PS:Alan, Let me know if something comes up and you are unable to host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 5/22/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 22820422 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ 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 From PZehler at crt.xerox.com Tue May 27 13:09:50 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Page Override Review Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Page Overrides and replacing the deprecated 5100.4-2001. (The document contains 20 pages. The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) PWG Semantic Model & Schema status 2) Walk through issues and sections in the Override spec The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030527.pdf 3) Next Steps Pete PS: Alan, Let me know if there is a problem with you hosting the WebEx 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 Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 5/22/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 22820422 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ From PZehler at crt.xerox.com Wed May 28 14:58:55 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Corrected info for Page Override Review telecon Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Page Overrides and replacing the deprecated 5100.4-2001. (The document contains 20 pages. The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) PWG Semantic Model & Schema status 2) Walk through issues and sections in the Override spec The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030527.pdf 3) Next Steps 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 Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: Semantic Model Date: 5/29/2003 Time: 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 26605116 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ From imcdonald at sharplabs.com Fri May 30 19:09:05 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> PWG SM bindings for new RepertoireSupported element Message-ID: <116DB56CD7DED511BC7800508B2CA53735D00F@mailsrvnt02.enet.sharplabs.com> Hi Elliot, Friday (30 May 2003) Per our conversation this afternoon, below is the complete verbatim text of Appendix C for the CR spec. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ C. Bindings to the PWG Semantic Model (Normative) To add the RepertoireSupported element to the PWG Semantic Model, the following XML Schema fragments SHALL be added to the specified files. Add the following simple type to the file 'PwgWellKnownValues.xsd': Add the following element reference to the file 'PrinterDescription.xsd' in the complex type "PrinterDescription": Add the following simple element to the file 'PrinterDescription.xsd' after the complex type "PrinterDescription": RepertoireWKV KeywordNsExtensionPattern From PZehler at crt.xerox.com Mon Jun 2 14:11:35 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Overrides Telecon *NEW NUMBER & PASSCODE* Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Page Overrides that is replacing the obsolete 5100.4-2001. (The document contains 20 pages. About 4 pages have changed significantly) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is : 1) Review each section of the spec with particular attention to the highlighted portions. 2) Next Steps & plan to get to Last Call The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030602.pdf Pete PS to Alan: Let me know if you can not host the Webex 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 Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: Semantic Model Date: 6/5/2003 Time: 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 26605116 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ From dcarney at us.ibm.com Thu Jun 5 09:30:03 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:31 2009 Subject: SM> Some comments on the Overrides spec Message-ID: All, Unfortunately, I am not going to be able to make the telecon today discussing the Overrides spec. I have sent Pete an email with some editorial updates to the Overrides spec, and also have some comments. My comments have to do with Table 2, "Job Template Attribute Override Scope". 1) I think some explanation of the "min" and "max" columns is needed. If nothing else, it needs to be made clear what the "order" of the scopes is. I assume that going from min to max it is: page, impression, sheet, document, job. I think an explanation would help in understanding why the values that are there have the values they do. 2) I assume that you are going to discuss today whether the values for the min and max scopes in the table are correct. I believe that the folks who have been very active in the Document object for a long time know this stuff much better than I do, but some of the values seem suspect to me. A few questions I had: a) "cover-back" and "cover-front" seem to me to be Document scope. b) Why would "feed-orientation" have different scopes than "media"? c) Without the Document object, it is actually possible to specify "insert-sheet", "output-bin", and "separator-sheets" at either the Document or the Job level? I hope these comments are not silly! 3) By the way, if by chance a long involved discussion ensues about what the values should be for each attribute, would it maybe be an alternative to replace the min and max columns with one single column that says simply whether the attribute is a valid Override or not? In theory, that is what this table is trying to convey, isn't it? 4) There are some rows that have a ** after the attribute name--is there a missing table footnote, or should the ** be deleted? 5) Is the reference for "pages-per-subset" correct? Dennis From PZehler at crt.xerox.com Mon Jun 9 15:17:04 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> JobX Telecon *NEW NUMBER & PASSCODE* Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Jobx. I will post the document later today. This review will prepare the document for the Face-to-Face. The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is : 1) Discuss the remaining issue and reach consensus The following issue came up during the Review of the JOBX specification on June 4, which affects the Job Extension spec, the Document Object spec, and the PWG Semantic Model spec. For IPP there are the following Operation attributes that a client MAY supply in a Print-Job or Print-URI operation for specifying Document Attributes that do not have corresponding Description attributes defined until the Document Object specification: compression (type2 (keyword)) document-charset (charset) document-digital-signature (type2 (keyword)) document-format (mimeMediaType) document-format-details (1setOf (collection)) document-format-version (text(127)) document-message (text(MAX)) document-name (name(MAX)) document-natural-language (naturalLanguage) The preceding attributes are attributes of a Document. Therefore, unless the Document object is implemented, it is not possible for a client to completely determine what a client had submitted. As a consequence, it is also not possible for an application to completely archive a single document job using the Get-Job-Attributes operation. Furthermore FSG is using these attributes at the Job level in its APIs. When implementing the Document object, these same attributes can be supplied in the Send-Document and Send-URI operation as well. These attribute have slightly different semantics at the Job level than they do at the Document level. A solution for IPP JOBX (whether or not implementing the Document object) would be to define corresponding Job Description attributes for these specific operation attributes with the semantics that they are the defaults for the all the Document objects in the Job (even single document jobs created with Print-Job and Print-URI). These new Job Description attributes would be : compression-default (type2 (keyword)) document-charset-default (charset) document-digital-signature-default (type2 (keyword)) document-format-default (mimeMediaType) document-format-details-default (1setOf (collection)) document-format-version-default (text(127)) document-message-default (text(MAX)) document-name-default (name(MAX)) document-natural-language-default (naturalLanguage) These new attributes would be populated by the associated operational attribute if supplied. The file for telecon is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030609.pdf NOTE: This file does not include the above proposal for the remaining issue. However, given the time and my schedule I wanted to get something out. If possible I will get an update out later this week. The main issue and resolution proposal is explained fairly well above. Pete ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, June 12, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From imcdonald at sharplabs.com Tue Jun 17 22:55:21 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> Prototype PWG Job Ticket schema - 17 June 2003 Message-ID: <116DB56CD7DED511BC7800508B2CA53735D05D@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (17 June 2003) Earlier today, I suggested that writing a PWG Job Ticket compatible with the FSG Job Ticket API was a small effort. Apropos, I wrote one... It's appended below and also posted at: ftp://ftp.pwg.org/pub/pwg/Semantic-Model/JobTicket-20030617.xsd Also below is a complete mapping from the JobTicketInfo object in the latest UML diagrams of the FSG Job Ticket API to objects and elements defined in the latest (0.93) PWG Semantic Model. My source documents for this mapping and prototype schema were: ftp://ftp.pwg.org//pub/pwg/fsg/jobticket/JTAPI_Diagrams/06Jun2003/ - file '03_JobTicketInfo.png' - JTAPI UML diagram ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ - file 'ippjdf-mapping-06-Jun-2003.pdf' - IPP/JDF mapping table Comments? Cheers, - Ira McDonald High North Inc PS - This PWG Job Ticket schema validates without errors with the (free) XSV schema validator from University of Edinburgh (see the W3C site under 'XML Schema' for the link for a Win32 self-installing download). ------------------------------------------------------------------------ FSG Job Ticket Element Mapping to PWG SM Object and Element ---------------------- ------------------------------------ -- JT API metadata -- jt-api-charset [not applicable] - JTAPI methods charset jt-api-version [not applicable] - JTAPI version -- JT instance metadata -- jt-author-name JobTicket.JTAuthorName - e.g., instance author "Ira McDonald" jt-version JobTicket.JTVersion - e.g., instance version "1.14" jt-syntax-version JobTicket.JTSyntaxVersion - e.g., PWG SM version "0.93" jt-type [not applicable] - hard-wired to PWG SM Job Ticket -- JT instance data -- jt-id JobTicket.JTId - e.g., identifier "uuid:blah..." jt-comment JobTicket.JTComment - e.g., "Weekly Accounts" jt-mandatory-attributes JobDescription.JobMandatoryElements - e.g., "media" jt-job JobTicket.Job and JobTicket.Document - contained job and document(s) jt-charset [XML 'encoding' attribute] - e.g., encoding="UTF-8" jt-length-units [not applicable??] - millimeters, points, etc. ------------------------------------------------------------------------ PWG Job Ticket schema - prototype 17 June 2003 - IEM NOTE: To use this schema you MUST include Job.xsd, Document.xsd, and all of their schema dependencies (see their documentation). Job Ticket Type definition Job Ticket instance author, e.g. 'Joe Smith' Job Ticket instance version, e.g. '1.14' PWG Semantic Model syntax version, e.g. '0.93' Job Ticket id, e.g. 'urn:uuid:f81d4fae-7dec-11d0-a765' Job Ticket comment, e.g. 'Weekly Accounts' Job Ticket Element From imcdonald at sharplabs.com Wed Jun 18 22:46:59 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> posted a photo of Ira McD Message-ID: <116DB56CD7DED511BC7800508B2CA53735D064@mailsrvnt02.enet.sharplabs.com> Hi, Claudia Alimpich asked yesterday if I would send a photo to further the rumor that I exist... Posted a JPEG photo (320KB) to the PWG FTP server at: ftp://ftp.pwg.org/pub/pwg/general/pictures/ira_2001.jpg I'm standing in front of my wife Nancy's 1956 International Harvester pickup truck with the blue EUPSAR (Eastern Upper Peninsula Search & Rescue) shield, on the grounds at 20th Annual Grand Marais Music & Arts Festival in August 2001. Cheers, - Ira McDonald High North Inc From imcdonald at sharplabs.com Thu Jun 19 19:57:33 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:31 2009 Subject: SM> Background on "output-device-xxx" new attributes Message-ID: <116DB56CD7DED511BC7800508B2CA53735D065@mailsrvnt02.enet.sharplabs.com> Hi folks, Thursday (19 June 2003) Ever since IPP/1.0 (RFC 2566), the IPP Job object has had a Description attribute named "output-device-assigned" (the _single_ name of the print device assigned by the IPP Printer to process the job). Earlier today, during the Semantic Model session in Portland, Oregon we discussed the IPP Job Extensions proposals for adding: IPP Job Object -------------- "output-device-requested" - device name requested by client IPP Printer Object ------------------ "output-device-supported" - device name(s) supported by Printer "output-device-default" - device name of Printer default, if any, or _absent_ if no default is configured (so that "output-device-requested" will select from "output-device-supported") Note that DPA (ISO 10175) does NOT define a Printer attribute analogous to the JobX proposed "output-device-default" (which has odd semantics). I suggest that we abandon "output-device-default" and solve the problem. Cheers, - Ira McDonald High North Inc ------------------------------ Background: Below are the (more numerous and complex) corresponding attributes defined in DPA (ISO 10175, Document Printing Application): DPA Server Object (roughly analogous to PSI Print Service) ---------------------------------------------------------- "physical-printers-supported" - physical device(s) supported (multi-valued) - source attribute for (single-valued) IPP "output-device-supported" "physical-printers-ready" - physical devices currently ready (multi-valued) "logical-printers-supported" - logical printers supported (multi-valued) "logical-printers-ready" - logical printers currently ready (multi-valued) DPA Printer Object (analogous to IPP Printer _or_ IPP Device) ------------------------------------------------------------- "printer-realization" - logical, physical, or both "printer-associated-printers" - logical/physical associated printers "printers-ready" - logical/physical associated ready DPA Job Object (analagous to IPP Job) ------------------------------------- "printer-name-requested" - logical printer or physical device requested by client - source attribute for (single-valued) IPP "output-device-requested" "physical-printers-requested" - physical device(s) requested by client if "printer-name-requested" is logical "printers-assigned" - physical device(s) assigned by Printer (multi-valued and ordered) - source attribute for (single-valued) IPP "output-device-assigned" "printer-state-of-printers-assigned" - state of each assigned physical device (multi-valued and ordered) From PZehler at crt.xerox.com Mon Jun 23 10:43:44 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> PWG Semantic Model/Schema: Call for Intellectual Property Message-ID: All, This is a call for Patents that are essential to the IEEE ISTO PWG Semantic Model specification and associated Schema. Until the new process documents are finalized we will use the policy and a procedure of the IEEE since the ISTO is an affiliate. The IEEE call, is for essential Patents. The PWG specifies a 10 day call for Intellectual Property(IP). This call will close on July 8, 2003. If you believe you have IP essential to the PWG Semantic Model and/or PWG Schema you should file a Letter of Assurance (LOA). (http://www.pwg.org/chair/pwg-loa.doc ) If you have IP related to the PWG Semantic Model and/or PWG Schema you are encouraged to submit an LOA. If you know of a company that has IP in this space that does participate in the working group please let me know and I will send them the appropriate letter asking them to file an LOA. The completed form should be sent to: Secretariat, Printer Working Group c/o IEEE-ISTO 445 Hoes Lane Piscataway, NJ 08855 USA FAX (+651-318-7292) with a copy to Me. Thanks, Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030623/0dd42a8c/attachment.html From PZehler at crt.xerox.com Wed Jun 25 07:50:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Next Semantic Model Teleconference will be on July 10 Message-ID: All, I am busy doing the edits from the Portland meeting (Document Object, Overrides, and JobX). I am also updating the Semantic Model and Schema with the Schema taking priority to get it posted this week(v0.95). Therefore there will be no teleconference this week. Next week is July 3rd and I doubt attendance would be high. I will get the next version of JobX out and hopefully get some email discussion going identifying issues and possible resolutions. The July 10th teleconference will, most likely, focus on JobX. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030625/b5aaed34/attachment.html From PZehler at crt.xerox.com Fri Jun 27 12:41:17 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> PWG Semantic Model Schema v0.95 posted Message-ID: All, I have posted the PWG Schema v0.95 to the PWG website. Please let me know if you find any problem. I have only had time to make the edits and check the schema with XMLSPY v5.4. I got a new system while I was in Portland and have not yet put my development environment back together. I do not expect the structure of the schema to change. There may be minor changes to element/value names or a limited set of additions/deletions mostly associated with the JobX specification. We will determine the best way to handle these updates at a later time. There are 2 valid "views" of the PWG schema. These schemas include the subschema below. By including all the required schema these two schema are valid. The first is flat and the second hierarchical. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel.xsd The following schemas describe the Printer. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Printer.xsd http://www.pwg.org/schemas/sm/0.95/PrinterDescription.xsd http://www.pwg.org/schemas/sm/0.95/PrinterStatus.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingActual.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingDefault.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingReady.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingSupported.xsd The following schemas describe the Job. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Job.xsd http://www.pwg.org/schemas/sm/0.95/JobDescription.xsd http://www.pwg.org/schemas/sm/0.95/JobProcessing.xsd http://www.pwg.org/schemas/sm/0.95/JobStatus.xsd The following schemas describe the Document. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Document.xsd http://www.pwg.org/schemas/sm/0.95/DocumentDescription.xsd http://www.pwg.org/schemas/sm/0.95/DocumentProcessing.xsd http://www.pwg.org/schemas/sm/0.95/DocumentStatus.xsd The following schemas describe the Media. http://www.pwg.org/schemas/sm/0.95/MediaElements.xsd http://www.pwg.org/schemas/sm/0.95/MediaWellKnownValues.xsd The following schemas describe the types and elements common to Printers, Jobs and Documents. Note that PwgCommon.xsd individually valid. It has a dependency on MediaElements.xsd. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgWellKnownValues.xsd For those of you that use XMLSPY, here is a project file for v0.95. http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel095.spp I've also included a local version of the schema. In this version each schema includes the necessary files and is valid. http://www.pwg.org/schemas/sm/0.95/local-0.95.zip Though not part of the schema, I've included a master list of complex types and elements. http://www.pwg.org/schemas/sm/0.95/MasterListOfPwgSemanticElements.xsd Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030627/f9b2bf61/attachment.html From PZehler at crt.xerox.com Fri Jun 27 14:48:41 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> PWG Semantic Model Schema v0.95 posted (Correction) Message-ID: All, Below is the correct announcement for the PWG Semantic Model Schema. The only two differences are the link to Local-0-95.zip has been fixed and the schemas in the zip file now have the appropriate namespace. (Sorry about that Bob) Pete All, I have posted the PWG Schema v0.95 to the PWG website. Please let me know if you find any problem. I have only had time to make the edits and check the schema with XMLSPY v5.4. I got a new system while I was in Portland and have not yet put my development environment back together. I do not expect the structure of the schema to change. There may be minor changes to element/value names or a limited set of additions/deletions mostly associated with the JobX specification. We will determine the best way to handle these updates at a later time. There are 2 valid "views" of the PWG schema. These schemas include the subschema below. By including all the required schema these two schema are valid. The first is flat and the second hierarchical. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel.xsd The following schemas describe the Printer. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Printer.xsd http://www.pwg.org/schemas/sm/0.95/PrinterDescription.xsd http://www.pwg.org/schemas/sm/0.95/PrinterStatus.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingActual.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingDefault.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingReady.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingSupported.xsd The following schemas describe the Job. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Job.xsd http://www.pwg.org/schemas/sm/0.95/JobDescription.xsd http://www.pwg.org/schemas/sm/0.95/JobProcessing.xsd http://www.pwg.org/schemas/sm/0.95/JobStatus.xsd The following schemas describe the Document. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Document.xsd http://www.pwg.org/schemas/sm/0.95/DocumentDescription.xsd http://www.pwg.org/schemas/sm/0.95/DocumentProcessing.xsd http://www.pwg.org/schemas/sm/0.95/DocumentStatus.xsd The following schemas describe the Media. http://www.pwg.org/schemas/sm/0.95/MediaElements.xsd http://www.pwg.org/schemas/sm/0.95/MediaWellKnownValues.xsd The following schemas describe the types and elements common to Printers, Jobs and Documents. Note that PwgCommon.xsd individually valid. It has a dependency on MediaElements.xsd. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgWellKnownValues.xsd For those of you that use XMLSPY, here is a project file for v0.95. http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel095.spp I've also included a local version of the schema. In this version each schema includes the necessary files and is valid. http://www.pwg.org/schemas/sm/0.95/Local-0-95.zip Though not part of the schema, I've included a master list of complex types and elements. http://www.pwg.org/schemas/sm/0.95/MasterListOfPwgSemanticElements.xsd Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030627/c4d9c80f/attachment.html From PZehler at crt.xerox.com Tue Jul 1 13:14:40 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Remaining issue in Document object spec Message-ID: All, I did not capture the resolution (if any) on the following issue from Dennis Carney. ISSUE: I definitely believe that we need a "Document-equivalent" of job-collation-type. It would have different semantics, since the Job level semantics include the concept of documents, but I believe that since it is useful to know whether a Job is doing collated or uncollated copies, it would also be useful to know the same for Documents. Proposed resolutions: I disagree. If we did add a Document attribute, it would need to have the same value as at the Job Level, since you can't collate some documents and not collate other documents in the same job. We don't duplicate on the Document object other Job level attributes that apply to the job as a whole, such as "job-name", "job-hold", "job-priority", "job-finishing". Before I put the updated document I would like to get consensus. Please respond on the IPP list. Opinions? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030701/e22c41d2/attachment.html From dcarney at us.ibm.com Tue Jul 1 17:35:19 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:31 2009 Subject: SM> Remaining issue in Document object spec Message-ID: Pete, It is easy for me to say :-), but I believe that we *did* resolve this issue, in favor of my proposal. The following appeared on the IPP mailing list: Maybe I'm not understanding. Can't you specify the "copies" attribute at the Document level? Therefore, you could have a Job that was made up of 1 copy of Document 1, 3 copies of Document 2, and 1 copy of Document 3, couldn't you? If you did, you might want to know if the 3 copies of Doc2 were collated or uncollated. I must be missing something--is there a section that would straighten me out? Now I see what you are suggesting. I suppose for consistency we could have a "collation-type" as a Document Template attribute. As long as it is clear that an implementation can implement the "job-collation-type" Job Template attribute without having to do the "collation-type" Document Template attribute (and vice versa). And I *thought* I remembered being on a call where Tom and Ira agreed with the concept. Anybody remember anything different? Dennis |---------+----------------------------> | | "Zehler, Peter" | | | | | | Sent by: | | | owner-sm@pwg.org | | | | | | | | | 07/01/03 11:14 AM| | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------| | | | To: "IPP Discussion List (IPP@pwg.org)" | | cc: "PWG Semantic Model WG (sm@pwg.org)" | | Subject: SM> Remaining issue in Document object spec | | | >------------------------------------------------------------------------------------------------------------------| All, I did not capture the resolution (if any) on the following issue from Dennis Carney. ISSUE: I definitely believe that we need a "Document-equivalent" of job-collation-type. It would have different semantics, since the Job level semantics include the concept of documents, but I believe that since it is useful to know whether a Job is doing collated or uncollated copies, it would also be useful to know the same for Documents. Proposed resolutions: I disagree. If we did add a Document attribute, it would need to have the same value as at the Job Level, since you can't collate some documents and not collate other documents in the same job. We don't duplicate on the Document object other Job level attributes that apply to the job as a whole, such as "job-name", "job-hold", "job-priority", "job-finishing". Before I put the updated document I would like to get consensus. Please respond on the IPP list. Opinions? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Jul 2 11:15:38 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:31 2009 Subject: SM> Semantic Model (JobX) teleconference Message-ID: All, Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This week's Teleconference will be dedicated to IPP JobX. The document is available on the PWG server at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc (If someone could convert this to PDF I would appreciate it. I haven't found my copy of distiller to put on my new system yet.) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is: 1) Discuss the print-quality issue (see included notes below) 2) Discuss the document-xxx-supplied changes in JobX 3) Discuss the output-device resolution Pete PS: Bob let me know if there is a problem hosting Webex. ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, July 10, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Print Quality Issue: Last Tuesday during the PWG/FSG meeting in Portland we had a discussion about the IPP print-quality attribute and FSG's desire to add two new values, "economy" and "fine", where "economy" is lower than "draft" and "fine" is higher than "high". After some discussion we all pretty much decided that it is not possible to add these new values to the already existing "draft", "normal", and "high" values because of the current definitions of the existing values (high is defined as the highest quality and draft is defined as the lowest quality). It also seemed like what FSG wanted was a way to specify print optimization and not additional levels of print quality. The FSG working group met today, and based on the input from last Tuesday's meeting, we would like to propose the addition of a new attribute, called print-optimize, that is defined as follows: print-optimize (type2 keyword) This attribute refines the value specified by the print-quality attribute. The standard keyword values are: 'image': optimize for image clarity 'photo': optimize for photo clarity 'text': optimize for text clarity 'text-and-image': optimize for both text and image clarity 'save-toner': optimize for minimal toner usage 'speed': optimize for printing speed We would appreciate your feedback on this proposal including suggestions for additional values. If this proposal looks good, we would like to propose that it be included in the JobX Spec. If the print-optimize attribute is approved by PWG by the end of August, then we can propose that it be added to the JDF 1.2 Spec that is being finalized in early September. Thank you for your time and feedback. Claudia Alimpich IBM Printing Systems Division Boulder CO 303-924-4418 alimpich@us.ibm.com Response to Print Quality Issue: I understand the desire to avoid violating the semantics of the IPP attribute - but adding these enumerations to print-quality does not feel as objectionable to me as splitting a single semantic concept into two different attributes. If this is the precedent we take for extending the semantic model, I'm worried that we'll end up with an increasingly confusing and complex. I would rather we take the minor hit and fix the high & draft definitions in the semantic model than create another ~equivalent attribute with a whole bunch of special semantic rules (e.g. - what should the service do if print-quality=high and print-optimize=save-toner?). bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:bobt@hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030702/98d0b0ff/attachment.html From PZehler at crt.xerox.com Mon Jul 7 12:59:36 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> PWG "latest" schema directory updated Message-ID: All, I have posted the "latest" PWG Schema to the PWG website. The "latest" version is nearly identical to v0.95. The main differences are the namespace and the schemas location on the website. Please let me know if you find any problem. There are 2 valid "views" of the PWG schema. These schemas include the subschema below. By including every required schema these two schemas are valid. The first is flat and the second hierarchical. http://www.pwg.org/schemas/sm/latest/PwgCommon.xsd http://www.pwg.org/schemas/sm/latest/PwgSemanticModel.xsd The following schemas describe the Printer. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/latest/Printer.xsd http://www.pwg.org/schemas/sm/latest/PrinterDescription.xsd http://www.pwg.org/schemas/sm/latest/PrinterStatus.xsd http://www.pwg.org/schemas/sm/latest/ProcessingActual.xsd http://www.pwg.org/schemas/sm/latest/ProcessingDefault.xsd http://www.pwg.org/schemas/sm/latest/ProcessingReady.xsd http://www.pwg.org/schemas/sm/latest/ProcessingSupported.xsd The following schemas describe the Job. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/latest/Job.xsd http://www.pwg.org/schemas/sm/latest/JobDescription.xsd http://www.pwg.org/schemas/sm/latest/JobProcessing.xsd http://www.pwg.org/schemas/sm/latest/JobStatus.xsd The following schemas describe the Document. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/latest/Document.xsd http://www.pwg.org/schemas/sm/latest/DocumentDescription.xsd http://www.pwg.org/schemas/sm/latest/DocumentProcessing.xsd http://www.pwg.org/schemas/sm/latest/DocumentStatus.xsd The following schemas describe the Media. http://www.pwg.org/schemas/sm/latest/MediaElements.xsd http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd The following schemas describe the types and elements common to Printers, Jobs and Documents. Note that PwgCommon.xsd individually valid. It has a dependency on MediaElements.xsd. http://www.pwg.org/schemas/sm/latest/PwgCommon.xsd http://www.pwg.org/schemas/sm/latest/PwgWellKnownValues.xsd For those of you that use XMLSPY, here is a project file for "latest". http://www.pwg.org/schemas/sm/latest/PwgSmPostedLatest.spp I've also included a local version of the schema. In this version each schema includes the necessary files and is valid. http://www.pwg.org/schemas/sm/latest/Local.zip Though not part of the schema, I've included a master list of complex types and elements. http://www.pwg.org/schemas/sm/latest/MasterListOfPwgSemanticElements.xsd Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030707/f6436a8f/attachment.html From imcdonald at sharplabs.com Wed Jul 9 11:46:26 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Request to discuss "print-optimize" first Message-ID: <116DB56CD7DED511BC7800508B2CA53735D097@mailsrvnt02.enet.sharplabs.com> Hi, Several FSG (Free Standards Group) people would like to attend the IPP Job Extensions (JobX) review tomorrow to discuss their recent proposal for a new "print-optimize" attribute - instead of additional values for "print-quality" (as Bob Taylor has recently suggested). To facilitate FSG participation, we request that "print-optimize" be discussed first, at the beginning of the telecon. Pete - please consider accomodating FSG participation this way. I'll forward replies to the FSG lists (also closed). Thanks, - Ira McDonald, member of FSG Architecture and Job Ticket WG's High North Inc From PZehler at crt.xerox.com Wed Jul 9 11:58:42 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Request to discuss "print-optimize" first Message-ID: Ira, After some very short status we will proceed with the print-quality discussion. Pete > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: Wednesday, July 09, 2003 11:46 AM > To: 'ipp@pwg.org'; 'sm@pwg.org' > Subject: SM> Request to discuss "print-optimize" first > > Hi, > > Several FSG (Free Standards Group) people would like to attend > the IPP Job Extensions (JobX) review tomorrow to discuss their > recent proposal for a new "print-optimize" attribute - instead > of additional values for "print-quality" (as Bob Taylor has > recently suggested). > > To facilitate FSG participation, we request that "print-optimize" > be discussed first, at the beginning of the telecon. > > Pete - please consider accomodating FSG participation this way. > I'll forward replies to the FSG lists (also closed). > > Thanks, > - Ira McDonald, member of FSG Architecture and Job Ticket WG's > High North Inc From hastings at cp10.es.xerox.com Wed Jul 9 19:08:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model (JobX) teleconference Message-ID: I've down loaded the .pdf for the .doc files as Peter requested for tomorrow's telecon. I've also put all four in the proper place in the IPP spec hierarchy as well under the new_JOBX arc (but I did not delete them from the Semantic_Model sub-tree): ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.doc Tom -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Wednesday, July 02, 2003 08:16 To: PWG Semantic Model WG (sm@pwg.org) Cc: 'Claudia Alimpich'; IPP Discussion List (IPP@pwg.org); printing-jobticket@freestandards.org; printing-driver@freestandards.org Subject: SM> Semantic Model (JobX) teleconference All, Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This week's Teleconference will be dedicated to IPP JobX. The document is available on the PWG server at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc (If someone could convert this to PDF I would appreciate it. I haven't found my copy of distiller to put on my new system yet.) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is: 1) Discuss the print-quality issue (see included notes below) 2) Discuss the document-xxx-supplied changes in JobX 3) Discuss the output-device resolution Pete PS: Bob let me know if there is a problem hosting Webex. ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, July 10, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ BM__MailAutoSigPeter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Print Quality Issue: Last Tuesday during the PWG/FSG meeting in Portland we had a discussion about the IPP print-quality attribute and FSG's desire to add two new values, "economy" and "fine", where "economy" is lower than "draft" and "fine" is higher than "high". After some discussion we all pretty much decided that it is not possible to add these new values to the already existing "draft", "normal", and "high" values because of the current definitions of the existing values (high is defined as the highest quality and draft is defined as the lowest quality). It also seemed like what FSG wanted was a way to specify print optimization and not additional levels of print quality. The FSG working group met today, and based on the input from last Tuesday's meeting, we would like to propose the addition of a new attribute, called print-optimize, that is defined as follows: print-optimize (type2 keyword) This attribute refines the value specified by the print-quality attribute. The standard keyword values are: 'image': optimize for image clarity 'photo': optimize for photo clarity 'text': optimize for text clarity 'text-and-image': optimize for both text and image clarity 'save-toner': optimize for minimal toner usage 'speed': optimize for printing speed We would appreciate your feedback on this proposal including suggestions for additional values. If this proposal looks good, we would like to propose that it be included in the JobX Spec. If the print-optimize attribute is approved by PWG by the end of August, then we can propose that it be added to the JDF 1.2 Spec that is being finalized in early September. Thank you for your time and feedback. Claudia Alimpich IBM Printing Systems Division Boulder CO 303-924-4418 alimpich@us.ibm.com Response to Print Quality Issue: I understand the desire to avoid violating the semantics of the IPP attribute - but adding these enumerations to print-quality does not feel as objectionable to me as splitting a single semantic concept into two different attributes. If this is the precedent we take for extending the semantic model, I'm worried that we'll end up with an increasingly confusing and complex. I would rather we take the minor hit and fix the high & draft definitions in the semantic model than create another ~equivalent attribute with a whole bunch of special semantic rules (e.g. - what should the service do if print-quality=high and print-optimize=save-toner?). bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:bobt@hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030709/eaa72de2/attachment.html From imcdonald at sharplabs.com Thu Jul 10 11:49:56 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model (JobX) teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA53735D09B@mailsrvnt02.enet.sharplabs.com> Hi Tom and Pete, Are we reviewing the '-rev.pdf' or the plain '.pdf' today? Will you be using the WebEx to edit the document? I picked up the '-rev.pdf', because it seemed most useful. Cheers, - Ira -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, July 09, 2003 7:09 PM To: Zehler, Peter; PWG Semantic Model WG (sm@pwg.org) Cc: 'Claudia Alimpich'; IPP Discussion List (IPP@pwg.org); printing-jobticket@freestandards.org; printing-driver@freestandards.org Subject: RE: SM> Semantic Model (JobX) teleconference I've down loaded the .pdf for the .doc files as Peter requested for tomorrow's telecon. I've also put all four in the proper place in the IPP spec hierarchy as well under the new_JOBX arc (but I did not delete them from the Semantic_Model sub-tree): ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.doc Tom -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Wednesday, July 02, 2003 08:16 To: PWG Semantic Model WG (sm@pwg.org) Cc: 'Claudia Alimpich'; IPP Discussion List (IPP@pwg.org); printing-jobticket@freestandards.org; printing-driver@freestandards.org Subject: SM> Semantic Model (JobX) teleconference All, Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This week's Teleconference will be dedicated to IPP JobX. The document is available on the PWG server at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc (If someone could convert this to PDF I would appreciate it. I haven't found my copy of distiller to put on my new system yet.) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is: 1) Discuss the print-quality issue (see included notes below) 2) Discuss the document-xxx-supplied changes in JobX 3) Discuss the output-device resolution Pete PS: Bob let me know if there is a problem hosting Webex. ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, July 10, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Print Quality Issue: Last Tuesday during the PWG/FSG meeting in Portland we had a discussion about the IPP print-quality attribute and FSG's desire to add two new values, "economy" and "fine", where "economy" is lower than "draft" and "fine" is higher than "high". After some discussion we all pretty much decided that it is not possible to add these new values to the already existing "draft", "normal", and "high" values because of the current definitions of the existing values (high is defined as the highest quality and draft is defined as the lowest quality). It also seemed like what FSG wanted was a way to specify print optimization and not additional levels of print quality. The FSG working group met today, and based on the input from last Tuesday's meeting, we would like to propose the addition of a new attribute, called print-optimize, that is defined as follows: print-optimize (type2 keyword) This attribute refines the value specified by the print-quality attribute. The standard keyword values are: 'image': optimize for image clarity 'photo': optimize for photo clarity 'text': optimize for text clarity 'text-and-image': optimize for both text and image clarity 'save-toner': optimize for minimal toner usage 'speed': optimize for printing speed We would appreciate your feedback on this proposal including suggestions for additional values. If this proposal looks good, we would like to propose that it be included in the JobX Spec. If the print-optimize attribute is approved by PWG by the end of August, then we can propose that it be added to the JDF 1.2 Spec that is being finalized in early September. Thank you for your time and feedback. Claudia Alimpich IBM Printing Systems Division Boulder CO 303-924-4418 alimpich@us.ibm.com Response to Print Quality Issue: I understand the desire to avoid violating the semantics of the IPP attribute - but adding these enumerations to print-quality does not feel as objectionable to me as splitting a single semantic concept into two different attributes. If this is the precedent we take for extending the semantic model, I'm worried that we'll end up with an increasingly confusing and complex. I would rather we take the minor hit and fix the high & draft definitions in the semantic model than create another ~equivalent attribute with a whole bunch of special semantic rules (e.g. - what should the service do if print-quality=high and print-optimize=save-toner?). bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:bobt@hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- From imcdonald at sharplabs.com Wed Jul 16 13:32:52 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Simple Device extension to Semantic Model Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0AE@mailsrvnt02.enet.sharplabs.com> Hi folks, Wednesday (16 July 2003) Proposal for a simple Device extension to the PWG Semantic Model: (1) Add a "PrinterRole" element to the Printer object, with legal values 'logical' (PSI Print Service, IPP Printer, etc.), 'physical' (PSI Target Device, SNMP Device, etc.), or 'logical-and-physical' (for consistency with ISO 10175 DPA's "printer-realization" attribute and a number of shipping vendor implementations of DPA). (2) Any 'logical' Printer object MAY support (e.g., via PSI's GetTargetDeviceElements) returning its 'best effort knowledge' of the elements of local surrogate 'physical' Printers (Devices). The URI of each local surrogate 'physical' Printer is formed by concatenating: (a) Any URI value of the "PrinterUriSupported" element (e.g., a 'pwg-psips:' value), and (b) a single dot '.', and (c) any value of the "OuputDeviceSupported" element. (3) A 'physical' Printer supports all standard Printer elements and MAY also support the "PrtXXX" elements extracted from the IESG-approved final draft of Printer MIB v2 (for the WBMM effort). Comments? Cheers, - Ira McDonald High North Inc PS - Mapping this PWG Semantic Model extension back to IPP is trivial. The latest IPP Job Extensions spec defines "output-device" (a client supplied Job Creation operation attribute) and "output-device-supported" (a Printer attribute that bounds the values of "output-device" and the existing "output-device-assigned", a Job Description attribute). An 'ipp:' value of "printer-uri-supported" on an IPP 'logical' Printer MAY be suffixed with a dot and a value of "output-device-supported" to form the URI of an IPP 'physical' Printer with "prt-xxx" attributes. Existing Get-Printer-Attributes and Set-Printer-Attributes operations MAY be used to manage and configure an IPP 'physical' Printer. No new IPP operations are required to add Device support to IPP. From imcdonald at sharplabs.com Wed Jul 16 15:58:15 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> RE: IPP> Simple Device extension to Semantic Model Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0B0@mailsrvnt02.enet.sharplabs.com> Hi Carl-Uno, As it's an OPTIONAL extension attribute, obviously if the IPP Printer Description attribute "printer-role" is NOT present, then the IPP Printer MUST behave (as in RFC 2911) as a 'logical' Printer (a service, not a device) - which is perfectly backwards compatible. Further, a client that doesn't understand "printer-role" will never ignore it erroneously in an IPP 'physical' Printer (a device), because that URL is NOT advertised - it's only constructed from the associated IPP 'logical' Printer's URL, as I proposed. OK? Cheers, - Ira McDonald High North Inc -----Original Message----- From: Carl [mailto:carl@manros.com] Sent: Wednesday, July 16, 2003 3:29 PM To: McDonald, Ira; sm@pwg.org; ipp@pwg.org Subject: RE: IPP> Simple Device extension to Semantic Model Ira, Unless you suggest this to be an mandatory element, what is the default assumption if it is not present? Carl-Uno Carl-Uno Manros 700 Carnegie Street #3724 Henderson, NV 89052, USA Tel +1-702-617-9414 Fax +1-702-617-9417 Mob +1-702-525-0727 Email carl@manros.com Web www.manros.com > -----Original Message----- > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of McDonald, > Ira > Sent: Wednesday, July 16, 2003 10:33 AM > To: 'sm@pwg.org'; 'ipp@pwg.org' > Subject: IPP> Simple Device extension to Semantic Model > > > Hi folks, Wednesday (16 July 2003) > > Proposal for a simple Device extension to the PWG Semantic Model: > > (1) Add a "PrinterRole" element to the Printer object, with legal values > 'logical' (PSI Print Service, IPP Printer, etc.), 'physical' (PSI > Target Device, SNMP Device, etc.), or 'logical-and-physical' (for > consistency with ISO 10175 DPA's "printer-realization" attribute > and a number of shipping vendor implementations of DPA). > > (2) Any 'logical' Printer object MAY support (e.g., via PSI's > GetTargetDeviceElements) returning its 'best effort knowledge' > of the elements of local surrogate 'physical' Printers (Devices). > The URI of each local surrogate 'physical' Printer is formed by > concatenating: > > (a) Any URI value of the "PrinterUriSupported" element (e.g., a > 'pwg-psips:' value), and > (b) a single dot '.', and > (c) any value of the "OuputDeviceSupported" element. > > (3) A 'physical' Printer supports all standard Printer elements and MAY > also support the "PrtXXX" elements extracted from the IESG-approved > final draft of Printer MIB v2 (for the WBMM effort). > > Comments? > > Cheers, > - Ira McDonald > High North Inc > > > PS - Mapping this PWG Semantic Model extension back to IPP is trivial. > > The latest IPP Job Extensions spec defines "output-device" (a client > supplied Job Creation operation attribute) and "output-device-supported" > (a Printer attribute that bounds the values of "output-device" and the > existing "output-device-assigned", a Job Description attribute). > > An 'ipp:' value of "printer-uri-supported" on an IPP 'logical' Printer > MAY be suffixed with a dot and a value of "output-device-supported" to > form the URI of an IPP 'physical' Printer with "prt-xxx" attributes. > > Existing Get-Printer-Attributes and Set-Printer-Attributes operations > MAY be used to manage and configure an IPP 'physical' Printer. No new > IPP operations are required to add Device support to IPP. > From imcdonald at sharplabs.com Thu Jul 17 12:12:17 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Is there an SM call in one hour (17 July)?? Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0B3@mailsrvnt02.enet.sharplabs.com> Hi Pete and Tom, Is there an SM telecon today? Did I just miss the announcement? Cheers, - Ira From imcdonald at sharplabs.com Thu Jul 17 12:26:34 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> NO - Is there an SM call in one hour (17 July)?? Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0B6@mailsrvnt02.enet.sharplabs.com> Hi, Tom says Pete's on vacation and today's SM call is CANCELLED. Cheers, - Ira McDonald -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Thursday, July 17, 2003 12:12 PM To: 'sm@pwg.org' Subject: SM> Is there an SM call in one hour (17 July)?? Hi Pete and Tom, Is there an SM telecon today? Did I just miss the announcement? Cheers, - Ira From imcdonald at sharplabs.com Mon Jul 21 13:43:35 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0BA@mailsrvnt02.enet.sharplabs.com> Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From PZehler at crt.xerox.com Wed Jul 23 09:46:56 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Next PWG Semantic Model Meeting Will Be July 31 Message-ID: All, Given vacation and subsequent work load I will be unable to get the JobX updates sent out prior to this Thursday. I will get it out ASAP and be ready for a review next Thursday. The objective is to get to a stable version. Soon after that the PWG Semantic Model document will be brought up to date and sent out for a final review. Minor updates will also be made to the schema. The proposed agenda for the 31st will be as follows. 1) Quick Status 2) JobX Review a. Section by section with focus on recently changed text b. Any issues raised by the group 3) Schema changes and update plans 4) Schedule for Semantic Model stable document I will get the JobX document, updated agenda (given any suggestions from the group), and the details for the teleconference out later this week. Any issues should be sent to the SM mail list. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030723/8d0ea1b1/attachment.html From PZehler at crt.xerox.com Mon Jul 28 11:45:53 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model (JobX) Teleconference Message-ID: All, This Thursday will be a review of the JobX specification. We will focus on the new and modified text. The text has been highlighted in turquoise. There are two issues highlighted in yellow. Please send out any issues or comments you have prior to Thursday so I can collect them and we can address them at the teleconference. The objective of this teleconference is to get to a stable version. Once this document is stable the PWG Semantic Model document will be brought up to date and sent out for a final review. Minor updates will also be made to the schema. The proposed agenda for the 31st will be as follows. 1) Quick Status 2) JobX Review a. Section by section with focus on recently changed text b. Any issues raised by the group 3) Schema changes and update plans 4) Schedule for Semantic Model stable document The JobX document is available on the PWG ftp server at < ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030728.pdf >. (There are also .doc, -rev.pdf and -rev.doc versions available in the same directory) The teleconference is 2 hours long. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. NOTE: New Webex site and possibly new software needs to be downloaded. Pete _____________________________________________________________ Meeting Date: 07/31/2003 Meeting Time: 1:00 PM Eastern (-4:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030728/2ededdec/attachment.html From hastings at cp10.es.xerox.com Mon Jul 28 16:25:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:32 2009 Subject: SM> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Tue Jul 29 18:31:32 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0CB@mailsrvnt02.enet.sharplabs.com> Hi Tom, I agree with your suggested rewording below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, July 28, 2003 4:25 PM To: McDonald, Ira; 'sm@pwg.org'; 'ps@pwg.org' Subject: RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From PZehler at crt.xerox.com Mon Aug 4 12:27:58 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Return of the Semantic Model (JobX) Teleconference Message-ID: All, Given that only Xerox attended last week's JobX teleconference I will assume that everyone was on vacation and try again. I would also like to discuss the next phase for JobX, Overrides, Document Object, Semantic Model and its associated schema. This Thursday will be a review of the JobX specification. We will focus on the new and modified text. The text has been highlighted in turquoise. There are two issues highlighted in yellow. Please send out any issues or comments you have prior to Thursday so I can collect them and we can address them at the teleconference. The objective of this teleconference is to get to a stable version. Once this document is stable the PWG Semantic Model document will be brought up to date and sent out for a final review. Minor updates will also be made to the schema. The proposed agenda for the 31st will be as follows. 1) Status of JobX, Overrides, Document Object, Semantic Model and its associated schema a. Next steps 2) JobX Review a. Section by section with focus on recently changed text b. Any issues raised by the group 3) Schema changes and updates plans 4) Schedule for Semantic Model stable document The JobX document is available on the PWG ftp server at < ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030728.pdf >. (There are also .doc, -rev.pdf and -rev.doc versions available in the same directory) The teleconference is 2 hours long. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. NOTE: New Webex site and possibly new software needs to be downloaded. Pete _____________________________________________________________ Meeting Date: 08/07/2003 Meeting Time: 1:00 PM Eastern (-4:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030804/2621a794/attachment.html From PZehler at crt.xerox.com Mon Aug 11 10:06:01 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> SM teleconference Message-ID: All, There will be no Semantic Model teleconference this week. . If we have enough content and interest we will hold a teleconference on August 21. I will be collecting comments from the PWG on moving the Document Object, Overrides and JobX to 'Prototype' maturity level. This week (when I'm not vacationing) I will be updating the Semantic Model and Schema. Bob Taylor has raised a few issues and I will send them out under separate cover. I have found several oversights and typing/paste errors that I will correct. I will also do a cross check with the three specifications listed above Please send ANY comments on the Semantic Model and Schema to this mail list. I would also like to get proposed agenda items for a teleconference on the 21st. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030811/2e9499ce/attachment.html From PZehler at crt.xerox.com Mon Aug 11 11:42:34 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Current Schema issues Message-ID: All, Here are the issues I am currently aware of regarding v0.95 of the PWG Schema. If you have any comments on one of these issues please cut and paste the issue into a new mail note with a subject line of "Schema Issue #" where # is the number of the issue from the list below Thanks, Pete 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030811/919afa71/attachment.html From PZehler at crt.xerox.com Tue Aug 19 13:02:00 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Next SM meeting will be 8/28/03 Message-ID: All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030819/c1e4d537/attachment.html From PZehler at crt.xerox.com Tue Aug 19 13:02:00 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Next SM meeting will be 8/28/03 Message-ID: All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030819/c1e4d537/attachment-0001.html From PZehler at crt.xerox.com Thu Aug 28 09:30:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Updated "Latest" PWG Semantic Model Schema Message-ID: All, The "Latest" version (v0.96) of the PWG Semantic Model Schema has been posted on the PWG web site. (See "Semantic Model: Latest Version" under "Documents" on http://www.pwg.org/sm/ ) The list of differences is available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/ChangesToPwgSchemaV95.pdf . Any issues or comments on the latest schema should be sent to mailto:sm@pwg.org We will discuss the schema in the SM teleconference scheduled for Thursday August 28. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030828/8728a14b/attachment.html From imcdonald at sharplabs.com Thu Aug 28 11:16:55 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Next SM meeting will be 8/28/03 ??? Message-ID: <116DB56CD7DED511BC7800508B2CA537B00183@mailsrvnt02.enet.sharplabs.com> Hi Pete, I haven't seen any announcement this week of today's (8/28) SM telecon. Are we still having it, two hours from now? Cheers, - Ira McDonald High North Inc -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, August 19, 2003 1:02 PM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> 8/21 cancelled - Next SM meeting will be 8/28/03 All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 From alan.berkema at hp.com Thu Aug 28 12:06:48 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:04:32 2009 Subject: SM> PWG Semantic Model Mtg. 8/28/03 Message-ID: <0806DAA43B1555479D53B58675D3468345844B@xrose01.rose.hp.com> On behalf of Peter Zehler: All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324 &p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 ____________________________________________________________________________ __ -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Thursday, August 21, 2003 11:37 AM To: 'Zehler, Peter' Subject: RE: PWG-ANNOUNCE> PWG Semantic Model Specification v0.90 Hi Pete, Is there a call today? I think I fell off of the reflector Thanks, Alan -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Thursday, August 21, 2003 8:03 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> PWG Semantic Model Specification v0.90 All, The v0.90 of the PWG Semantic Model has been posted on the PWG web site. The document is available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20030820.pdf . The changes from the last review are listed below. The changes are primarily clean-up and incorporating the final changes in the JobX, Overrides and Document Object Specifications. Any issues or comments on the v0.90 specification should be sent to mailto:sm@pwg.org We will set the schedule for the final review of this specification in the SM teleconference scheduled for Thursday August 28. Pete Change Log: 8/20/03 PJZ cross checked tables and figures 8/15/03 PJZ Synched specification with [jobx], [override] and [doc-obj], 6/30/03 PJZ Added Overrides 4/21/03 PJZ Removed Tumble value from Sides 3/31/03 PJZ Cleaned up Naming of Classes, Elements and Values (? 4.1) and IPP Mapping (?14). Fixed case of element values in tables 3/26/03 PJZ Updated with changes from Document Object Specification 3/21/03 PJZ Added Character Repertoire 3/17/03 PJZ Removed PSI specific actions, corrected list of excluded elements in appendix B 3/16/03 TNH/PJZ Updated with the Document Object specifications. Added CloseJob that PSI is using. Renamed SendData to SendDocumentData to indicate what data. Prefixed JobId, JobPrinterUri, and JobUri Document Description elements with Document, so no Document attributes have a Job prefix. Added the following Document Description elements: DocumentContainerSummary, DocumentCreatorApplicationName, DocumentCreatorApplicationVersion, DocumentCreatorOsName, DocumentCreatorOsVersion, DocumentFormatDetected, DocumentFormatDeviceId, DocumentFormatVersion, DocumentIdUri, DocumentMessage, ElementNaturalLanguage. 1/29/03 PJZ Incorporated comments from Face to Face preparing document for Last Call. Updated abstract, introdusction and terminology sections. Added section to capture known semantic elements "waiting in the wings". Sorted status strings alphabetically. Added PSI specific actions and status strings. Corected Job & Doc state transition diagrams. Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030828/e14ed377/attachment.html From PZehler at crt.xerox.com Thu Aug 28 11:54:52 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> REMINDER: Next SM meeting will be 8/28/03 Message-ID: > -----Original Message----- > From: Zehler, Peter > Sent: Thursday, August 28, 2003 11:29 AM > To: PWG Semantic Model WG (E-mail) > Subject: REMINDER: Next SM meeting will be 8/28/03 > > > > -----Original Message----- > From: Zehler, Peter > Sent: Tuesday, August 19, 2003 1:02 PM > To: PWG Semantic Model WG (sm@pwg.org) > Subject: Next SM meeting will be 8/28/03 > > All, > > The next teleconference for the Semantic Model will be on August 28. My > proposed agenda is > 1) Status of JobX, Overrides and Document Object specifications > 2) Status of PWG Semantic Model > 3) Status of PWG Schema > a. Changes > b. Release update strategy and naming > 4) Review issues raised (list included below) > 5) Other items? > 6) Next steps > > Please send me any additional items, comments or issues. > > Pete > > Peter Zehler > XEROX > Xerox Innovation Group > Email: PZehler@crt.xerox.com > Voice: (585) 265-8755 > FAX: (585) 422-7961 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > You are invited to join a meeting on the PWG Semantic Model. Meeting > details are listed below. > > Meeting Date: 08/28/2003 > Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) > > Instant Meeting Details: > ------------------------------- > USA Toll Free Number: 877-707-6056 > > Participant Passcode: 437874 > > Instant Net Conference Details: > ------------------------------- > Meeting Number: 747275324 > Meeting Passcode: PwgSm > Meeting Host: Pete Zehler > > Join Instructions for Instant Net Conference: > > REPEAT USERS > 1. Join the meeting now: > http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c > 2. Enter your name > 3. Agree to the Terms & Conditions and click Proceed. > > NEW USERS > 1. Go to http://www.mymeetings.com/nc/ > 2. Type in the Meeting Number > 3. Type in the Meeting Passcode (if one was provided) > 4. Choose "Conference" and click Proceed > 5. If you are a new user, click on "New Users" to check your system > and download the software and go back to Join Net Conference page > 6. Enter your name > 7. Agree to the Terms & Conditions and click Proceed. > Current PWG Semantic Model/Schema Issues: > 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual > in JobProcessingActual - I pulled it out and it was fine in sqc > Duplicate was supposed to be > "OutputDeciceActual". Fixed in all sub-schemas. > 2) the PWG SM schemas liberally use . The > sqc apparently dislikes using ##any for the namepace wildcard if the > xs:any is in a sequence with any other elements. If I switch this to > , the problem goes away. I couldn't find any > documentation on why this is a problem, but the sqc doesn't like it. > Interestingly, it looks like you can add !both! namespace="##other"/> and and it works fine > - which in theory is the equivalent of . I did > find this pattern in a sample online, but I haven't yet found any > description on why is a real problem. It > does, however, fail the sqc, and we think it may be what is causing some > of the MS tools to give up on the SM schemas as well > Actually the replacement for namespace="##any"/> would be namespace="http://www.pwg.org/schemas/sm/latest/"/> and namespace="##other"/>. We do NOT want locally defined elements. All > extensions MUST be fully qualified with the namespace to federate > extensions to the schema. In all examples I have seen from the W3C they > use '##any" for this type of extensibility. I still have not reinstalled > all my XML tools yet or have not had time to try them on this issue. It > seems to me that '##any' is exactly what we mean. > 3) The PWG copyright on the schemas still says 2002. I'm assuming we > need to roll this to 2003. > Added ", 2003" to copyright notices > 4) "JobPriority" need minimum value of '1' and maximum value of '100'. > Added to "JobPriority" and > "JobPriorityDefault" > 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation > 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. > Fixed > 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and > image MIME types > Added 'application/vnd.pwg-xhtml-print+xml', > image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. > 7) "DocumentFormat" does not allow certain extension values. > The "MimeExtentionPattern" SimpleType is not > correct. As a quick fix I changed it to have a value of > '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone > with time to create a proper pattern describing MIME would be > appreciated. > 8) "PrinterStateReasons" should include the values 'AttentionRequired' > and 'MarkerFailure'. > Added them > 9) "DocumentFormat" need the value 'unknown'. > Added it > 10) "JobAccountingId" should be "JobAccountingID". > Fixed > 11) How should we release the updated PWG Schema v0.95? > Release as version 0.96 > > From PZehler at crt.xerox.com Thu Aug 28 11:54:52 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> REMINDER: Next SM meeting will be 8/28/03 Message-ID: > -----Original Message----- > From: Zehler, Peter > Sent: Thursday, August 28, 2003 11:29 AM > To: PWG Semantic Model WG (E-mail) > Subject: REMINDER: Next SM meeting will be 8/28/03 > > > > -----Original Message----- > From: Zehler, Peter > Sent: Tuesday, August 19, 2003 1:02 PM > To: PWG Semantic Model WG (sm@pwg.org) > Subject: Next SM meeting will be 8/28/03 > > All, > > The next teleconference for the Semantic Model will be on August 28. My > proposed agenda is > 1) Status of JobX, Overrides and Document Object specifications > 2) Status of PWG Semantic Model > 3) Status of PWG Schema > a. Changes > b. Release update strategy and naming > 4) Review issues raised (list included below) > 5) Other items? > 6) Next steps > > Please send me any additional items, comments or issues. > > Pete > > Peter Zehler > XEROX > Xerox Innovation Group > Email: PZehler@crt.xerox.com > Voice: (585) 265-8755 > FAX: (585) 422-7961 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > You are invited to join a meeting on the PWG Semantic Model. Meeting > details are listed below. > > Meeting Date: 08/28/2003 > Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) > > Instant Meeting Details: > ------------------------------- > USA Toll Free Number: 877-707-6056 > > Participant Passcode: 437874 > > Instant Net Conference Details: > ------------------------------- > Meeting Number: 747275324 > Meeting Passcode: PwgSm > Meeting Host: Pete Zehler > > Join Instructions for Instant Net Conference: > > REPEAT USERS > 1. Join the meeting now: > http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c > 2. Enter your name > 3. Agree to the Terms & Conditions and click Proceed. > > NEW USERS > 1. Go to http://www.mymeetings.com/nc/ > 2. Type in the Meeting Number > 3. Type in the Meeting Passcode (if one was provided) > 4. Choose "Conference" and click Proceed > 5. If you are a new user, click on "New Users" to check your system > and download the software and go back to Join Net Conference page > 6. Enter your name > 7. Agree to the Terms & Conditions and click Proceed. > Current PWG Semantic Model/Schema Issues: > 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual > in JobProcessingActual - I pulled it out and it was fine in sqc > Duplicate was supposed to be > "OutputDeciceActual". Fixed in all sub-schemas. > 2) the PWG SM schemas liberally use . The > sqc apparently dislikes using ##any for the namepace wildcard if the > xs:any is in a sequence with any other elements. If I switch this to > , the problem goes away. I couldn't find any > documentation on why this is a problem, but the sqc doesn't like it. > Interestingly, it looks like you can add !both! namespace="##other"/> and and it works fine > - which in theory is the equivalent of . I did > find this pattern in a sample online, but I haven't yet found any > description on why is a real problem. It > does, however, fail the sqc, and we think it may be what is causing some > of the MS tools to give up on the SM schemas as well > Actually the replacement for namespace="##any"/> would be namespace="http://www.pwg.org/schemas/sm/latest/"/> and namespace="##other"/>. We do NOT want locally defined elements. All > extensions MUST be fully qualified with the namespace to federate > extensions to the schema. In all examples I have seen from the W3C they > use '##any" for this type of extensibility. I still have not reinstalled > all my XML tools yet or have not had time to try them on this issue. It > seems to me that '##any' is exactly what we mean. > 3) The PWG copyright on the schemas still says 2002. I'm assuming we > need to roll this to 2003. > Added ", 2003" to copyright notices > 4) "JobPriority" need minimum value of '1' and maximum value of '100'. > Added to "JobPriority" and > "JobPriorityDefault" > 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation > 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. > Fixed > 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and > image MIME types > Added 'application/vnd.pwg-xhtml-print+xml', > image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. > 7) "DocumentFormat" does not allow certain extension values. > The "MimeExtentionPattern" SimpleType is not > correct. As a quick fix I changed it to have a value of > '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone > with time to create a proper pattern describing MIME would be > appreciated. > 8) "PrinterStateReasons" should include the values 'AttentionRequired' > and 'MarkerFailure'. > Added them > 9) "DocumentFormat" need the value 'unknown'. > Added it > 10) "JobAccountingId" should be "JobAccountingID". > Fixed > 11) How should we release the updated PWG Schema v0.95? > Release as version 0.96 > > From hastings at cp10.es.xerox.com Fri Aug 29 20:05:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:32 2009 Subject: SM> FW: Status of JobX, Overrides and Document Object specifications [from Pete Zehler] Message-ID: I've not seen this email from the PWG site, so I'm forwarding it to the sm@pwg.org, as Pete has requested. He'll be traveling next week with a new laptop. Tom -----Original Message----- From: Zehler, Peter Sent: Friday, August 29, 2003 12:51 PM To: PWG Semantic Model WG (sm@pwg.org) Subject> : Status of JobX, Overrides and Document Object specifications All, In the Semantic Model teleconference we discussed the status of the JobX, Overrides and Document Object specifications. They have been stable for quite some time. The requirements for entering into last call are that the specifications must be prototyped first. It was agreed that PSI satisfied this requirement for the Document Object and JobX. Overrides have been prototyped by Xerox on their DocuSP platform. This prototype was done independently of the Overrides specification and based on PWG 5100.4. However the implementation was greatly simplified and aligns with the Overrides specification. I will be generating clean versions of these three specifications. The only comments received so far are editorial in nature. I will post them on the PWG and formally announce the start of Last Call on the specifications. The Last Call will end on the Thursday (10/9/03) of our next PWG meeting. Once these documents have completed Last Call we will proceed with Last Call on the Semantic Model and Schema. Peter Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030829/145c5c2e/attachment.html From PZehler at crt.xerox.com Fri Aug 29 12:51:28 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Status of JobX, Overrides and Document Object specifications Message-ID: All, In the Semantic Model teleconference we discussed the status of the JobX, Overrides and Document Object specifications. They have been stable for quite some time. The requirements for entering into last call are that the specifications must be prototyped first. It was agreed that PSI satisfied this requirement for the Document Object and JobX. Overrides have been prototyped by Xerox on their DocuSP platform. This prototype was done independently of the Overrides specification and based on PWG 5100.4. However the implementation was greatly simplified and aligns with the Overrides specification. I will be generating clean versions of these three specifications. The only comments received so far are editorial in nature. I will post them on the PWG and formally announce the start of Last Call on the specifications. The Last Call will end on the Thursday (10/9/03) of our next PWG meeting. Once these documents have completed Last Call we will proceed with Last Call on the Semantic Model and Schema. Peter Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030829/9acc4893/attachment.html From PZehler at crt.xerox.com Wed Sep 17 09:13:34 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> FW: Sematic model and Media question Message-ID: All, Below is a Schema issue raised by Geoff Soord and my response. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 > -----Original Message----- > From: Geoff Soord [mailto:geoff_soord@sw2000.com] > Sent: Tuesday, September 16, 2003 12:25 PM > To: Zehler, Peter > Subject: Sematic model and Media question > > > > Peter, > > I have a few questions about the semantic model - please see the > attached bitmap. > > My understanding is for an insertSheet can contain 0 or more Isheets. An > ISheet can optional contain "Media" or "MediaCol". > > My first question is: From DocumentProcessing, should Media and MediaCol > be mutually exclusive as is the case for Isheet? Yes they should Is this a mistake in > the schema or I am missing the point somewhere along the way? Just one of the mistakes lurking in the schema > > Second question: If I wanted to know the media size for an inserted > sheet where should I look to find the information? Media or > MediaCol\MediaSize or MediaCol\MediaKey or MediaCol\MediaSizeName or do > a search of all of the above? It depends on how the client intends to specify the inserted sheet. The standard way to specify inserted sheets, or desired media, is "Media". The well known values for media are taken from PWG51001.1 and have well defined sizes. There are also standard ways to define custom sizes. "MediaCol" is used on higher end Printers. So you may use "MediaCol" to specify media on high end machines to precisely define the intent for you media selection. The "MediaCol" element contains "MediaSize" that is a numerical width and height dimension pair. Determining the available sizes for inserted sheets depends on how the client intends to specify the "InsertSheet". You could use the element "Printer.ProcessingSupported.DocumentProcessing.InsertSheetSupported.Media Supported" that contains a sequence of available "Media". Alternatively you could use the "Printer.ProcessingSupported.DocumentProcessing.InsertSheetSupported.Media ColSupported.MediaSizeSupported" that contains a sequence of available "MediaSize"s. As for what you would query to determine the available sizes that would depend on the protocol mapping. PSI uses the elements above. IPP does not distinguish "JobProcessing" From "DocumentProcessing" and uses "job- template". You would use "GetPrinterAttributes" to request "insert-sheet- supported.media-supported" or "insert-sheet- supported.MediaColSupported.media-size-supported". A protocol like UPnP does things quite differently and you would need to pull down the SCPD file and parse the SST to find the "MediaSize" element that contains an "allowedValueList" of "allowedValues". UPnP's "MediaSize" maps directly to the Semantic Model's "MediaCol.MediaSizeName" > > Last question: has the PWG got any working examples or well formed XML > documents? It maybe is would be useful to try working with some real > world example. I generate them to help me check the Schema. Perhaps we can post some to help with the Last Call of the Schema > > Thanks for you time in reading this. > > Regards, > Geoff From PZehler at crt.xerox.com Wed Sep 17 10:46:24 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, I have no plans for a Semantic Model Teleconference until October 2nd. There are currently 3 IPP/SM specifications out for Last Call. Those specifications are for JobX, Overrides, and the Document Object. Please send any comment you have on them to the IPP mailing list. I would like to have a list of issues before the start of the upcoming NYC meeting. The SM Web page update is almost complete. I will announce when the new page goes live. Please raise any issues you have with the Semantic Mode on the Semantic Model mail list. The latest update brings the MasterListOfSemanticElements.xsd up to date, makes the copyright date format consistent in all the files, and corrects some spelling and sorting errors. A running list of changes is maintained at http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf . The only outstanding Semantic Model/Schema issues I am aware of are: 1) The use of #any for element extensions 2) Fixing the patterns for keyword/name/mime extensions 3) The recent submission from Geoff Soord regarding "Media" and "MediaCol" being mutually exclusive. (Comments on the SM mail list welcome) The SM teleconference on October 2nd will be the prep meeting for the face to face. If anyone has need of a meeting before that please let me know and I can schedule one. I will send out the phone/webex information and proposed agenda the week before the October 2nd teleconference. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030917/02622c29/attachment.html From imcdonald at sharplabs.com Wed Sep 17 11:09:48 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA537B001B3@mailsrvnt02.enet.sharplabs.com> Hi Pete, I'll be travelling on Thursday (2 October), so I'll miss your SM prep telecon - sorry about that. Cheers, - Ira -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Wednesday, September 17, 2003 10:46 AM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> Semantic Model Teleconference All, I have no plans for a Semantic Model Teleconference until October 2nd. There are currently 3 IPP/SM specifications out for Last Call. Those specifications are for JobX, Overrides, and the Document Object. Please send any comment you have on them to the IPP mailing list. I would like to have a list of issues before the start of the upcoming NYC meeting. The SM Web page update is almost complete. I will announce when the new page goes live. Please raise any issues you have with the Semantic Mode on the Semantic Model mail list. The latest update brings the MasterListOfSemanticElements.xsd up to date, makes the copyright date format consistent in all the files, and corrects some spelling and sorting errors. A running list of changes is maintained at http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf . The only outstanding Semantic Model/Schema issues I am aware of are: 1) The use of #any for element extensions 2) Fixing the patterns for keyword/name/mime extensions 3) The recent submission from Geoff Soord regarding "Media" and "MediaCol" being mutually exclusive. (Comments on the SM mail list welcome) The SM teleconference on October 2nd will be the prep meeting for the face to face. If anyone has need of a meeting before that please let me know and I can schedule one. I will send out the phone/webex information and proposed agenda the week before the October 2nd teleconference. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Sep 17 12:39:31 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Web Page Update Message-ID: All, The SM Web page (http://www.pwg.org/sm ) has been updated. (Thanks Gail) The page has links to the v0.95 and "Latest" schemas. The current version of the Semantic Model (v0.90 8/20/03) is linked in. Other updates include the registry of PWG Semantic Model elements, complex types, and keywords as well as the change log for the "Latest" schema. Please send any comments or issues on the Semantic Model and Schema to mailto:sm@pwg.org Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030917/a8b5bcfb/attachment.html From PZehler at crt.xerox.com Thu Sep 25 11:44:25 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Teleconference/Last Call Message-ID: All, There will be no SM teleconference today. The next scheduled teleconference is October 2nd. The JobX, Overrides and Document Object specifications are in Last call. Please send any comments and/or issues to mailto:ipp@pwg.org and I will collect them for review next week and at the Face-to-Face. I will send out the teleconference information later this week. At this time we have 4 editorial comments on JobX, 16 editorial comments and 3 issues with Document Object and nothing on Overrides. (Thanks Jerry) Please take a look at the documents so we can complete Last Call on these and move on to finalizing the Semantic Model and Schema. I've included Jerry's comments and issues below. Thanks, Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf ) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf ) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf ) No comments -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030925/7c0e773b/attachment.html From PZehler at crt.xerox.com Tue Sep 30 13:09:36 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Teleconference info (10/02) Message-ID: All, We will have a Semantic Model Teleconference this week. The teleconference details are below. The agenda is below. Please send out any comments/issues you wish to discuss during the teleconference by cob Wednesday. Current list of comments is appended below. Agenda: 1) Adjust agenda 2) Quick status of SM, Schema, JobX, Overrides and Document Object 3) Discuss upcoming face to face a. Tuesday SM (1/2 day pm) b. Thursday IPP extensions (1/2 day am) c. Thursday JobX (1/2 day pm) 4) Review any comments/issues a. Handle editorial first b. Discuss more involved comments and issues 5) Next steps Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 10/02/2003 Meeting Time: 11:50 AM CENTRAL TIME Instant Meeting Details: --------------------------- USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 Meeting Date: 09/30/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current list of comments.issues (9/30/03): Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf ) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf ) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf ) No comments -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030930/a86f58e7/attachment.html From imcdonald at sharplabs.com Tue Sep 30 13:28:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Teleconference info (10/02) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001D9@mailsrvnt02.enet.sharplabs.com> Hi Pete, Your SM agenda doesn't agree with the agenda posted by Harry Lewis (Amy's note this morning was out-of-date). The agenda for next week (according to Harry's note last Friday, 26 Sept): PWG - NYC Meeting - 2003 Details ---------------------------------------------------------------------------- ---- October 6 - 10, 2003 Grand Hyatt New York, NY ---------------------------------------------------------------------------- ---- Schedule: WBMM Monday 9:30 - 5:00 pm PSI Tuesday 8:30 - 5:00 pm Plenary Wednesday 8:30 - Noon and 1:00 pm - 2:30 pm CR Wednesday 2:30 - 5:30 pm IPP Exts Thursday 8:30 am - Noon /JobX Semantic Thursday 1:00 - 5:00 pm Model(SM) Notify / Friday 8:30 - 1:00 pm Discovery BOF Location: Park Avenue at Grand Central Station New York, New York 10017 USA 1 212 883 1234 http://grandnewyork.hyatt.com/property/index.jhtml Registration: https://www.ieee-isto.org/pwg/registration.html Cheers, - Ira McDonald High North Inc PS - I'll probably have to miss the SM telecon this Thursday, due to a time conflict. Good luck. -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, September 30, 2003 1:10 PM To: PWG Semantic Model WG (sm@pwg.org); IPP Discussion List (IPP@pwg.org) Subject: SM> Semantic Model Teleconference info (10/02) All, We will have a Semantic Model Teleconference this week. The teleconference details are below. The agenda is below. Please send out any comments/issues you wish to discuss during the teleconference by cob Wednesday. Current list of comments is appended below. Agenda: 1) Adjust agenda 2) Quick status of SM, Schema, JobX, Overrides and Document Object 3) Discuss upcoming face to face a. Tuesday SM (1/2 day pm) b. Thursday IPP extensions (1/2 day am) c. Thursday JobX (1/2 day pm) 4) Review any comments/issues a. Handle editorial first b. Discuss more involved comments and issues 5) Next steps Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 10/02/2003 Meeting Time: 11:50 AM CENTRAL TIME Instant Meeting Details: --------------------------- USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 Meeting Date: 09/30/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current list of comments.issues (9/30/03): Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf) No comments From PZehler at crt.xerox.com Thu Oct 2 11:54:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> REMINDER/corrected: Semantic Model Teleconference info (10/02) Message-ID: All, We will have a Semantic Model Teleconference this week at the usual time. The teleconference details are below. The agenda is below. Bring any new comment/issues you have with you and email them to me if possible. The current list of comments is appended below. Agenda: 1) Adjust agenda 2) Quick status of SM, Schema, JobX, Overrides and Document Object 3) Discuss upcoming face to face a. Thursday(1/2 day am) IPP extensions, JobX b. Thursday (1/2 day pm) SM 4) Review any comments/issues a. Handle editorial first b. Discuss more involved comments and issues 5) Next steps Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 10/02/2003 Meeting Time: 1:00 PM EASTERN (10:00 AM Pacific) Instant Meeting Details: --------------------------- USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 Meeting Date: 10/02/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current list of comments.issues (10/02/2003): Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf ) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf ) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf ) No comments -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031002/b8e33f34/attachment.html From imcdonald at sharplabs.com Fri Oct 10 09:24:08 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> Correct PHONE # below - Friday: Notification / Discovery BOF, 8:3 0 - 1:00 pm EDT Message-ID: <116DB56CD7DED511BC7800508B2CA537B001F3@mailsrvnt02.enet.sharplabs.com> Hi, As planned, today's Friday PWG Discovery/Notification BOF turns out to be on the IEEE/ISTO PWG conference bridge at: 1-866-365-4406 Passcode: 2635888# Do not use the Xerox bridge in Tom's note below. Cheers, - Ira -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Thursday, October 09, 2003 3:07 PM To: pwg-announce@pwg.org Subject: PWG-ANNOUNCE> Order of Agenda for Friday: Notification / Discovery BOF, 8:30 - 1:00 pm EDT Ira informed me that I was wanted for the Notification part of the BOF. I have a meeting conflict for the time 9:00-10:30 AM EDT. So if you could reverse the order of the topics and cover Discovery first starting at 8:30 EDT, I'll join you at 10:30 AM for the Notification discussion. I have converted the Notification spec [ipp-ntfy] to an IEEE-ISTO format for someone to take over as editor. I've moved 'job-forwarded-operation-failed' keyword value for use with the "notify-events" attribute from the IETF Internet-Draft Job and Printer Administrative Operations - Set2 to [ipp-ntfy], so that Set2 can make progress in the IETF without any mention of [ipp-ntfy]. I've made notes that other TO DO things for [ipp-ntfy] include: 1. Add event 'job-state-change-only' for PSI. (no state reason changes) 2. Add 'job-progress-error' and 'job-progress-warning-or-error' events for IPPFAX, etc Tom Call-in details: USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 From PZehler at crt.xerox.com Wed Oct 15 12:25:43 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, There will be no teleconference this week. I would appreciate it if in its place you could send your votes for the Document Object, JobX and Overrides specifications. The announcements were sent out on the PWG Announce mailing list. I will let you know later this week if we will have a telecom next week on the SM and Schema. If anyone has any items for the teleconference please send them to me. Thanks, Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031015/d67ec41e/attachment.html From PZehler at crt.xerox.com Tue Oct 21 10:49:42 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> No SM Telecon this week, Next on 10/30 Message-ID: All, I should be caught up by then and have stuff sent out this week. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031021/81817fca/attachment.html From PZehler at crt.xerox.com Mon Oct 27 11:40:07 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, This Thursday there will be a Semantic Model teleconference. The main objective of this teleconference is to begin the Last Call of the Semantic Model and associated schema. The proposed agenda for the 30th will be as follows. 1) Quick Status a. Results of vote on three IPP extension specifications b. Current state of Semantic Model and Schema 2) Walk through known issues a. Exact location of Media related elements within schema b. Pattern problems for extension of well known values (Schema only) c. Post some valid XML document to assist in Last Call d. Other issues 3) Next steps The Latest (i.e. October 24, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031024.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.96) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 10/30/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031027/722c818b/attachment.html From PZehler at crt.xerox.com Wed Nov 5 09:18:09 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> No SM Telecon this week...keep reviewing spec and raising those Last Call issues Message-ID: Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031105/f4523632/attachment.html From PZehler at crt.xerox.com Mon Nov 10 14:00:45 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> No SM teleconference this week Message-ID: Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031110/8ff064c2/attachment.html From PZehler at crt.xerox.com Mon Nov 10 14:24:46 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:32 2009 Subject: SM> JobStateReasons issue Message-ID: All, The values in the Semantic Model document do not line up with those in the Schema or in the referenced specifications. In order to keep the mapping clean and to maintain alignment with JDF I propose the following changes in the JobStateReasons keywords entry on page 44 of the Semantic Model spec (JobStateReasons entry in Job Element Table). Below are the corrected values. I also need to update the reference column to include JobX and Prod-Print. Current SM value -> Corrected SM Value __________________________________ CanceledAtDevice -> JobCanceledAtDevice CanceledByOperator -> JobCanceledByOperator CanceledByUser -> JobCanceledAtUser CompletedSuccessfully -> JobCompletedSuccessfully CompletedWithErrors -> JobCompletedWithErrors CompletedWithWarnings -> JobCompletedWarnings Incoming -> JobIncoming Interpreting -> JobInterpreting Outgoing -> JobOutgoing Printing -> JobPrinting Queued -> JobQueued QueuedForMarker -> JobQueuedForMarker Transforming -> JobTransforming Comments? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031110/c577edb3/attachment.html From imcdonald at sharplabs.com Mon Nov 10 20:11:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:32 2009 Subject: SM> JobStateReasons issue Message-ID: <116DB56CD7DED511BC7800508B2CA537B0022F@mailsrvnt02.enet.sharplabs.com> Hi Pete, I agree with your proposed changes - clean 'em up! Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Monday, November 10, 2003 2:25 PM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> JobStateReasons issue All, The values in the Semantic Model document do not line up with those in the Schema or in the referenced specifications. In order to keep the mapping clean and to maintain alignment with JDF I propose the following changes in the JobStateReasons keywords entry on page 44 of the Semantic Model spec (JobStateReasons entry in Job Element Table). Below are the corrected values. I also need to update the reference column to include JobX and Prod-Print. Current SM value -> Corrected SM Value __________________________________ CanceledAtDevice -> JobCanceledAtDevice CanceledByOperator -> JobCanceledByOperator CanceledByUser -> JobCanceledAtUser CompletedSuccessfully -> JobCompletedSuccessfully CompletedWithErrors -> JobCompletedWithErrors CompletedWithWarnings -> JobCompletedWarnings Incoming -> JobIncoming Interpreting -> JobInterpreting Outgoing -> JobOutgoing Printing -> JobPrinting Queued -> JobQueued QueuedForMarker -> JobQueuedForMarker Transforming -> JobTransforming Comments? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Nov 12 13:27:03 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:33 2009 Subject: SM> JobStateReasons issue Message-ID: Bob, The change was not intentional. It was a cut and paste error in the mail note. The actual values are derived directly from the IPP specs. The correct values are CanceledByUser -> JobCanceledByUser CompletedWithWarnings -> JobCompletedWithWarnings I cut and pasted the full contents of JobStateReason's "Description (values)" entry below. Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Provides additional information about this Job's current state. (Keywords: AbortedBySystem, CompressionError, DigitalSignatureDidNotVerify, DigitalSignatureTypeNotSupported, DocumentAccessError, DocumentFormatError, ErrorsDetected, JobCanceledAtDevice, JobCanceledByOperator, JobCanceledByUser, JobCompletedSuccessfully, JobCompletedWithErrors, JobCompletedWithWarnings, JobDataInsufficient, JobDigitalSignatureWait, JobHoldUntilSpecified, JobIncoming, JobInterpreting, JobOutgoing, JobPasswordWait, JobPrinting, JobQueued, JobQueuedForMarker, JobRestartable, JobResuming, JobSavedSuccessfully, JobSaveError, JobSaving, JobScheduling, JobSpooling, JobStreaming, JobSuspended, JobSuspendedByOperator, JobSuspendedBySystem, JobSuspendedByUser, JobSuspending, JobTransforming, None, PrinterStopped, PrinterStoppedPartly, ProcessingToStopPoint, ProofPrintWait, QueuedInDevice, ResourcesAreNotReady, ResourcesAreNotSupported, ServiceOffLine, SubmissionInterrupted, UnsupportedCompression, UnsupportedDocumentFormat, WarningsDetected) -----Original Message----- From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com] Sent: Wednesday, November 12, 2003 1:05 PM To: Zehler, Peter; PWG Semantic Model WG (sm@pwg.org) Subject: RE: SM> JobStateReasons issue Hi Pete, While most of these just pre-pend "Job" on value, a few change the value (CanceledByUser -> JobCanceledAtUser, CompletedWithWarnings -> JobCompletedWarnings, etc.). Were these intentional? bt -----Original Message----- From: owner-sm@pwg.org [mailto:owner-sm@pwg.org] On Behalf Of Zehler, Peter Sent: Monday, November 10, 2003 11:25 AM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> JobStateReasons issue All, The values in the Semantic Model document do not line up with those in the Schema or in the referenced specifications. In order to keep the mapping clean and to maintain alignment with JDF I propose the following changes in the JobStateReasons keywords entry on page 44 of the Semantic Model spec (JobStateReasons entry in Job Element Table). Below are the corrected values. I also need to update the reference column to include JobX and Prod-Print. Current SM value -> Corrected SM Value __________________________________ CanceledAtDevice -> JobCanceledAtDevice CanceledByOperator -> JobCanceledByOperator CanceledByUser -> JobCanceledAtUser CompletedSuccessfully -> JobCompletedSuccessfully CompletedWithErrors -> JobCompletedWithErrors CompletedWithWarnings -> JobCompletedWarnings Incoming -> JobIncoming Interpreting -> JobInterpreting Outgoing -> JobOutgoing Printing -> JobPrinting Queued -> JobQueued QueuedForMarker -> JobQueuedForMarker Transforming -> JobTransforming Comments? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031112/8ad4c04d/attachment.html From imcdonald at sharplabs.com Mon Nov 17 11:26:20 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:33 2009 Subject: SM> FW: [printing-jobticket] Updated JTAPI UML diagram Message-ID: <116DB56CD7DED511BC7800508B2CA537B00244@mailsrvnt02.enet.sharplabs.com> Hi, FYI - the FSG Job Ticket API UML diagrams have been updated for recent design tweaks and new content from PWG IPP JobX and JDF/1.2 work. The FSG JTAPI working group has begun development of the Alpha version of the JTAPI/1.0 C language header files. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Claudia Alimpich [mailto:alimpich@us.ibm.com] Sent: Thursday, November 13, 2003 7:42 PM To: printing-jobticket@freestandards.org Subject: [printing-jobticket] Updated JTAPI UML diagram The JTAPI UML diagrams have been updated to include some changes that I have had marked up on my copy for some time now. The png files are located in the following directory on the PWG site: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JTAPI_Diagrams/13Nov2003/ The following changes were made to the UML diagrams: 1. Modified JobTicketInfo object - Remove the jt-id attribute and id data member - Renamed the jt-length-units attribute to jt-length-unit and lengthUnits data member to lengthUnit - Removed the jt-syntax-version attribute and jtSyntaxVersion data member - Renamed the jt-type attribute to jt-type-and-version and the type data member to typeAndVersion - Added a "*" jt-version indicating that it will not be implemented in 1.0 2. Modified Job object - Added the job-print-content-optimize attribute and printContentOptimize data member. It will not be implemented 1.0. 3. Modified Destination object - Added missing constructor, destructor, get, getAttributeNames, and set methods 4. Modified CollateEnum - Renamed SHEET_AND_JOB value to SHEET_AND_DOC 5. Modified ContactTypeEnum - Added SENDER value 6. Modified HoldEnum - Renamed HOLD_DEFINITELY value to DEFINITE 7. Modified JobTicketTypeEnum - Renamed to JobTicketTypeVersionEnum - Renamed JDF value to JDF_1.2 - Renamed PWG value to PWG_1.2 8. Modified LengthUnitsEnum - Renamed to LengthUnitEnum 9. Added PrintContentOptimizeEnum 10. Modified PresentationDirectionEnum - Renamed all values from xyz format to format used by IPP (for example renamed the value "xyz" the much more readable "TO_RIGHT_TO_BOTTOM") 11. Modified PrintQualityEnum - Removed ECONOMY, FINE, and PHOTO values since we now have a separate attribute and the values in PrintContentOptimizeEnum. 12. Modified SidesEnum - Renamed values to use SHORT_EDGE and LONG_EDGE instead of FLIP_X and FLIP_Y terminology Claudia _______________________________________________ printing-jobticket mailing list printing-jobticket@freestandards.org http://freestandards.org/mailman/listinfo/printing-jobticket From PZehler at crt.xerox.com Tue Nov 18 08:09:49 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:33 2009 Subject: SM> Proposed time change for Teleconference Message-ID: All, I would like to have a teleconference to prep for the face to face I have an unavoidable conflict at our usual time. Unless there is any objection I would like to have a two hour teleconference on Friday November 21 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 21st will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/21/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031118/1be21c8d/attachment.html From imcdonald at sharplabs.com Tue Nov 18 21:18:42 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:33 2009 Subject: SM> Proposed time change for Teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA537B00257@mailsrvnt02.enet.sharplabs.com> Hi Pete, I'll probably be somewhere on the highway at that time Friday (and ALSO at that time Thursday). I have a musical gig in Wausau, WI (300 miles west of Grand Marais) from 9pm Thur until 2am Friday. Have a good teleconference. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, November 18, 2003 8:10 AM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> Proposed time change for Teleconference All, I would like to have a teleconference to prep for the face to face I have an unavoidable conflict at our usual time. Unless there is any objection I would like to have a two hour teleconference on Friday November 21 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 21st will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/21/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Nov 19 08:25:45 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:33 2009 Subject: SM> Another proposed time change for Teleconference Message-ID: All, Since Bob and Ira had conflicts on Friday I would like to change the SM teleconference date again. Unless there is any objection I would like to have a two hour teleconference on Tuesday November 25 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 25th will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/25/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031119/847227ec/attachment.html From harryl at us.ibm.com Wed Nov 19 10:48:27 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:33 2009 Subject: SM> Another proposed time change for Teleconference In-Reply-To: Message-ID: I'm on vacation (and off radar) that week... but go ahead... we need all the focus on this we can get leading up to Provo. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- "Zehler, Peter" Sent by: owner-sm@pwg.org 11/19/2003 06:25 AM To "PWG Semantic Model WG (sm@pwg.org)" cc Subject SM> Another proposed time change for Teleconference All, Since Bob and Ira had conflicts on Friday I would like to change the SM teleconference date again. Unless there is any objection I would like to have a two hour teleconference on Tuesday November 25 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 25th will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/25/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031119/7500e4b6/attachment.html From PZehler at crt.xerox.com Tue Nov 25 09:39:18 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:33 2009 Subject: SM> Today's Teleconference reminder Message-ID: All, Just a reminder for today's teleconference Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -----Original Message----- From: Zehler, Peter Sent: Wednesday, November 19, 2003 8:26 AM To: PWG Semantic Model WG (sm@pwg.org) Subject : Another proposed time change for Teleconference All, Since Bob and Ira had conflicts on Friday I would like to change the SM teleconference date again. Unless there is any objection I would like to have a two hour teleconference on Tuesday November 25 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 25th will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/25/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031125/6be9ce13/attachment.html From PZehler at crt.xerox.com Wed Dec 3 08:22:36 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:33 2009 Subject: SM> Today's SM meeting Documents Message-ID: All, I have uploaded the documents I plan to use at today's meetin to the PWG ftp site. ftp://ftp.pwg.org/pub/pwg/Semantic-Model/ProvoSmMtg.zip Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031203/d3da8b6c/attachment.html From PZehler at crt.xerox.com Mon Jan 6 08:42:24 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> This week's SM teleconference agenda and information Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. The teleconference is one hour long. It will be run using both phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is 1) Adjust agenda 2) Collect comments and issues on version 17 of the Semantic Model Specification (ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf ) Maui version of the document needs to be final this week. Version with revision marks available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-17-021207-rev.pd f 3) Review schema reorganization. (Latest schema (v0.91) to be published soon under http://www.pwg.org/schemas/sm/latest/ ) Local version available for download at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Schema/latestLocalVersion.zip 4) Plan Maui Semantic Model meeting 5) Next steps Pete All, 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 PS to Bob Taylor: Let me know if there is any problem with Webex for this week. ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 1/9/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ From PZehler at crt.xerox.com Mon Jan 6 08:55:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Action Required (comments and issues) Message-ID: All, Please review the PWG Semantic Model Specification version 17 (ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-17-021207.pdf). Send your comments or issues to the Semantic Model mail list by the close of business Thursday January 9. I would like to include them in the version for review at the Maui meeting that is due to be sent out on January 10. A version of the specification with revision marks from version 15 is available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-17-021207-rev.pd f Version 15 was the last released version of the document before version 17. 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 From PZehler at crt.xerox.com Tue Jan 7 09:10:34 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> RE: PWG Pattern vs. QName Message-ID: Bob, The only reason I know of now for the patterns is to keep the types used in the union the same. As I recall HP had some problem with a union of two different types. The pattern is defining a QName. (When defining the schema I was focused in reducing the number of types used and overlooked QName) I have no objection to going with QName wherever we are doing extensions federated by a namespace. The elements to be changed are MediaNsExtensionPattern, KeywordExtensionPattern and StringNsExtensionPattern and all the elements that use them. Any objections to making the change? 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: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com] Sent: Thursday, December 19, 2002 8:16 PM To: Peter Zehler [Xerox] (E-mail) Subject: FW: PWG Pattern vs. QName Hi Pete, I got pinged on this internally, and didn't have a good answer. Do we just have these patterns declared to avoid doing a union of NMTOKEN & QName? If not, these patterns look a lot like they are just restricting NMTOKEN to a qualified name. thanks, bt -----Original Message----- From: JARVIS,DAN (HP-Boise,ex1) Sent: Thursday, December 19, 2002 1:03 PM To: TAYLOR,BOB (HP-Vancouver,ex1) Cc: SCHMELING,GARTH (HP-Boise,ex1); HELMS,JANINE (HP-Boise,ex1); FOSTER,WARD (HP-Boise,ex1) Subject: PWG Pattern vs. QName Bob- The following two simple types in the PWG schemas define a pattern that appears to be describing a QName: * MediaNsExtensionPattern (in MediaWellKnownValues.xsd) * KeywordNsExtensionPattern (in PwgWellKnownValues.xsd) Is this pattern intended to be a QName? If so, why is a seemingly complex pattern being used rather than QName? -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030107/e2d188f9/attachment-0001.html From dhall at hp.com Tue Jan 7 18:34:56 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:38 2009 Subject: SM> Union construct for 0.95 Message-ID: <77261E830267D411BD4D00902740AC250DB4C400@xvan01.vcd.hp.com> Hey All During todays PSI meeting, the issue of toolkit support for the union construct in schema definitions came up. In general, one of our goals for the PSI spec is to provide a specification that has a high probability of interoperatibility between different vendors. There are three options available to address the union construct: 1) Leave it as it is, and deal with the toolkits lack of support on a case by case basis. This has the advantage of keeping the specification "pure", but has the dis-advantage of near term interop problems. 2) For the interim, modify the Common Semantic Model to not utilize the union construct. As the toolkits add support, eventually roll the union construct back into the semantic model. This gets us better interop in the near term, but may add turmoil when we re-introduce the union construce. 3) In PSI, duplicate the object defnintions that contain the element refences to the types that are defined by union, and define them directly as an NMTOKEN. In otherwords, create a PSI_DocumentDescription.xsd that has: instead of: This has the advantage of keeping the semantic model "pure", but has the dis-advantage of duplicated container object definitions.. Thoughts / Opinions? Dave From PZehler at crt.xerox.com Wed Jan 8 13:26:00 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> The latest PWG Semantic Model Schema is now available Message-ID: All, The latest PWG Semantic Model Schema (v0.91) is available on the PWG Web site. The Semantic Model web page has been updated (thanks Gail) and is located at . As agreed the namespace for the schema is . The intent of this schema is to provide the latest version of the PWG schema. The contents of this schema may change at any time. Numbered versions, such as v0.90 below, are formal checkpoints and will not be modified. The schemas themselves are located at . For example the Printer Status schema is located at . See the web page for a list of all the schemas. One major change is that there is no longer a single file containing the master list of semantic elements. The semantic elements are now contained in the file that references them. The PwgCommon.xsd file contains elements that are referenced by more than one file. The PWG Semantic Model Schema v0.90 is still available on the PWG Web site. The namespace for this schema is . The schemas themselves are located at . For example the semantic element master list is located at . See the web page for a list of all the schemas. 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 From hastings at cp10.es.xerox.com Wed Jan 8 14:13:39 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> SM/CIP4/PODi/FSG Color & Imaging telecon: Thur, Jan 9, 12:30-3:30 EST (9:30-12:30 PST) Message-ID: For the PWG Semantic Model WG. We're hoping to finish up the review of the IPP color and imaging attributes in the context of JDF. Unfortunately, the time of this three hour meeting overlaps with the regular SM WG Thursday one hour meeting. I'm sorry for the conflict for those who want to attend both. Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, January 07, 2003 19:28 To: printing-jobticket@freestandards.org Cc: 'thor.olsen@efi.com'; 'NIELSEN,MARY (HP-Boise,ex1)'; 'ted_podelnyk@hp.com'; 'Rick.Keeney@efi.com'; Hastings, Tom N Subject: CIP4/PODi/FSG Color & Imaging telecon: Thur, Jan 9, 12:30-3:30 EST (9:30-12:30 PST) Meeting Date: January 09, 2003 Start Time (hh:mm) 9:30 AM PST 10:30 AM America/Denver 12:30 AM EST MeetingPlace Telephone numbers: US and International Calls: 1+ 650-690-9367 Telnet Number (HP employees only): T348-9367 Meeting ID: 2474 Meeting Password: 123 Meeting Name: NIELSEN,MARY Meeting Length: 3 hours We'll also use HP webex: http://hp.webex.com Agenda: Resolve subset of the 70 issues in JDF subset mapping table and JDF/1.1a updated with proposed extensions. Tom to make an agenda with list of ISSUES in order to be processed. I've updated the documents from the last telecons in December. They are available as previously announced: Finish reviewing the color and imaging attribute subset of JDF and mapping from IPP: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c and the JDF/1.2 extensions: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip The detailed IPP Color and Imaging attributes spec that the table references is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg-ipp-color-and-imaging-latest-rev .zip Tom P.S. As we have agreed, for each "latest" version, I also store an identical copy with the date in the title. Here are the correspondences between the "latest" version and the titled files: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev.doc ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.zi p ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev.zip I've also stored the .pdf with just color and with all of the attributes: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev-color-only.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-6-Jan-200 3-rev-all-attrs.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-030107.zip ----- This message was submitted by Tom Hastings (Xerox) Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=4408 Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=7 From dhall at hp.com Thu Jan 9 11:50:14 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:38 2009 Subject: SM> Semantic Model Review Comments Message-ID: <77261E830267D411BD4D00902740AC250DB4C429@xvan01.vcd.hp.com> Hey Pete.. Here is my feedback for the specification. It's looking really good! :) Dave Page 7: Document definition - do we need a mention of multiple files? Document Description Elements - Need to add? Page 11: 4.1.2: The PrinterDescriptionElements contains many *Supported. A short discussion about the differences between the *Supported and the ProcessingSupported object would be helpful. Page 12: Line 256 - Five groups? Add ProcessingActual? Page 14: Line 299 - Four groups? Add DocumentProcessingActual? From hastings at cp10.es.xerox.com Tue Jan 14 01:13:09 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> Joint telecon: Fri, Jan-17, CIP4/PODi/FSG Color and Imaging attri butes Message-ID: Teleconference: Friday, January 17, 2003 650-690-9367 (T348-9367 inside HP) Meeting ID: 2474 (spelled cip4 on a phone) NO password https://hp.webex.com/ Meeting Number: 21162802 Meeting Password: colors Agenda: 6. Address 18 ISSUES in JDF spec with the proposed color extensions. Those issues that don't have anything to do with color will be left for Digital Printing WG and CIP4 to resolve. 7. Address 70 ISSUES in the IPPJDF mapping table document. Those issues that don't have anything to do with color will be left for Digital Printing WG and CIP4 to resolve. I've down loaded a January 13, version of these two specs: Finish reviewing the color and imaging attribute subset of JDF and mapping from IPP: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c and the JDF/1.2 extensions: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip The detailed IPP Color and Imaging attributes spec that the table references is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg-ipp-color-and-imaging-latest-rev .zip Tom P.S. As we have agreed, for each "latest" version, I also store an identical copy with the date in the title. Here are the correspondences between the "latest" version and the titled files: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev.doc ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.zi p ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev.zip I've also stored the .pdf with just color and with all of the attributes: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev-color-only.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-13-Jan-20 03-rev-all-attrs.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-030113.zip From PZehler at crt.xerox.com Tue Jan 14 12:54:06 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> No teleconference on 1/16 or 1/23 Message-ID: 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 From PZehler at crt.xerox.com Tue Jan 14 13:04:37 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Semantic Model Document v0.18 for review at Maui meeting availabl e Message-ID: All, The latest version of the Semantic Model document is available at . This is version 0.18 of the document and is dated January 13, 2003. This document will be used during the section by section review at the Maui meeting. Please bring any comments, issues or complaints with you to Maui. Those not attending can send them to the Semantic Model mailing list. After the Maui meeting a new version will be published for last call moving the specification from a working document to a PWG draft. As always red-lined versions and .docs are available at the following URLs 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 From PZehler at crt.xerox.com Tue Jan 14 13:58:17 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Agenda for Semantic Model Face to Face Message-ID: All, Here is what I have so far for the face to face. Let me know if you have any additions. 1) Introductions and Agenda bashing 2) PWG Semantic Model section by section review to prepare for last call work through simple issues, defer ones that take too long 3) Schema overview of changes Discuss organization issues and type/element naming 4) Document Object Close outstanding issues to prepare for last call 5) Processing Actual Close any outstanding issues review schema representation 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 From hastings at cp10.es.xerox.com Fri Jan 17 05:46:16 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> Version 0.6 of the IPP Document object specification is available Message-ID: I've stored version 0.6 of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .doc Version 0.6 contains the agreements reached at the last PWG face to face and on the SM telecons. Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just posted. The issues will be reviewed during the PWG Semantic Model face to face meeting, Thursday, 23. Is this specification ready for Last Call? Here are 9 ISSUES: ISSUE 01: It is the [override] specification the allowed these four "compression", "document-format", "document-name", and "document-natural-language" operation attributes to be supplied in the Create-Job request. There needs to be a way for a client to query to see what was submitted. Possible solutions: a. OK to have the exception to the no copy down rule for these four which do not have any corresponding Job Description attributes to hold them? Otherwise, there would be no queriable record of what the client had supplied when the client only supplies them in the Create-Job operation. b. Or would it be better, simpler, and more consistent to define the four corresponding Job Description attributes and have the Printer just copy the operation attributes to them, like most other operation attributes? c. Or should we forget the [override] extension and go back to the RFC2911 Create-Job definition (see [RFC2911] section 3.2.4) which does not allow these four operation attributes to be submitted in the Create-Job, but requires that the client supply them each time in each Send-Document and Sent-URI operation, if the client wants to submit them at all. Then the Printer just copies them to the corresponding Document Description attributes and there is no inheritance problem between the Job and Document level for these four attributes. ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 04: Is the definition of "document-format-detail" OK? ISSUE 05: Should we call this member attribute "os-type", instead of "platform", in order to agree with the PWG Printer Installation Extension (see draft-ietf-ipp-install-04.txt)? ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 06: This is a change from [override], OK? ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 07: This is a change from [override], OK? ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? Version 0.6, 13 January 2003, agreements from New Orleans October PWG meeting and subsequent telecons: 1. Deleted the Cancel-Current-Document and Validate-Document operations. 2. Deprecated the "input-document-number" operation attribute from the Document Creation operations. 3. Deleted the "document-mandatory-attributes" operation attribute to align with the PWG Semantic model. So both specifications have only the "job-mandatory-attributes" operation attribute. The client can only supply at the Job Level. The Document Level inherits from the Job Level. 4. Increased "document-message" operation attribute length from 127 to MAX (1023) octets. 5. Clarified that "ipp-attribute-fidelity" and "job-mandatory-attributes" can only be supplied at the Job Level; the Document level inherits their values. 6. Added "ipp-attribute-fidelity" and "job-mandatory-attributes" Job Description attributes. 7. Added the "media-size-name" as a member attribute of "media-col" and as a separate Job Template attribute as used by UPnPv1 and UPnPv2. 8. Added the "media-type" as a Job and Document Template attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as a member attribute of the "media-col" Job and Document Template attributes). 9. Renamed "document-printer-up-time" Document Description attribute to simply "printer-up-time". 10. Added the following Job Description attributes: "ipp-attribute-fidelity", and "job-mandatory-attributes". 11. Removed the following Document Description attributes: "ipp-attribute-fidelity". 12. Added the following Document Description attributes: "document-format-detail", "document-format-detected", "job-id", "job-printer-uri", "job-uri", "output-device-assigned". 13. Defined all of the Document Description attributes, often with references to other specifications, so that they appear in the table of contents. Send comments to the mailing list. Thanks, Tom P.S. I'll not be attending the meeting. From hastings at cp10.es.xerox.com Fri Jan 17 16:55:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> IPP/SM ISSUE 10: Name of JobMandatoryElements Message-ID: Here is ISSUE 10 to be added to the 9 ISSUE. This one affects both the IPP Document object spec and the PWG Semantic Model document. Version 0.6 of the IPP Document object specification aligns with the attributes of the Semantic Model version 0.18. The Semantic Model has the Job Description Element: JobMandatoryElements The values are a list of Element names of the Job Processing and Document Processing Elements that the submitter wants to be Mandatory, else the provider MUST reject the request. The IPP Document object spec has the "job-mandatory-attributes" (1setOf type2 keyword) operation attribute which the Printer copies to the corresponding "job-mandatory-attributes" Job Description attributes. The values are a list of the keyword names of the Job Template and Document Template attributs that the submitter wants to be Mandatory, else the provider MUST reject the request. Neither spec allows this same Element/attribute to also be a Document Description Element/attribute. This simplification is fine. So whatever Job and Document Elements/attributes are declared to be mandatory at the Job level must be mandatory at the Document level as well. A possible extension in the future might be to allow the submitted to submit this Element/Attribute in a Document Creation request. If that ever happens, we will regret that its name started with "Job"/"job-", because we have to invent a new name with the "Job"/"job-" prefix either removed or change to something else, like "Document"/"document-". Since the values are already contaiing both job and document attributes, I don't see any problem with just dropping the "Job"/"job-" prefix now. But I'm not suggesting that the renamed Element/attribute can be submitted at the Document level. A further agrument of removing the "Job"/"job-" prefix is that a closely relate Element/attribute: ElementFidelity/"ipp-attribute-fidelity" is also limited to being a Job level attribute by being a Job Description attribute and not a Document Description attribute. However, it too also affects both job and document attributes making them all mandatory. Comments? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, January 17, 2003 02:46 To: sm@pwg.org Subject: SM> Version 0.6 of the IPP Document object specification is available I've stored version 0.6 of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .doc Version 0.6 contains the agreements reached at the last PWG face to face and on the SM telecons. Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just posted. The issues will be reviewed during the PWG Semantic Model face to face meeting, Thursday, 23. Is this specification ready for Last Call? Here are 9 ISSUES: ISSUE 01: It is the [override] specification the allowed these four "compression", "document-format", "document-name", and "document-natural-language" operation attributes to be supplied in the Create-Job request. There needs to be a way for a client to query to see what was submitted. Possible solutions: a. OK to have the exception to the no copy down rule for these four which do not have any corresponding Job Description attributes to hold them? Otherwise, there would be no queriable record of what the client had supplied when the client only supplies them in the Create-Job operation. b. Or would it be better, simpler, and more consistent to define the four corresponding Job Description attributes and have the Printer just copy the operation attributes to them, like most other operation attributes? c. Or should we forget the [override] extension and go back to the RFC2911 Create-Job definition (see [RFC2911] section 3.2.4) which does not allow these four operation attributes to be submitted in the Create-Job, but requires that the client supply them each time in each Send-Document and Sent-URI operation, if the client wants to submit them at all. Then the Printer just copies them to the corresponding Document Description attributes and there is no inheritance problem between the Job and Document level for these four attributes. ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 04: Is the definition of "document-format-detail" OK? ISSUE 05: Should we call this member attribute "os-type", instead of "platform", in order to agree with the PWG Printer Installation Extension (see draft-ietf-ipp-install-04.txt)? ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 06: This is a change from [override], OK? ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 07: This is a change from [override], OK? ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? Version 0.6, 13 January 2003, agreements from New Orleans October PWG meeting and subsequent telecons: 1. Deleted the Cancel-Current-Document and Validate-Document operations. 2. Deprecated the "input-document-number" operation attribute from the Document Creation operations. 3. Deleted the "document-mandatory-attributes" operation attribute to align with the PWG Semantic model. So both specifications have only the "job-mandatory-attributes" operation attribute. The client can only supply at the Job Level. The Document Level inherits from the Job Level. 4. Increased "document-message" operation attribute length from 127 to MAX (1023) octets. 5. Clarified that "ipp-attribute-fidelity" and "job-mandatory-attributes" can only be supplied at the Job Level; the Document level inherits their values. 6. Added "ipp-attribute-fidelity" and "job-mandatory-attributes" Job Description attributes. 7. Added the "media-size-name" as a member attribute of "media-col" and as a separate Job Template attribute as used by UPnPv1 and UPnPv2. 8. Added the "media-type" as a Job and Document Template attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as a member attribute of the "media-col" Job and Document Template attributes). 9. Renamed "document-printer-up-time" Document Description attribute to simply "printer-up-time". 10. Added the following Job Description attributes: "ipp-attribute-fidelity", and "job-mandatory-attributes". 11. Removed the following Document Description attributes: "ipp-attribute-fidelity". 12. Added the following Document Description attributes: "document-format-detail", "document-format-detected", "job-id", "job-printer-uri", "job-uri", "output-device-assigned". 13. Defined all of the Document Description attributes, often with references to other specifications, so that they appear in the table of contents. Send comments to the mailing list. Thanks, Tom P.S. I'll not be attending the meeting. From hastings at cp10.es.xerox.com Fri Jan 17 23:01:12 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> FW: Completed JDF Color extension spec and IPP mapping specs, 17- Jan-2003, available Message-ID: -----Original Message----- From: Hastings, Tom N Sent: Friday, January 17, 2003 20:00 To: 'color_workflow@cip4.org' Subject: Completed JDF Color extension spec and IPP mapping specs, 17-Jan-2003, available The joint Digital Printing and Color Workflow WG project to add more color and imaging to JDF/1.2 based after reviewing the IPP Color and Imaging attributes has completed its proposed set of updates. I've down loaded a January 17, version of these two specs: The mapping of IPP color and imaging to JDF: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f and the JDF/1.2 extensions: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions/JDF1.1a-4Sept2002-wit h-color-ext-latest.zip The detailed IPP Color and Imaging attributes spec that the table references is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg-ipp-color-and-imaging-latest-rev .zip The .doc file has the non-color attributes as hidden text. To see go into MS-WORD and display hidden text (Tools/Options/View/Display Hidden Text). The .pdf versions don't show the non-color attributes. Tom P.S. As we have agreed, for each "latest" version, I also store an identical copy with the date in the title. Here are the correspondences between the "latest" version and the titled files: ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.do c ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-17-Jan-20 03-rev.doc ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.pd f ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-17-Jan-20 03-rev.pdf ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-latest.zi p ftp://ftp.pwg/org/pub/pwg/fsg/jobticket/IPP_Mapping/ippjdf-mapping-17-Jan-20 03-rev.zip From imcdonald at sharplabs.com Mon Jan 20 14:47:59 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:38 2009 Subject: SM> IPP/SM ISSUE 10: Name of JobMandatoryElements Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE8E@mailsrvnt02.enet.sharplabs.com> Hi Tom, Agreed - please drop the "job-" prefix throughout (SM and IPP). Cheers, - Ira -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, January 17, 2003 3:55 PM To: sm@pwg.org Subject: SM> IPP/SM ISSUE 10: Name of JobMandatoryElements Here is ISSUE 10 to be added to the 9 ISSUE. This one affects both the IPP Document object spec and the PWG Semantic Model document. Version 0.6 of the IPP Document object specification aligns with the attributes of the Semantic Model version 0.18. The Semantic Model has the Job Description Element: JobMandatoryElements The values are a list of Element names of the Job Processing and Document Processing Elements that the submitter wants to be Mandatory, else the provider MUST reject the request. The IPP Document object spec has the "job-mandatory-attributes" (1setOf type2 keyword) operation attribute which the Printer copies to the corresponding "job-mandatory-attributes" Job Description attributes. The values are a list of the keyword names of the Job Template and Document Template attributs that the submitter wants to be Mandatory, else the provider MUST reject the request. Neither spec allows this same Element/attribute to also be a Document Description Element/attribute. This simplification is fine. So whatever Job and Document Elements/attributes are declared to be mandatory at the Job level must be mandatory at the Document level as well. A possible extension in the future might be to allow the submitted to submit this Element/Attribute in a Document Creation request. If that ever happens, we will regret that its name started with "Job"/"job-", because we have to invent a new name with the "Job"/"job-" prefix either removed or change to something else, like "Document"/"document-". Since the values are already contaiing both job and document attributes, I don't see any problem with just dropping the "Job"/"job-" prefix now. But I'm not suggesting that the renamed Element/attribute can be submitted at the Document level. A further agrument of removing the "Job"/"job-" prefix is that a closely relate Element/attribute: ElementFidelity/"ipp-attribute-fidelity" is also limited to being a Job level attribute by being a Job Description attribute and not a Document Description attribute. However, it too also affects both job and document attributes making them all mandatory. Comments? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, January 17, 2003 02:46 To: sm@pwg.org Subject: SM> Version 0.6 of the IPP Document object specification is available I've stored version 0.6 of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev .doc Version 0.6 contains the agreements reached at the last PWG face to face and on the SM telecons. Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just posted. The issues will be reviewed during the PWG Semantic Model face to face meeting, Thursday, 23. Is this specification ready for Last Call? Here are 9 ISSUES: ISSUE 01: It is the [override] specification the allowed these four "compression", "document-format", "document-name", and "document-natural-language" operation attributes to be supplied in the Create-Job request. There needs to be a way for a client to query to see what was submitted. Possible solutions: a. OK to have the exception to the no copy down rule for these four which do not have any corresponding Job Description attributes to hold them? Otherwise, there would be no queriable record of what the client had supplied when the client only supplies them in the Create-Job operation. b. Or would it be better, simpler, and more consistent to define the four corresponding Job Description attributes and have the Printer just copy the operation attributes to them, like most other operation attributes? c. Or should we forget the [override] extension and go back to the RFC2911 Create-Job definition (see [RFC2911] section 3.2.4) which does not allow these four operation attributes to be submitted in the Create-Job, but requires that the client supply them each time in each Send-Document and Sent-URI operation, if the client wants to submit them at all. Then the Printer just copies them to the corresponding Document Description attributes and there is no inheritance problem between the Job and Document level for these four attributes. ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation attribute in Send-Document and Send-URI when supporting this specification? Or forbid? ISSUE 04: Is the definition of "document-format-detail" OK? ISSUE 05: Should we call this member attribute "os-type", instead of "platform", in order to agree with the PWG Printer Installation Extension (see draft-ietf-ipp-install-04.txt)? ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 06: This is a change from [override], OK? ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when supplied at the job level of a multi-document job depends on the value of the "multiple-document-handling" Job Template attribute. For the 'single-document' and 'single-document-new-sheet' values, the pages are numbered as a single set from 1 to n for the job as a whole. For the 'separate-documents-collated-copies' and 'separate-document-uncollated-copies' values, the pages are numbered from 1 to n for each document separately. ISSUE 07: This is a change from [override], OK? ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job Description attribute to go along with the Operation attribute with suitable security in Get-Job-Attributes response in order to align with the PWG Semantic Model, OK? Version 0.6, 13 January 2003, agreements from New Orleans October PWG meeting and subsequent telecons: 1. Deleted the Cancel-Current-Document and Validate-Document operations. 2. Deprecated the "input-document-number" operation attribute from the Document Creation operations. 3. Deleted the "document-mandatory-attributes" operation attribute to align with the PWG Semantic model. So both specifications have only the "job-mandatory-attributes" operation attribute. The client can only supply at the Job Level. The Document Level inherits from the Job Level. 4. Increased "document-message" operation attribute length from 127 to MAX (1023) octets. 5. Clarified that "ipp-attribute-fidelity" and "job-mandatory-attributes" can only be supplied at the Job Level; the Document level inherits their values. 6. Added "ipp-attribute-fidelity" and "job-mandatory-attributes" Job Description attributes. 7. Added the "media-size-name" as a member attribute of "media-col" and as a separate Job Template attribute as used by UPnPv1 and UPnPv2. 8. Added the "media-type" as a Job and Document Template attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as a member attribute of the "media-col" Job and Document Template attributes). 9. Renamed "document-printer-up-time" Document Description attribute to simply "printer-up-time". 10. Added the following Job Description attributes: "ipp-attribute-fidelity", and "job-mandatory-attributes". 11. Removed the following Document Description attributes: "ipp-attribute-fidelity". 12. Added the following Document Description attributes: "document-format-detail", "document-format-detected", "job-id", "job-printer-uri", "job-uri", "output-device-assigned". 13. Defined all of the Document Description attributes, often with references to other specifications, so that they appear in the table of contents. Send comments to the mailing list. Thanks, Tom P.S. I'll not be attending the meeting. From hastings at cp10.es.xerox.com Tue Jan 21 21:06:10 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> Adding 4 more member attributes to "document-format-detail" (coll ection) attribute Message-ID: PWG Semantic Model folks (and IPP WG folks), This is a similar mail message that I've send to the CIP4 JDF Capabilities WG. The IPP Document object spec has a "document-format-detail" (collection) attribute which contains member attributes that give more information about a document, such as "document-format-version", "document-format-natural-language", "platform", "device-id", and a recursive "document-format-details" (collection) to describe the unique Parts of an application/zip or multipart/related file. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf The IPP "document-format-details" (collection) attribute is much like the FileSpec resource in JDF. So I've downloaded a comparison of the IPP document format attributes including the proposed "document-format-detail" (collection) attribute and the JDF/1.1 FileSpec resource. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentParts. and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application", "application-version", "platform-version" (or "os-version"), "user-file-name" in order to align both of them and to take the features of one and make them available in the other. I'll be glad to write up the new JDF FileSpec attributes (if the CIP4 Capabilities WG likes the proposed semantics) and update the IPP Document object spec (if the PWG Semantic Model WG likes the proposed semantics). Comments? Thanks, Tom From imcdonald at sharplabs.com Wed Jan 22 16:44:06 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:38 2009 Subject: SM> Adding 4 more member attributes to "document-format-detai l" (coll ection) attribute Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE8F@mailsrvnt02.enet.sharplabs.com> Hi Tom, There's some confusion in your proposal below. The current "document-format-detail" member attribute "platform" and the proposed additional member attribute "platform-version" (or "os-version") are likely to be redundant. The only standardized source of values for all these attributes is the IANA registry of operating system names - it contains BOTH OS and version as a single string (e.g., "WINDOWS-95") and generally does NOT contain the simple name (e.g., there is no registered "WINDOWS" operating system). See: ftp://ftp.iana.org/assignments/operating-system-names In the IPP Driver Installation spec we have a single attribute "os-type" (with the values normalized to lowercase for IPP). See: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-install-04.txt Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, January 21, 2003 8:06 PM To: sm@pwg.org Cc: ipp@ipp.org Subject: SM> Adding 4 more member attributes to "document-format-detail" (coll ection) attribute PWG Semantic Model folks (and IPP WG folks), This is a similar mail message that I've send to the CIP4 JDF Capabilities WG. The IPP Document object spec has a "document-format-detail" (collection) attribute which contains member attributes that give more information about a document, such as "document-format-version", "document-format-natural-language", "platform", "device-id", and a recursive "document-format-details" (collection) to describe the unique Parts of an application/zip or multipart/related file. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf The IPP "document-format-details" (collection) attribute is much like the FileSpec resource in JDF. So I've downloaded a comparison of the IPP document format attributes including the proposed "document-format-detail" (collection) attribute and the JDF/1.1 FileSpec resource. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentParts. and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application", "application-version", "platform-version" (or "os-version"), "user-file-name" in order to align both of them and to take the features of one and make them available in the other. I'll be glad to write up the new JDF FileSpec attributes (if the CIP4 Capabilities WG likes the proposed semantics) and update the IPP Document object spec (if the PWG Semantic Model WG likes the proposed semantics). Comments? Thanks, Tom From hastings at cp10.es.xerox.com Wed Jan 22 21:20:34 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> Adding 4 more member attributes to "document-format-detai l" (coll ection) attribute Message-ID: For the Semantic Model face to face on Thursday: Ira and I talked today and we propose the following tweaks to the IPP and JDF proposals: 1. Don't use the term "platform" in the attribute name, use "os" or "operating-system (OS or OperatingSystem in JDF). The term "platform" often means the middleware. What we want here is the operating system. Also the IANA Registry is called Operating System Names. See: http://www.iana.org/assignments/operating-system-names 2. The IANA Registry has token strings without spaces that include the base operating system name and the version. Examples are: 'linux', 'linux-2.2', 'os/2', 'mac', 'mac-x', 'sun-os-4.0', 'unix', 'unix-bsd', 'win32', 'windows-95', 'windows-98', 'windows-ce', 'windows-nt', 'windows-nt-4', 'windows-nt-5', 'windows-2000', and 'unknown'. However, it is useful for software to determine the base operating system independent of the version and to also determine the version. To get both, it is simpler to have two attributes. We also propose that the second attribute (the one that includes the version), be the complete IANA registry entry, rather than just the version and be named: "os-name-and-version". Applications can then choose which attribute to match on and no parsing is needed. I've downloaded an updated proposal for IPP and JDF which in summary is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentPart. and clarify that and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application-name", "application-name-and-version", "os-name-and-version", and "user-file-name" in order to align both of them and to take the features of one and make them available in the other. Comments? Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, January 22, 2003 13:44 To: 'Hastings, Tom N'; sm@pwg.org Cc: ipp@ipp.org Subject: RE: SM> Adding 4 more member attributes to "document-format-detai l" (coll ection) attribute Hi Tom, There's some confusion in your proposal below. The current "document-format-detail" member attribute "platform" and the proposed additional member attribute "platform-version" (or "os-version") are likely to be redundant. The only standardized source of values for all these attributes is the IANA registry of operating system names - it contains BOTH OS and version as a single string (e.g., "WINDOWS-95") and generally does NOT contain the simple name (e.g., there is no registered "WINDOWS" operating system). See: ftp://ftp.iana.org/assignments/operating-system-names In the IPP Driver Installation spec we have a single attribute "os-type" (with the values normalized to lowercase for IPP). See: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-install-04.txt Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, January 21, 2003 8:06 PM To: sm@pwg.org Cc: ipp@ipp.org Subject: SM> Adding 4 more member attributes to "document-format-detail" (coll ection) attribute PWG Semantic Model folks (and IPP WG folks), This is a similar mail message that I've send to the CIP4 JDF Capabilities WG. The IPP Document object spec has a "document-format-detail" (collection) attribute which contains member attributes that give more information about a document, such as "document-format-version", "document-format-natural-language", "platform", "device-id", and a recursive "document-format-details" (collection) to describe the unique Parts of an application/zip or multipart/related file. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf The IPP "document-format-details" (collection) attribute is much like the FileSpec resource in JDF. So I've downloaded a comparison of the IPP document format attributes including the proposed "document-format-detail" (collection) attribute and the JDF/1.1 FileSpec resource. See: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.pdf (213K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.doc (264K) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/Comparison of JDF and IPP document-format-attrs.zip (33K) This downloaded document proposes adding 3 more attributes to JDF FileSpec resource: MimeTypeVersion, IEEE1284DeviceId, and DocumentParts. and 4 more member attributes to the proposed IPP "document-format-details (collection):: "application", "application-version", "platform-version" (or "os-version"), "user-file-name" in order to align both of them and to take the features of one and make them available in the other. I'll be glad to write up the new JDF FileSpec attributes (if the CIP4 Capabilities WG likes the proposed semantics) and update the IPP Document object spec (if the PWG Semantic Model WG likes the proposed semantics). Comments? Thanks, Tom From hastings at cp10.es.xerox.com Thu Jan 23 00:33:28 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> FW: PWG-IPP> Last Call Comments on IPP "-actual" Attributes Docum ent Message-ID: For the Semantic Model Team meeting on Thursday. Ron, Do you have a document the covers "ISTO requirements"? Harry had said a while ago that the ISTO was working on a revised template and/or requirements. Has any progress been made on that? Ira, Dennis, and I thought that it would be better to have the Abstract and names of the authors on the first page, in case the ISTO is accepting suggestions on their format. Tom -----Original Message----- From: Ron.Bergman@hitachi-ps.us [mailto:Ron.Bergman@hitachi-ps.us] Sent: Wednesday, January 22, 2003 15:37 To: pwg-ipp@pwg.org Subject: PWG-IPP> Last Call Comments on IPP "-actual" Attributes Document Technically the document looks very sound. The following comments are primarily editorial. 1. RFC 2565 and 2566 are obsolete. It is not appropriate to reference obsolete documents, especially as a normative reference. See Line 146 (in section 1 Introduction) Line 228 (in section 3 -actual attributes) Line 331 - 336 (in section 7.1 Normative References 2. In lines 151 & 152 recommend changing "(or are going to print)" to "(or are expected to be printed)" to be more consistent with the example in section 3.3. 3. In line 239 remove "that has the" and all of the text in the following line. This additional text adds nothing and results in a sentence that is very difficult to read. 4. In lines 279 and 280 there is a strange split (by WORD) of the string "-attribute". 5. The formatting of the document is not per ISTO requirements. Specifically page numbering and headers. Is there a procedure for format review prior to final publication? I propose that this needs to be established. Ron Bergman Hitachi Printing Solutions From imcdonald at sharplabs.com Sat Jan 25 19:59:04 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:38 2009 Subject: SM> draft-mcdonald-cip4-jdf-mime-00.txt (25 Jan 2003) Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE99@mailsrvnt02.enet.sharplabs.com> Copies: PWG Semantic Model FSG Job Ticket Tom Hastings Ira McDonald Hi folks, Saturday (25 January 2003) I've just sent 'The MIME application/vnd.cip4-jdf+xml Content-Type' to the Internet-Drafts editor and posted a copy on the PWG server in the directory 'ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JDF_extensions' in the files: - IETF-style plaintext - HTML w/ live TOC - PDF w/ live TOC Cheers, - Ira McDonald (editor of IANA Charset MIB) High North Inc imcdonald@sharplabs.com ------------------------------------------------------------------------ Copies: Internet Drafts Editor Tom Hastings Ira McDonald I-D Editor, Saturday (25 January 2003) Please place this document in the Internet-Drafts repository named: Abstract The International Cooperation for the Integration of Processes in Prepress, Press, and Postpress (CIP4) is an international worldwide standards body located in Switzerland. The purpose of CIP4 is to encourage computer based integration of all processes that have to be considered in the graphic arts industry. CIP4 has defined two document formats that are encoded in W3C Extensible Markup Language (XML): (1) CIP4 Job Definition Format (JDF) - an open standard for integration of all computer aided business and production processes around print media; (2) CIP4 Job Messaging Format (JMF) - an open standard for job messaging using Hyper Text Transport Protocol/1.1 (HTTP/1.1, RFC2616) that defines Query, Command, Response, Acknowledge, and Signal message families. This document defines two new MIME sub-types for IANA registration: (1) 'application/vnd.cip4-jdf+xml' for CIP4 Job Definition Format; (2) 'application/vnd.cip4-jmf+xml' for CIP4 Job Messaging Format. Thanks very much, - Ira McDonald (co-editor) High North Inc imcdonald@sharplabs.com From harryl at us.ibm.com Tue Jan 28 17:15:52 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:38 2009 Subject: SM> D.C. Friday schedule Message-ID: In D.C. , Semantic Model is on Friday. We should plan ahead when we plan to end the meeting. Most meetings go until 5pm but some end at 3pm on Friday so people can catch flights. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030128/d1e69e1b/attachment-0001.html From harryl at us.ibm.com Wed Jan 29 00:09:13 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:38 2009 Subject: SM> Updated Process Message-ID: In prep for a discussion during the SM call, tomorrow, I've updated the PWG process document. ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.doc This is a one-time notification to both reflectors. Further on-line discussion of the PWG process with occur ONLY on pwg@pwg.org ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030128/04779ac9/attachment-0001.html From imcdonald at sharplabs.com Wed Jan 29 13:59:55 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:38 2009 Subject: SM> [PDF of] Updated Process Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE9C@mailsrvnt02.enet.sharplabs.com> Hi folks, I ran the PWG process document through Acrobat Distiller to make a PDF version for those who don't have MS Word or Star Office installed: ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.pdf Cheers, - Ira McDonald High North Inc -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, January 28, 2003 11:09 PM To: pwg@pwg.org Cc: sm@pwg.org Subject: SM> Updated Process In prep for a discussion during the SM call, tomorrow, I've updated the PWG process document. ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.doc This is a one-time notification to both reflectors. Further on-line discussion of the PWG process with occur ONLY on pwg@pwg.org ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- From hastings at cp10.es.xerox.com Wed Jan 29 17:19:11 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> Strawman for a PWG IEEE-ISTO Template for PWG Proposed Standards Message-ID: In case there is time at the end of the SM telecon tomorrow, Thursday, Jan 30, 1-2 PM EST (10-11 PST) after we discuss the PWG Process, here is a Strawman for a PWG IEEE-ISTO Template for PWG Proposed Standards. This is a one-time notification to both reflectors. Further on-line discussion of the PWG Template with occur ONLY on pwg@pwg.org, NOT on the sm@pwg.org (same as for any other PWG process discussion). Dennis Carney, Ira McDonald, Ron Bergman, and I have been working on an MS-WORD template for PWG IEEE-ISTO standards for use by all the PWG WGs doing IEEE-ISTO standards. Here is version 0.2 as a strawman. ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-lates t.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-lates t.doc ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf Ira and I made some simplifications in it as part of making version 0.2 over the IEEE-ISTO style as documents below in Appendix C which also described why we made each change. Ira and I haven't had a chance to talk to anyone else about many of these simplifications. ISSUE: So an imporant issue is whether these simplifications are OK or do we need to rigorously follow the IEEE-ISTO standard style? The rest of version 0.2 is incorporating the detailed commens that Dennis Carney had made as a result of trying to use a template while he wrote up his "-actuals" IPP specification. There is a companion document: "Tips for Good Technical Writing" which I moved from the Appendix to a separate document available at: ftp://ftp.pwg.org/pub/pwg/general/templates/good-writing-tips-latest.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/good-writing-tips-latest.doc ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf ftp://ftp.pwg.org/pub/pwg/general/templates/pwg-template-for-standards-v02-0 30127.pdf Please send comments. Thanks, Tom Appendix C Differences between this Template and the IEEE-ISTO standard style This Appendix lists the differences between this Template and the IEEE/ISTO standard style and explains why. The IEEE-ISTO standard style is represented in the IEEE/ISTO 5101.1 Media Name Standard. These differences have evolved after experience using the IEEE/ISTO standard style for online viewing and printing with Adobe Acrobat. The differences are (working top to bottom): 1. Merged the redundant second page (which had the Abstract) onto the first page and got rid of the second page. Our understanding is that having two title pages comes from publishing the document in printed form, where the first page is like a cover. Most standards bodies have eliminated the cover so that the Abstract appears on the first page. 2. Added "(PWG)" after "The Printer Working Group" in the title. 3. Removed the redundant indications of whether this version is a Working Draft, a Proposed Standard, a Draft Standard, or a Standard from the Header. Only the title indicates the status. A Working Draft has: "Working Draft for a PWG Proposed Standard". A Proposed Standard after passing WG Last Call will have: "PWG Proposed Standard". A Draft Standard after passing WG Last Call will have: "PWG Draft Standard". A Standard after passing PWG Last Call will have: "PWG Standard" 4. Added the URL for the document on the first page, so that it is easy to find. 5. Added Editor's name(s) to the first page, so that proper credit is given as is common in some standards bodies. 6. Simplified the headers and footers, so that the headers are all the same except for the first page. Keeping the headers and footers simple will reduce errors in producing drafts and allow editor's to focus on content more and format less. 7. The Left side of the Header is blank for Working Drafts, then gets IEEE-ISTO 51nn.n after the Working Draft passes WG Last Call. Thus the editor only changes the Header once, when the specification passes Last Call. 8. In the Header, the Title is centered with most of the fixed parts removed. 9. In the Header, the page number is always on the right. The IEEE-ISTO format did not have the page number on the top at all, which has proved a problem when viewing the specification with Adobe Acrobat, when the user can only see part of the page at one time. Also scrolling upwards and downwards needs the page numbers to be at the top and bottom. 10. The Footer follows the IEEE-ISTO style, except the page number is always centered, instead of alternating left and right. This makes it easier to spot the page number when viewing it on the screen. 11. Page numbers in the Header and Footer, start at 1 with the first page. No Roman numerals are used. This makes it easier to relate pages as numbered by Adobe Acrobat and those printing on each page and in the Table of Contents. Also when printing out selected pages, the page number used by the Printer driver agree with the printed page numbers. 12. Defined the Body Text style to use ragged right, rather than justified, in order to make the document more readable by people when printed or displayed though it may not look as pretty. 13. Added editor names for PWG standards in the References section, as is practice in some standards bodies and most technical publications. 14. Removed the first initials from references and used only family names as is becoming practice to avoid the cultural confusion about whether family names come first or last. Here is the change log: Changes to make version 0.2, January 27, 2003 The following changes were made to create version 0.2, January 27, 2003 after careful review by Dennis Carney and Ira McDonald: 1. Generalized the template so that it can be for any PWG standard, not just IPP. 2. Simplified the template so that as few fields as possible have to be updated as the specification progresses through the process - otherwise everyone does it differently. 3. Follow the IEEE-ISTO style with the exceptions listed in Appendix C derived from experience viewing and printing on-line versions using Adobe Acrobat. 4. Explained the file naming scheme for PWG WGs. 5. Added the requirements for a Logical Diagram and a Configuration Diagrams and showed some IPP examples. 6. Highlighted IPP specific instructions and examples in green, like this, in order to give real examples, but make the Template work for all PWG Working Groups 7. Added RFC 3380, 3381, 3382. 8. Added a number of terms that may be useful to PWG projects other than IPP. 9. Moved the Appendix "Tips for Good Technical Writing" to a separate document available at: ftp://ftp.pwg.org/pub/pwg/general/templates/good-writing-tips-latest.pdf From hastings at cp10.es.xerox.com Thu Jan 30 13:06:49 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: FW: PWG> RE: SM> Updated Process [my comments] Message-ID: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Thursday, January 30, 2003 03:03 To: pwg@pwg.org Subject: PWG> RE: SM> Updated Process [my comments] Harry, Here are my comments: 1. Section 3.3 PWG Proposed Standard and elsewhere: I like your proposed change of terminology from "PWG Working Draft" to "PWG Working Material" for the successive versions of a specification that lead up to a Last Call and a PWG Proposed Standard.. The term "PWG Working Material" can't be confused with the second stage of a PWG standard: a "PWG Draft Standard". I assume that any PWG project that also produces other forms of output in addition to a specification, such as a schema is part of the PWG Proposed Standard, not a separate Standard, right? Also this means that any Schema has to have an accompanying specification. No schemas by themselves. 1a. There are a number of places where the old term "Working Draft" still exists, including Process Summary and Figure in Section 9. All occurrences of "Working Draft" need to be changed to "Working Material". 2. Section 3.5 PWG Staandard and elsewhere: Ira and I would like to propose putting some adjective in front of Standard for the final stage, such as "Final". So instead of having: PWG Proposed Standard PWG Draft Standard PWG Standard, we have: PWG Proposed Standard PWG Draft Standard PWG Final Standard Then the term Standard by itself can be used to discuss any of PWG Proposed Standard, PWG Draft Standard, or PWG Final Standard, rather than being ambiguous as to whether "Standard" means all three or just the last one. 3. Sections 3.3 PWG Proposed Standard, 3.4 PWG Draft Standard, and 3.5 [Final] Standard The comparison with the corresonding IETF standards is very similar as follows: 3.3: PWG Working Material is equivalent to an IETF Internet Draft. A PWG Proposed Standard is equivalent to an IETF Proposed Standard. 3.4: A PWG Draft Standard is equivalent to an IETF Draft Standard. 3.5: A PWG [Final] Standard is equivalent to an IETF Standard. These statements should be made in parallel fashion in sections 3.3, 3.4, and 3.5, preferably in separate paragraphs, so that they aren't mixed in with our descriptions. Or put them together into a separate section, like the deleted section 3.6. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, January 28, 2003 21:09 To: pwg@pwg.org Cc: sm@pwg.org Subject: SM> Updated Process In prep for a discussion during the SM call, tomorrow, I've updated the PWG process document. ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process-030128.doc This is a one-time notification to both reflectors. Further on-line discussion of the PWG process with occur ONLY on pwg@pwg.org ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030130/339d7aef/attachment-0001.html From PZehler at crt.xerox.com Tue Feb 4 07:25:27 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Semantic Model teleconference & PWG Process discussion Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. The teleconference is one hour long. It will be run using both phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is 1) Adjust agenda 2) Overview (and short discussion) of Schema changes to replace union scheme representing type 2&3 keyword enumerations. (See below) 3) Continue PWG process discussion from last week. Updated document will be sent out by Wednesday. (objective: closure) 4) Next steps Pete All, 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 __________________________________________________________ webex info: ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: https://hp.webex.com/join/ Then click New User. ------------------------- MEETING SUMMARY ------------------------- Name: pwg-sm Date: 2/6/2003 Time: 10:00AM, (GMT -08:00) Pacific Time, USA & Canada Meeting Number: 23689380 Meeting Password: tempsm __________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# __________________________________________________________ Schema change Info: Old: New: CompressionWKV KeywordNsExtensionPattern (Note: appinfo may also include namespace: ) Supporting enumeration and pattern: __________________________________________________________ From PZehler at crt.xerox.com Tue Feb 4 14:34:13 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Semantic Model meeting minutes Message-ID: All, The meeting minutes for the Semantic Model meeting are available at: ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Minutes/PWG-SM-030123.pdf An updated Semantic Model and Schema will be posted next week. 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 From dhall at hp.com Thu Feb 6 11:26:25 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:38 2009 Subject: SM> Interface / Document revisioning Working Draft Message-ID: <77261E830267D411BD4D00902740AC250DB4C7A9@xvan01.vcd.hp.com> Hey All.. Attached are the notes from Tuesdays PSI meeting.. I apologize for the late publication, but I've been absolutely swamped since Tuesday! Keep in mind that this is a work in progress... Dave <> -------------- next part -------------- A non-text attachment was scrubbed... Name: Spec Stuff.doc Type: application/msword Size: 47104 bytes Desc: not available Url : http://www.pwg.org/archives/sm/attachments/20030206/fe94638c/SpecStuff-0001.doc From PZehler at crt.xerox.com Tue Feb 11 12:51:29 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. The teleconference is one hour long. Hopefully it will be run using both phone and Webex. Information for the phone is included below. Since the Webex information has been rather fluid lately I hope someone from HP (Bob Taylor?) can provide Webex. The agenda for the Semantic Model teleconference is 1) Adjust agenda 2) Discuss Semantic Model document focusing on recent edits (updated version with revision mark will be sent out tomorrow) 3) Next steps Pete All, 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 __________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# Date: 2/13/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) __________________________________________________________ From PZehler at crt.xerox.com Wed Feb 12 13:07:43 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Latest Semantic Model available Message-ID: All, The latest version of the Semantic Model document is available at . This is version 0.20 of the document and is dated February 13, 2003. This document will be used during this weeks teleconference. As always red-lined versions and .docs are available at the following URLs 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 From dhall at hp.com Wed Feb 12 18:10:07 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:38 2009 Subject: SM> Interface / Document revisioning Working Draft Message-ID: <77261E830267D411BD4D00902740AC250DB4C84C@xvan01.vcd.hp.com> One reason that I can think of is that I think of the version as part of the namespace, and the "foo" to be the interface name. / Hence http://www.pwg.org/ps/2003/02/12/JobControlInterface The flip side of the argument is that the namespace is: http://www.pwg.org/ps, and the interface is JobControlInterface/2003/02/12 Giving us: // I'm not sure what the right answer is.. Dave -----Original Message----- From: TAYLOR,BOB (HP-Vancouver,ex1) Sent: Wednesday, February 12, 2003 1:35 PM To: HALL,DAVID (HP-Vancouver,ex1); 'sm@pwg.org'; 'pwg@pwg.org' Subject: RE: SM> Interface / Document revisioning Working Draft Hi all, One question on this since I missed last week's meeting. When we're actually declaring namespaces, the recommendation appeared to be of the style: http://msdn.microsoft.com/2002/04/foo We are right now doing the following: http://msdn.microsoft.com/foo/2002/04/ I.e., pretty much the same model, but put the version/date after the service declaration rather than in the middle of it. I think this makes more sense - was there a specific reason to put the version/date in the middle instead of on the end? bt > -----Original Message----- > From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] > Sent: Thursday, February 06, 2003 8:26 AM > To: 'sm@pwg.org'; 'pwg@pwg.org' > Subject: SM> Interface / Document revisioning Working Draft > > > Hey All.. > > Attached are the notes from Tuesdays PSI meeting.. I > apologize for the late > publication, but I've been absolutely swamped since Tuesday! > > Keep in mind that this is a work in progress... > > Dave > > <> > From PZehler at crt.xerox.com Thu Feb 20 07:31:31 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> No Semantic Teleconference today Message-ID: All, Without any outstanding SM issues or requests for time, there was no agenda and so, no meeting. 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 From PZehler at crt.xerox.com Fri Feb 21 11:02:22 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Latest PWG Schemas (v0.92) available Message-ID: All, The latest PWG schemas have been updated. See "Semantic Model Schema: Latest Version" under "Documents" on the Semantic Model Web page "http://www.pwg.org/sm/index.html" for links to all the schemas. The schema files are all stored under "http://www.pwg.org/schemas/sm/latest/". The schemas do not have the latest version of "DocumentFormatDetails" or "StatusStrings". Other things not included are "CharacterRepertoireSupported" and the color&imaging extensions. Please forward any comments to me and the Semantic Model mailing list. 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 From PZehler at crt.xerox.com Wed Feb 26 09:29:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> No Semantic Teleconference this week Message-ID: > All, > The latest schema has been published. The Semantic Model is waiting on > the Document Object specification before its final edit prior to the start > of Last Call. If we need to have a teleconference for any reason please > let me know. > 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 > From hastings at cp10.es.xerox.com Fri Mar 14 20:59:37 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions Message-ID: We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From PZehler at crt.xerox.com Mon Mar 17 13:17:21 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> PWG Semantic Model Teleconference Information 3/20 Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference will be dedicated to the Document Object > > The teleconference is one hour long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > > The agenda for the Semantic Model teleconference is : > > 1) Adjust agenda > 2) Walk through Document Object Specification Tom Hastings will send out link to specification under separate cover 3) Check out the latest changes to the Semantic Model Specification We will use the version with revision marks. > ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20030317.pdf ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20030317-rev.pdf > 3) Next Steps > > > Pete > All, > > > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 3/20/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) > ___________________________________________________ > > From dhall at hp.com Mon Mar 17 13:55:23 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:38 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABA1@xvan01.vcd.hp.com> Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From hastings at cp10.es.xerox.com Mon Mar 17 19:12:08 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> IPP Document object specification, March 14 2003 version, is avai lable for SM 3/20 telecon Message-ID: I've stored the 14 March 2003 version of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.doc The rest of the email message contains the 18 issues followed by the change log summary. The 14 March 2003 version contains the agreements reached at the last PWG face to face meeting in Maui and on subsequent SM telecons and email threads. This version also aligns with the 17 March 2003 version of the Semantic Model that Pete just posted. The issues will be reviewed during the PWG Semantic Model telecon, Thursday, March 20. There are 18 issues, mostly minor or just making sure you approve of the specific updates. However, issue #9 is significant. Here are the issues that are also embedded in the document: ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? ISSUE 06: OK that "document-container-summary" is only one level deep? ISSUE 07: Is the description of "document-container-summary" attribute OK? ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. Here is the Change Log: Version 0.7, 14 March 2003, agreements from the Maui January PWG meeting and subsequent telecons: 1. Fixed up the file naming and numbering to agree with the latest PWG process agreements. 2. Updated the Abstract and Introduction to reflect the additions. 3. Fixed cross references to use the standard numbers as agreed, rather than mnemonic references. 4. Deprecated the "input-document-number" operation attribute ([pwg5100.4] section 9.2.1 in the Create-Document Requests 5. Renamed Send-Data to Send-Document-Data to more clearly reflect the scope of the operation. 6. Added the REQUIRED Close-Job operation to close a job that contains Document objects. Using "last-document" still works too and the Printer MUST support both ways. 7. Retained the idea that the Printer MUST NOT copy down any attributes supplied in the Job Creation operation to the Document object as observable in Document object query responses. Document objects inherit that effect from the Job object. 8. Added the following operation and Document Description attributes: document-container-summary (collection), document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127). The "document-container-summary" collection attribute may contain them, plus "document-format" and "document-natural-language". 9. REQUIRED Printers to support "document-format-version" Document Description. 10. Deprecated "document-overrides" and indicated that the agreement is to re-issue [pwg5100.4] without "document-overrides". 11. Prefixed the following three Document Description attributes that are copies of Job Description attributes with "document-" so that no Document attribute has a "job-" prefix: "job-printer-uri" becomes "document-job-printer-uri", "job-uri" becomes "document-job-uri", and "job-id" becomes "document-job-id". 12. Added the encoding for the "document-attributes-tag" as 0x09. 13. Updated the IANA Registration section, but still needs more work. Send any comments to the SM mailing list. Thanks, Tom From PZehler at crt.xerox.com Tue Mar 18 09:51:47 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> My response to some of the 18 Document issues...Comments? Message-ID: All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From PZehler at crt.xerox.com Tue Mar 18 10:30:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:38 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: Dave, I was under the impression that the reason for defining DeviceId was to establish an unambiguous mapping of a Printer and its associated driver. IPP v1.0 and 1.1 used PrinterMakeAndModel. UPnP felt that that mapping was not sufficiently defined and ambiguous. The IEEE P1284 device registry was utilized with the definition of DeviceId. I believe that the DeviceId provides a more direct and convenient mapping to printer's device driver. It also includes the make and model in a well defined format. I recommend that we do not include PrinterMakeAndModel in the list below. 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: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 17, 2003 1:55 PM To: 'Hastings, Tom N' Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From imcdonald at sharplabs.com Tue Mar 18 10:52:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:38 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF39@mailsrvnt02.enet.sharplabs.com> Hi Pete, Agreed - specifically, Bob Taylor (HP strong voice for document details) has urged the use of DeviceID as the unambiguous identifier. Admittedly that's no help to actually find the driver install for human beings, but that's a separate problem, I think. Cheers, - Ira McDonald -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:31 AM To: 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Dave, I was under the impression that the reason for defining DeviceId was to establish an unambiguous mapping of a Printer and its associated driver. IPP v1.0 and 1.1 used PrinterMakeAndModel. UPnP felt that that mapping was not sufficiently defined and ambiguous. The IEEE P1284 device registry was utilized with the definition of DeviceId. I believe that the DeviceId provides a more direct and convenient mapping to printer's device driver. It also includes the make and model in a well defined format. I recommend that we do not include PrinterMakeAndModel in the list below. 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: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 17, 2003 1:55 PM To: 'Hastings, Tom N' Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From AMcCarthy at crt.xerox.com Tue Mar 18 13:09:13 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:38 2009 Subject: SM> My response to some of the 18 Document issues...Comments? Message-ID: All, WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:52 AM To: Hastings, Tom N; sm@pwg.org Subject: SM> My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Tue Mar 18 14:09:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:38 2009 Subject: SM> IPP Document object specification, March 14 2003 version, is avai lable for SM 3/20 telecon [much smaller zips] Message-ID: For some reason the sizes of the clean version of the .PDF file is huge (3 Mb) while the revision marked .pdf was much smaller. And of course the .doc files are always huge. However, zipping all of them separately helped a lot. Those who have to down load over a phone line this savings is significant. So I've down loaded individual .zip files for each of the four flavors: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-pdf.zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-doc.zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev-pdf.zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev-doc.zip .pdf .doc -rev.pdf -rev.doc which are: 1152KB, 290KB, 694KB, and 307KB, respectively, compared to: 2786KB, 1925KB, 865KB, and 2007KB, respectively. ratio: 59%, 85%, 85%, 20%, respectively Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 17, 2003 16:12 To: sm@pwg.org Subject: SM> IPP Document object specification, March 14 2003 version, is available for SM 3/20 telecon I've stored the 14 March 2003 version of the IPP Document object on the PWG server at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-latest.doc which are the same as: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.doc The version with revision marks is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314-rev.doc The rest of the email message contains the 18 issues followed by the change log summary. The 14 March 2003 version contains the agreements reached at the last PWG face to face meeting in Maui and on subsequent SM telecons and email threads. This version also aligns with the 17 March 2003 version of the Semantic Model that Pete just posted. The issues will be reviewed during the PWG Semantic Model telecon, Thursday, March 20. There are 18 issues, mostly minor or just making sure you approve of the specific updates. However, issue #9 is significant. Here are the issues that are also embedded in the document: ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? ISSUE 06: OK that "document-container-summary" is only one level deep? ISSUE 07: Is the description of "document-container-summary" attribute OK? ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. Here is the Change Log: Version 0.7, 14 March 2003, agreements from the Maui January PWG meeting and subsequent telecons: 1. Fixed up the file naming and numbering to agree with the latest PWG process agreements. 2. Updated the Abstract and Introduction to reflect the additions. 3. Fixed cross references to use the standard numbers as agreed, rather than mnemonic references. 4. Deprecated the "input-document-number" operation attribute ([pwg5100.4] section 9.2.1 in the Create-Document Requests 5. Renamed Send-Data to Send-Document-Data to more clearly reflect the scope of the operation. 6. Added the REQUIRED Close-Job operation to close a job that contains Document objects. Using "last-document" still works too and the Printer MUST support both ways. 7. Retained the idea that the Printer MUST NOT copy down any attributes supplied in the Job Creation operation to the Document object as observable in Document object query responses. Document objects inherit that effect from the Job object. 8. Added the following operation and Document Description attributes: document-container-summary (collection), document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127). The "document-container-summary" collection attribute may contain them, plus "document-format" and "document-natural-language". 9. REQUIRED Printers to support "document-format-version" Document Description. 10. Deprecated "document-overrides" and indicated that the agreement is to re-issue [pwg5100.4] without "document-overrides". 11. Prefixed the following three Document Description attributes that are copies of Job Description attributes with "document-" so that no Document attribute has a "job-" prefix: "job-printer-uri" becomes "document-job-printer-uri", "job-uri" becomes "document-job-uri", and "job-id" becomes "document-job-id". 12. Added the encoding for the "document-attributes-tag" as 0x09. 13. Updated the IANA Registration section, but still needs more work. Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Tue Mar 18 14:33:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> RE: My response to some of the 18 Document issues...Comments? [IS SUE 03 "job-mandatory-attributes" = REQUIRED] Message-ID: I agree with Peter's suggested resolutions to ISSUE 03, but need to test our understanding of the terminology, since I think that the spec needs to say that "job-mandatory-attributes" is a REQUIRED attribute in the Document Object spec, not OPTIONAL, in order to agree with Peter's suggestion. Peter wrote: ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. When we say anything is "REQUIRED" in the Document Object spec, we mean it is REQUIRED if the Printer conforms to the Document Object specification, i.e., supports the Document Object. [This semantic for the word REQUIRED is true for any IPP extension specification]. Here is what the Document Object spec says in the Conformance Terminology section to try to make the scope of the term "REQUIRED" clear: 2.1 Conformance Terminology Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance as defined in RFC 2119 [rfc2119] and [rfc2911] section 12.1. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they do not. These terms define conformance to this document (and [rfc2911]) only; they do not affect conformance to other documents, unless explicitly stated otherwise. To be more specific: REQUIRED - an adjective used to indicate that a conforming IPP Printer implementation MUST support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. See [rfc2911] "Appendix A - Terminology for a definition of "support". Since support of this entire Document Object specification is OPTIONAL for conformance to IPP/1.1, the use of the term REQUIRED in this document means "REQUIRED if this OPTIONAL Document Object specification is implemented". RECOMMENDED - an adjective used to indicate that a conforming IPP Printer implementation is recommended to support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. Since support of this entire Document Object specification is OPTIONAL for conformance to IPP/1.1, the use of the term RECOMMENDED in this document means "RECOMMENDED if this OPTIONAL Document Object specification is implemented". OPTIONAL - an adjective used to indicate that a conforming IPP Printer implementation MAY, but is NOT REQUIRED to, support the indicated operation, object, attribute, attribute value, status code, or out-of-band value in requests and responses. It has been suggested (and I put in the proposed PWG Template) that it is not good to repeat the definitions of terms that appear in other specifications, since the definition may inadvertantly be changed. Also we don't need to use the term "NEED NOT" which [rfc2911] introduces and explains in section 12.1. So I'll recast the 5 uses of NEED NOT to be MAY in the next version. So how about this much shorter explanation for the Document Object section 2.1 Conformance Terminology: Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, and OPTIONAL, have special meaning relating to conformance as defined in RFC 2119 [rfc2119]. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they do not. These terms define conformance to this document (and [rfc2911]) only; they do not affect conformance to other documents, unless explicitly stated otherwise. For example, the term REQUIRED in this document means "REQUIRED if this OPTIONAL Document Object specification is implemented". Comments? Tom -----Original Message----- From: Zehler, Peter Sent: Tuesday, March 18, 2003 06:52 To: Hastings, Tom N; sm@pwg.org Subject: My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Tue Mar 18 14:58:14 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Message-ID: Here is the definition of the "document-format-device-id" proposed in the Document object spec: This OPTIONAL Document Description attribute identifies the type of device for which the document was formatted, including manufacturer and model. This attribute is intended to identify document formats that are not portable, e.g., PDLs that are device dependent. The value of this variable MUST exactly match the IEEE 1284-2000 Device ID string (see [IEEE1284] clause 6), except the length field MUST not be specified. See the Microsoft Universal Plug and Play [upnp] section 2.2.6 DeviceId parameter for details and examples. Here is an example showing only the required fields for a PostScript document: MANUFACTURER:ACME Co.;COMMAND SET:PS;MODEL:LaserBeam 9; And here is the definition of the UPnP DeviceId attribute from the UPnP v1 Printer Template. Note: in UPnP this is a Printer attribute, not an attribute that the submitter includes with his job submission: 2.6.6 DeviceId The value of this variable MUST exactly match the IEEE 1284-2000 Device ID string, except the length field MUST not be specified.. The value is assigned by the Printer vendor and MUST NOT be localized by the Print Service. The IEEE 1284-2000 Device ID is a length field followed by a case-sensitive string of ASCII characters defining peripheral characteristics and/or capabilities. For the purposes of this specification, the length bytes MUST NOT be included. The Device ID sequence is composed of a series of keys and values of the form: key: value {,value} repeated for each key As indicated, each key will have one value, and MAY have more than one value. The minimum necessary keys (case-sensitive) are MANUFACTURER, COMMAND SET, and MODEL. (These keys MAY be abbreviated as MFG, CMD, and MDL respectively.) Each implementation MUST supply these three keys and possibly additional ones as well. Each key (and each value) is a string of characters. Any characters except colon (:), comma (,), and semi-colon (;) MAY be included as part of the key (or value) string. Any leading or trailing white space (SPACE[x'20'], TAB[x'09'], VTAB[x'0B'], CR[x'0D'], NL[x'0A'], or FF[x'0C']) in the string is ignored by the parsing program (but is still counted as part of the overall length of the sequence). An example ID String, showing optional comment and active command set keys and their associated values (the text is actually all on one line): MANUFACTURER:ACME Manufacturing; COMMAND SET:PCL,PJL,PS,XHTML-Print+xml; MODEL:LaserBeam 9; COMMENT:Anything you like; ACTIVE COMMAND SET:PCL; (See IEEE 1284-2000 clause 7.6) Note: One of the purposes of the DeviceId variable is to select a printer driver for those UCPs that need a printer driver. The values of the COMMAND SET key are interpreted by the printer driver provided by the vendor and so are vendor-defined, rather than being standardized. TH Observations: 1. The Note is part of the definition of the UPnP DeviceId Printer attribute showing the intent to relate to the driver needed. 2. Because the keyword fields also have shorter forms, the string: MFG:ACME Manufacturing;CMD:PCL,PJL,PS,XHTML-Print+xml;MDL:LaserBeam 9; is also conforming for the UPnP DeviceId Printer Attribute. 3. This alternate form for the keyword fields means that the Printer will either have to include both forms in its "document-format-device-id-supported" Printer attribute (if we decide to have one) or have a more sophisticated matching algorithm. 4. The UPnP DeviceId attribute is a Printer Attribute that describes the Printer's capabilities. Unlike the IPP "document-format-device-id", the UPnP DeviceId attribute is not submitted by the clent to tell the printer what the document format is that the client is submitting. 5. For our use as an attribute that the client submits as a value of "document-format-device-id", presumably there would only be one value of the COMMAND SET, e.g.,: MFG:ACME Manufacturing;CMD:PS;MDL:LaserBeam 9; Right? Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, March 18, 2003 07:53 To: 'Zehler, Peter'; 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Hi Pete, Agreed - specifically, Bob Taylor (HP strong voice for document details) has urged the use of DeviceID as the unambiguous identifier. Admittedly that's no help to actually find the driver install for human beings, but that's a separate problem, I think. Cheers, - Ira McDonald -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:31 AM To: 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Dave, I was under the impression that the reason for defining DeviceId was to establish an unambiguous mapping of a Printer and its associated driver. IPP v1.0 and 1.1 used PrinterMakeAndModel. UPnP felt that that mapping was not sufficiently defined and ambiguous. The IEEE P1284 device registry was utilized with the definition of DeviceId. I believe that the DeviceId provides a more direct and convenient mapping to printer's device driver. It also includes the make and model in a well defined format. I recommend that we do not include PrinterMakeAndModel in the list below. 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: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com] Sent: Monday, March 17, 2003 1:55 PM To: 'Hastings, Tom N' Cc: sm@pwg.org Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions Having just implemented an initial PSI TargetDeviceSupportInterface, another IPP attribute appears to be very important: PrinterMakeAndModel While the DeviceID can be utilized to indirectly determine the appropriate device data format, it is much more convient to utilize the printer make and model, if it corresponds to the Printer Driver Name. I would like to recommend that we consider this attribute for inclusion in the below list.. Dave -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 14, 2003 6:00 PM To: CIP4 Capabilities WG [capabilities@cip4.org] Cc: sm@pwg.org Subject: SM> Summary of additions to JDF/FileSpec and IPP Document object for document format versions We've had a long thread of discussion about the need to indicate the version of a document format in a job submission along with its MIME type in JDF and IPP. In JDF this infomation is represented as attributes in the FileSpec resource. In IPP, the PWG Semantic Model (SM) and the Print Service Interface (PSI), the document format and versions are represented as Document Description attributes. In IPP the client submits these as operation attributes which the Printer copies to the corresponding Document Description attributes. Here is a quick summary to see if we are in agreement: 1. Don't add stuff to the IPP Document object that hasn't been asked for, even though its being added to JDF FileSpec resource. So IPP will remain a subset of JDF. So while adding TransferEncoding (per Israel Viente's request), DocumentClass (to help distinguish fonts from other files), and some attribute for use with fonts to designate which organization they are coming from (which need work) so we don't need MIME types for fonts. 2. The following list show the relationship between IPP Document object and the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and FileFormatVersion are new. All of the IPP Document attributes are new except for document-format and document-natural-language: document-container-summary (collection) ContainerSummary which can contain: document-creator-application-name (name(MAX)) document-creator-application-version (name(MAX)) document-creator-os-name (name(MAX)) document-creator-os-version (name(MAX)) document-format (mimeMediaType) document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) document-creator-application-name (name(MAX)) Application document-creator-application-version (name(MAX)) AppVersion document-creator-os-name (name(40)) AppOS document-creator-os-version (name(40)) OSVersion document-format (mimeMediaType) MimeType document-format-detected (mimeMediaType) N/A document-format-device-id (text(127)) IEEE1284DeviceId document-format-version (text(127) FileFormatVersion document-natural-language (naturalLanguage) I'll have an updated spec for IPP Document object out by Monday AM and a corresponding FileSpec on Monday. I won't be addressing additional MIME types in these documents. That is separate. Tom From hastings at cp10.es.xerox.com Tue Mar 18 21:31:32 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> JDF FileSpec/@FileFormatVersion and IPP "document-format-version" for PDF/X and TIFF/IT Message-ID: I did a google search to find out what the ISO designation is for the PDF/X-1 and TIFF/IT ISO standards. We're trying to define which values should be used for JDF FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that we've collapsed FileFormatStandard into FileFormatVersion as suggested. Same question for IPP "document-format" (mimeMediaType) and "document-format-version" (text(127)) attributes, assuming that we've collapsed "document-format-standard" into "document-format-version" (text(127)) as suggested. This is what I found from google: 1. PDF/X: ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) So this sounds great to use the value of "ISO 15930-1:2001" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec instead of "PDF/X-1:2001". And the MimeType attribute value will be "application/pdf". ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish them in either the MimeType or FileFormatVersion attribute? 2. TIFF/IT: ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag image file format for image technology (TIFF/IT). So use the value "ISO 12639-1998" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec Since TIFF/IT doesn't yet have a MIME type registered, the JDF FileSpec/@MimeType attribute will be omitted and the IPP "document-format" attribute will be omitted, OK? Tom -----Original Message----- From: McCarthy, Ann L Sent: Tuesday, March 18, 2003 10:09 To: Zehler, Peter; Hastings, Tom N; sm@pwg.org Subject: RE: SM> My response to some of the 18 Document issues...Comments? All, WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:52 AM To: Hastings, Tom N; sm@pwg.org Subject: SM> My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From AMcCarthy at crt.xerox.com Wed Mar 19 10:19:10 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:39 2009 Subject: SM> RE: JDF FileSpec/@FileFormatVersion and IPP "document-format-vers ion" for PDF/X and TIFF/IT Message-ID: Tom, I am rethinking the recommendation to use the ISO standard name. When we established that idea originally we were dealing with media standards. Media measurement standards and other physical system standards can be designated by the ISO or other selected standard name. I now realize that file formats need to be treated differently. In the file format case - each file format standard itself specifies a conformance string value that must be used in the file to identify the specific standard to which the file conforms. JDF should use those same conformance identifier strings. So for PDF/X the conformance values are: PDF/X-1:2001 PDF/X-1a:2001 PDF/X-2:2001 PDF/X-3:2001 One of these string values will appear in the PDF/X key "GTS_PDFXVersion" (with the exception of PDF/X-1a:2001). If the PDF/X file is X-1a conforming then 'PDF/X-1:2001' will appear in the "GTS_PDFXVersion" key and the 'PDF/X-1a:2001' string will appear in the additional key "GTS_PDFXConformance". So X-1a pdf files are identified by a combination of these two keys within the pdf file. JDF should be able to use a single string. TIFF/IT files also have several possible conformance levels. TIFF/IT conformance strings (given in section 5 of ISO 12639) are: TIFF/IT TIFF/IT-CT TIFF/IT-LW TIFF/IT-HC TIFF/IT-MP TIFF/IT-BP TIFF/IT-BL TIFF/IT-P1 TIFF/IT-CT/P1 TIFF/IT-LW/P1 TIFF/IT-HC/P1 TIFF/IT-MP/P1 TIFF/IT-BP/P1 TIFF/IT-BL/P1 Each of these informs the reader of specific constraints or file interpretation requirements. We may be able to reduce the list of TIFF/IT strings if someone more familiar with the exchange of TIFF/IT can identify a case that never occurs. Absent that - JDF should duplicate the conformance level identifiers given in the ISO 12639 standard. My apologies for the back-and-forth on this. After looking at the file format standards I think that one consistent way of specifying all standards is less important than adhering to previously defined conformance identification methods when they are available. Best regards, Ann -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Hastings, Tom N Sent: Tuesday, March 18, 2003 9:32 PM To: McCarthy, Ann L; sm@pwg.org Cc: CIP4 Capabilities WG [capabilities@cip4.org]; Masinter, Larry at Adobe Subject: JDF FileSpec/@FileFormatVersion and IPP "document-format-version" for PDF/X and TIFF/IT I did a google search to find out what the ISO designation is for the PDF/X-1 and TIFF/IT ISO standards. We're trying to define which values should be used for JDF FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that we've collapsed FileFormatStandard into FileFormatVersion as suggested. Same question for IPP "document-format" (mimeMediaType) and "document-format-version" (text(127)) attributes, assuming that we've collapsed "document-format-standard" into "document-format-version" (text(127)) as suggested. This is what I found from google: 1. PDF/X: ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) So this sounds great to use the value of "ISO 15930-1:2001" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec instead of "PDF/X-1:2001". And the MimeType attribute value will be "application/pdf". ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish them in either the MimeType or FileFormatVersion attribute? 2. TIFF/IT: ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag image file format for image technology (TIFF/IT). So use the value "ISO 12639-1998" for the value of: FileSpec/@FileFormatVersion attribute in JDF "document-format-version" attribute in the IPP Document object spec Since TIFF/IT doesn't yet have a MIME type registered, the JDF FileSpec/@MimeType attribute will be omitted and the IPP "document-format" attribute will be omitted, OK? Tom -----Original Message----- From: McCarthy, Ann L Sent: Tuesday, March 18, 2003 10:09 To: Zehler, Peter; Hastings, Tom N; sm@pwg.org Subject: RE: SM> My response to some of the 18 Document issues...Comments? All, WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, March 18, 2003 9:52 AM To: Hastings, Tom N; sm@pwg.org Subject: SM> My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Thu Mar 20 10:35:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> RE: JDF FileSpec/@FileFormatVersionand IPP "document-format-versi on"for PDF/X and TIFF/IT Message-ID: Here are some really good comments from Martin Bailey about a number of recent emails about the FileSpec proposal for JDF from Ann McCarthy, Bob Taylor, and myself. Martin, One thing I left out of the proposal by mistake was how to indicate which types of fonts: "Type 1" "TrueType" "OpenType" ... I think we should just add another attribut to FileSpec, say, FontType (string) that has meaning when FileClass = Font. I like yours and Ann's suggestion not to use the ISO standard designation ("ISO nnnn-part:year") when the ISO standard has a versioning mechanism specified as part of it, as does TIFF/IT and PDF/X (see below). Also I forgot to include DCS (Desktop Color Separation version 2). It doesn't have an ISO standard, right? Tom -----Original Message----- From: Martin Bailey [mailto:Martin.Bailey@globalgraphics.com] Sent: Thursday, March 20, 2003 03:03 To: hastings@cp10.es.xerox.com Subject: CIP4 Forum Capabilities: Re:JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Hi Tom Responses in-line. At 02:37 19/03/2003, Tom Hastings wrote: >I did a google search to find out what the ISO designation is for the >PDF/X-1 and TIFF/IT ISO standards. > >We're trying to define which values should be used for JDF >FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that >we've collapsed FileFormatStandard into FileFormatVersion as suggested. > >Same question for IPP "document-format" (mimeMediaType) and >"document-format-version" (text(127)) attributes, assuming that we've >collapsed "document-format-standard" into "document-format-version" >(text(127)) as suggested. > > >This is what I found from google: > >1. PDF/X: > >ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use >of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) > >So this sounds great to use the value of "ISO 15930-1:2001" for the value >of: > > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >instead of "PDF/X-1:2001". And the MimeType attribute value will be >"application/pdf". > >ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish >them in either the MimeType or FileFormatVersion attribute? I would go back to the suggestion that I originally made, which matches the strings that are used inside the file to uniquely identify the conformance level: "PDF/X-1a:2001", "PDF/X-3:2002", etc. At 19:02 19/03/2003, Tom Hastings wrote: >1. Should we also list in JDF the "PDF/X-1:1999" value as well? Its mention >in the 2001 ISO standard as an "older version". Given that the list we will include in the standard is, almost by definition, incomplete, no - I would not include that. It's an obsolete file format, defined in a standard that has been withdrawn. If somebody really wants to include it they could figure out from the other values in the list what the right string should be. >2. TIFF/IT: > >ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag >image file format for image technology (TIFF/IT). > >So use the value "ISO 12639-1998" for the value of: That would be "ISO 12639:1998", colon rather than hyphen. > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >Since TIFF/IT doesn't yet have a MIME type registered, the JDF >FileSpec/@MimeType attribute will be omitted and the IPP "document-format" >attribute will be omitted, OK? OK, but how do you plan to distinguish between the sub-file types (FP, CT, LW, HC) and between baseline TIFF/IT and TIFF/IT-P1? Those are important questions when it comes to capabilities reporting because many tools will only read P1, and not baseline, and many can't read all of the sub-file types. I made some suggestions for those in my original mail. At 15:27 19/03/2003, Ann McCarthy wrote: >TIFF/IT files also have several possible conformance levels. >TIFF/IT conformance strings (given in section 5 of ISO 12639) >are: >TIFF/IT >TIFF/IT-CT >TIFF/IT-LW >TIFF/IT-HC >TIFF/IT-MP >TIFF/IT-BP >TIFF/IT-BL >TIFF/IT-P1 >TIFF/IT-CT/P1 >TIFF/IT-LW/P1 >TIFF/IT-HC/P1 >TIFF/IT-MP/P1 >TIFF/IT-BP/P1 >TIFF/IT-BL/P1 > >Each of these informs the reader of specific constraints or file >interpretation requirements. > >We may be able to reduce the list of TIFF/IT strings if someone >more familiar with the exchange of TIFF/IT can identify a case >that never occurs. Absent that - JDF should duplicate the >conformance level identifiers given in the ISO 12639 standard. Ann's suggested list is almost what we need: - I'm not sure what "TIFF/IT" on its own means in that context - did you mean 'FP'? I know FP isn't normative in the 1998 standard (it is in the 2003 revision), but that doesn't stop people using it :-) - there's a 2003 revision of 12639 in ballot at the moment, so we need a date suffix on all of the above. In theory the P1 subset has not been changed in that revision (we tried not leave it unchanged, anyway), but I'd feel safer with a date suffix still, although that might complicate capabilities reporting somewhat. The revision also adds a new file subtype (SD), and a new conformance level (P2). The full list therefore gets a bit long: TIFF/IT-FP:1998 TIFF/IT-CT:1998 TIFF/IT-LW:1998 TIFF/IT-HC:1998 TIFF/IT-MP:1998 TIFF/IT-BP:1998 TIFF/IT-BL:1998 TIFF/IT-FP/P1:1998 TIFF/IT-CT/P1:1998 TIFF/IT-LW/P1:1998 TIFF/IT-HC/P1:1998 TIFF/IT-MP/P1:1998 TIFF/IT-BP/P1:1998 TIFF/IT-BL/P1:1998 TIFF/IT-FP:2003 TIFF/IT-CT:2003 TIFF/IT-LW:2003 TIFF/IT-HC:2003 TIFF/IT-MP:2003 TIFF/IT-BP:2003 TIFF/IT-BL:2003 TIFF/IT-SD:2003 TIFF/IT-FP/P1:2003 TIFF/IT-CT/P1:2003 TIFF/IT-LW/P1:2003 TIFF/IT-HC/P1:2003 TIFF/IT-MP/P1:2003 TIFF/IT-BP/P1:2003 TIFF/IT-BL/P1:2003 (no P1 conformance level of SD) TIFF/IT-FP/P2:2003 TIFF/IT-CT/P2:2003 TIFF/IT-LW/P2:2003 TIFF/IT-HC/P2:2003 TIFF/IT-MP/P2:2003 TIFF/IT-BP/P2:2003 TIFF/IT-BL/P2:2003 TIFF/IT-SD/P2:2003 But, as I commented above, the list in the spec can only be regarded as incomplete, so it might be better to explicitly make it a set of examples and include only some of these? At 07:32 19/03/2003, Bob Taylor wrote: > >I would think we'd just use the TIFF MIME type for these (application/TIFF >?). > No, because most TIFF/IT subfile types are not valid TIFF. Martin >Tom > > > >-----Original Message----- >From: McCarthy, Ann L >Sent: Tuesday, March 18, 2003 10:09 >To: Zehler, Peter; Hastings, Tom N; sm@pwg.org >Subject: RE: SM> My response to some of the 18 Document >issues...Comments? > > >All, > >WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. > >-------------------------------------------------------------------- >Ann L. McCarthy >XIG/SSTC Imaging Systems Architect >Internal:8*221-8701 External: 585-231-8701 >FAX: 585-265-8871 Mailcode: B128-30E > > >-----Original Message----- >From: Zehler, Peter [mailto:PZehler@crt.xerox.com] >Sent: Tuesday, March 18, 2003 9:52 AM >To: Hastings, Tom N; sm@pwg.org >Subject: SM> My response to some of the 18 Document issues...Comments? > >All, > >I saw many of the issues as "low hanging fruit". I have my responses to >issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on >and issues 14 to 17 are basically work to be done. This leaves issues 9 and >11. These involve how to represent the supported values for the document >format detail attributes. I think we will need to dedicate a large chunk of >time for this issue in Thursday's teleconference. > >Are there any comments on these issues or my responses? > >Pete > >ISSUE 00: Or should we just delete "input-document-number" operation >attribute when we republish pwg5100.4 without "document-overrides? >Delete "input-document-number". Document numbers start at 1 and >monotonically increment as documents are added to the Job. > >ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the >object on which it operates? >No, keep it Send-Data. I see no reason for the longer name. The only >data we send is associated with a Document. We don't have >CreateJob-Document >or Create-Printer-Job. > >ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support >it, since PSI is using it? >Yes > >ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute >for a Printer to support (if it supports the Document object)? Otherwise, >clients won't support it and will be stuck with the "ipp-attribute-fidelity" >attribute? >It should be an OPTIONAL Operation Attribute that a Printer MUST support >if the Printer supports the Document Object. > >ISSUE 04: The "document-overrides" attribute is also useful in combination >with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the >Input Page stream concatenated across the Input Documents into separate >Output Documents. For example, making every 10 Input Pages be a separate >Output Document but the client only wants to staple the first Output >Document. ISSUE 04: But what about Subset Finishing? Can we it be done >without "document-overrides"? >Get rid of "document-overrides" in favor of the Document. Place the >burden of the example corner case on the Client. The results can be easily >achieved through the use of Documents and page-overrides. > >ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE >the Printer to continue to support the "page-overrides" as an operation >attribute in Send-Document and Send-URI as well as a Document Template >attribute? >Yes > >ISSUE 06: OK that "document-container-summary" is only one level deep? >Yes, this information is not a manifest of the contained documents. >It is used to determine if a Printer can process the Document. Clients >are free to send individual compressed Documents if a manifest of a Job's >contents is required. > >ISSUE 07: Is the description of "document-container-summary" attribute OK? >Clarify that a manifest can be accomplished by the Client sending >individually compressed Documents. > >ISSUE 08: Are the conformance requirements for the >"document-container-summary" attributes OK? >No opinion > >ISSUE: 09: How can a Printer indicate which combinations of >document-creator-application-name (name(MAX)), >document-creator-application-version (text(127)), document-creator-os-name >(name(40)), document-creator-os-version (text(40)), >document-format-device-id (text(127)), document-format-version (text(127), >document-format (mimeMediaType) and "document-natural-language >(naturalLanguage) are supported? > >ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to >support? >Yes > >ISSUE: 11: The problem with separating "document-format" and >"document-format-version" is how can a Printer describe what versions are >supported, since the versions have to be associated with the document >format. > >ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. >ISSUE 12: Or should the official ISO standard number, part number and date, >be used instead, e.g., "ISO nnnnn.n-2001"? >No opinion > >ISSUE 13: The definition of "document-natural-language" in [rfc2911] >?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document >Description attribute isn't 1setOf? Or should we extend >"document-natural-language" to 1setOf naturalLanguage) and keep the same >name? Or change the name to "document-natural-languages"? >Keep single-valued. It will handle the vast majority of cases and >keep things simple > >ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table >14 that go with the Document Template attributes. >OK > >ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Document Template attributes. >OK > >ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Job Template attributes being defined. >OK > >ISSUE 17: TBD - Need to list the keyword attribute values in the IANA >Registration section. Do so by reference to the values registered for >corresponding attributes. >OK > >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 > > > >ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf > >Send any comments to the SM mailing list. > >Thanks, >Tom > > >----- >This message was submitted by Tom Hastings (Xerox) >Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5383 >Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 ----- This message was submitted by Martin Bailey (Global Graphics Software) Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5407 Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 From hastings at cp10.es.xerox.com Thu Mar 20 10:51:21 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> FW: JDF FileSpec/@FileFormatVersionand IPP "document-format-versi on"for PDF/X and TIFF/IT Message-ID: For the PWG Semantic telecon today (10:00 AM PST, 1:00 PM EST): For PWG Semantic folks who want to understand the parallel semantics being developed for JDF, here is the proposed additions to the JDF FileSpec resource and a direct comparison with the IPP Document Object attributes that we are reviewing today at the SM call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030318-rev. pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030318-rev. doc.zip I also suspect that the details of which values for non-MIME type documents are not going to be so interesting to IPP/SM/PSI. Tom P.S. The JDF Capabilities WG will be reviewing the FileSpec proposal at a CIP4 telecon that starts in 10 minutes (8:00 AM PST, 11:00 AM EST). Bob Taylor and I will bring any late developing ideas to the SM telecon today if it might affect what we want to do in the IPP Document Object spec. -----Original Message----- From: Hastings, Tom N Sent: Thursday, March 20, 2003 07:36 To: 'capabilities@cip4.org' Cc: 'sm@pwg.org'; 'Masinter, Larry at Adobe' Subject: RE: JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Here are some really good comments from Martin Bailey about a number of recent emails about the FileSpec proposal for JDF from Ann McCarthy, Bob Taylor, and myself. Martin, One thing I left out of the proposal by mistake was how to indicate which types of fonts: "Type 1" "TrueType" "OpenType" ... I think we should just add another attribut to FileSpec, say, FontType (string) that has meaning when FileClass = Font. I like yours and Ann's suggestion not to use the ISO standard designation ("ISO nnnn-part:year") when the ISO standard has a versioning mechanism specified as part of it, as does TIFF/IT and PDF/X (see below). Also I forgot to include DCS (Desktop Color Separation version 2). It doesn't have an ISO standard, right? Tom -----Original Message----- From: Martin Bailey [mailto:Martin.Bailey@globalgraphics.com] Sent: Thursday, March 20, 2003 03:03 To: hastings@cp10.es.xerox.com Subject: CIP4 Forum Capabilities: Re:JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Hi Tom Responses in-line. At 02:37 19/03/2003, Tom Hastings wrote: >I did a google search to find out what the ISO designation is for the >PDF/X-1 and TIFF/IT ISO standards. > >We're trying to define which values should be used for JDF >FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that >we've collapsed FileFormatStandard into FileFormatVersion as suggested. > >Same question for IPP "document-format" (mimeMediaType) and >"document-format-version" (text(127)) attributes, assuming that we've >collapsed "document-format-standard" into "document-format-version" >(text(127)) as suggested. > > >This is what I found from google: > >1. PDF/X: > >ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use >of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a) > >So this sounds great to use the value of "ISO 15930-1:2001" for the value >of: > > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >instead of "PDF/X-1:2001". And the MimeType attribute value will be >"application/pdf". > >ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish >them in either the MimeType or FileFormatVersion attribute? I would go back to the suggestion that I originally made, which matches the strings that are used inside the file to uniquely identify the conformance level: "PDF/X-1a:2001", "PDF/X-3:2002", etc. At 19:02 19/03/2003, Tom Hastings wrote: >1. Should we also list in JDF the "PDF/X-1:1999" value as well? Its mention >in the 2001 ISO standard as an "older version". Given that the list we will include in the standard is, almost by definition, incomplete, no - I would not include that. It's an obsolete file format, defined in a standard that has been withdrawn. If somebody really wants to include it they could figure out from the other values in the list what the right string should be. >2. TIFF/IT: > >ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag >image file format for image technology (TIFF/IT). > >So use the value "ISO 12639-1998" for the value of: That would be "ISO 12639:1998", colon rather than hyphen. > FileSpec/@FileFormatVersion attribute in JDF > > "document-format-version" attribute in the IPP Document object spec > >Since TIFF/IT doesn't yet have a MIME type registered, the JDF >FileSpec/@MimeType attribute will be omitted and the IPP "document-format" >attribute will be omitted, OK? OK, but how do you plan to distinguish between the sub-file types (FP, CT, LW, HC) and between baseline TIFF/IT and TIFF/IT-P1? Those are important questions when it comes to capabilities reporting because many tools will only read P1, and not baseline, and many can't read all of the sub-file types. I made some suggestions for those in my original mail. At 15:27 19/03/2003, Ann McCarthy wrote: >TIFF/IT files also have several possible conformance levels. >TIFF/IT conformance strings (given in section 5 of ISO 12639) >are: >TIFF/IT >TIFF/IT-CT >TIFF/IT-LW >TIFF/IT-HC >TIFF/IT-MP >TIFF/IT-BP >TIFF/IT-BL >TIFF/IT-P1 >TIFF/IT-CT/P1 >TIFF/IT-LW/P1 >TIFF/IT-HC/P1 >TIFF/IT-MP/P1 >TIFF/IT-BP/P1 >TIFF/IT-BL/P1 > >Each of these informs the reader of specific constraints or file >interpretation requirements. > >We may be able to reduce the list of TIFF/IT strings if someone >more familiar with the exchange of TIFF/IT can identify a case >that never occurs. Absent that - JDF should duplicate the >conformance level identifiers given in the ISO 12639 standard. Ann's suggested list is almost what we need: - I'm not sure what "TIFF/IT" on its own means in that context - did you mean 'FP'? I know FP isn't normative in the 1998 standard (it is in the 2003 revision), but that doesn't stop people using it :-) - there's a 2003 revision of 12639 in ballot at the moment, so we need a date suffix on all of the above. In theory the P1 subset has not been changed in that revision (we tried not leave it unchanged, anyway), but I'd feel safer with a date suffix still, although that might complicate capabilities reporting somewhat. The revision also adds a new file subtype (SD), and a new conformance level (P2). The full list therefore gets a bit long: TIFF/IT-FP:1998 TIFF/IT-CT:1998 TIFF/IT-LW:1998 TIFF/IT-HC:1998 TIFF/IT-MP:1998 TIFF/IT-BP:1998 TIFF/IT-BL:1998 TIFF/IT-FP/P1:1998 TIFF/IT-CT/P1:1998 TIFF/IT-LW/P1:1998 TIFF/IT-HC/P1:1998 TIFF/IT-MP/P1:1998 TIFF/IT-BP/P1:1998 TIFF/IT-BL/P1:1998 TIFF/IT-FP:2003 TIFF/IT-CT:2003 TIFF/IT-LW:2003 TIFF/IT-HC:2003 TIFF/IT-MP:2003 TIFF/IT-BP:2003 TIFF/IT-BL:2003 TIFF/IT-SD:2003 TIFF/IT-FP/P1:2003 TIFF/IT-CT/P1:2003 TIFF/IT-LW/P1:2003 TIFF/IT-HC/P1:2003 TIFF/IT-MP/P1:2003 TIFF/IT-BP/P1:2003 TIFF/IT-BL/P1:2003 (no P1 conformance level of SD) TIFF/IT-FP/P2:2003 TIFF/IT-CT/P2:2003 TIFF/IT-LW/P2:2003 TIFF/IT-HC/P2:2003 TIFF/IT-MP/P2:2003 TIFF/IT-BP/P2:2003 TIFF/IT-BL/P2:2003 TIFF/IT-SD/P2:2003 But, as I commented above, the list in the spec can only be regarded as incomplete, so it might be better to explicitly make it a set of examples and include only some of these? At 07:32 19/03/2003, Bob Taylor wrote: > >I would think we'd just use the TIFF MIME type for these (application/TIFF >?). > No, because most TIFF/IT subfile types are not valid TIFF. Martin >Tom > > > >-----Original Message----- >From: McCarthy, Ann L >Sent: Tuesday, March 18, 2003 10:09 >To: Zehler, Peter; Hastings, Tom N; sm@pwg.org >Subject: RE: SM> My response to some of the 18 Document >issues...Comments? > > >All, > >WRT 12: recommend "ISO nnnnn.n-2001" as in JDF. > >-------------------------------------------------------------------- >Ann L. McCarthy >XIG/SSTC Imaging Systems Architect >Internal:8*221-8701 External: 585-231-8701 >FAX: 585-265-8871 Mailcode: B128-30E > > >-----Original Message----- >From: Zehler, Peter [mailto:PZehler@crt.xerox.com] >Sent: Tuesday, March 18, 2003 9:52 AM >To: Hastings, Tom N; sm@pwg.org >Subject: SM> My response to some of the 18 Document issues...Comments? > >All, > >I saw many of the issues as "low hanging fruit". I have my responses to >issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on >and issues 14 to 17 are basically work to be done. This leaves issues 9 and >11. These involve how to represent the supported values for the document >format detail attributes. I think we will need to dedicate a large chunk of >time for this issue in Thursday's teleconference. > >Are there any comments on these issues or my responses? > >Pete > >ISSUE 00: Or should we just delete "input-document-number" operation >attribute when we republish pwg5100.4 without "document-overrides? >Delete "input-document-number". Document numbers start at 1 and >monotonically increment as documents are added to the Job. > >ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the >object on which it operates? >No, keep it Send-Data. I see no reason for the longer name. The only >data we send is associated with a Document. We don't have >CreateJob-Document >or Create-Printer-Job. > >ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support >it, since PSI is using it? >Yes > >ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute >for a Printer to support (if it supports the Document object)? Otherwise, >clients won't support it and will be stuck with the "ipp-attribute-fidelity" >attribute? >It should be an OPTIONAL Operation Attribute that a Printer MUST support >if the Printer supports the Document Object. > >ISSUE 04: The "document-overrides" attribute is also useful in combination >with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the >Input Page stream concatenated across the Input Documents into separate >Output Documents. For example, making every 10 Input Pages be a separate >Output Document but the client only wants to staple the first Output >Document. ISSUE 04: But what about Subset Finishing? Can we it be done >without "document-overrides"? >Get rid of "document-overrides" in favor of the Document. Place the >burden of the example corner case on the Client. The results can be easily >achieved through the use of Documents and page-overrides. > >ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE >the Printer to continue to support the "page-overrides" as an operation >attribute in Send-Document and Send-URI as well as a Document Template >attribute? >Yes > >ISSUE 06: OK that "document-container-summary" is only one level deep? >Yes, this information is not a manifest of the contained documents. >It is used to determine if a Printer can process the Document. Clients >are free to send individual compressed Documents if a manifest of a Job's >contents is required. > >ISSUE 07: Is the description of "document-container-summary" attribute OK? >Clarify that a manifest can be accomplished by the Client sending >individually compressed Documents. > >ISSUE 08: Are the conformance requirements for the >"document-container-summary" attributes OK? >No opinion > >ISSUE: 09: How can a Printer indicate which combinations of >document-creator-application-name (name(MAX)), >document-creator-application-version (text(127)), document-creator-os-name >(name(40)), document-creator-os-version (text(40)), >document-format-device-id (text(127)), document-format-version (text(127), >document-format (mimeMediaType) and "document-natural-language >(naturalLanguage) are supported? > >ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to >support? >Yes > >ISSUE: 11: The problem with separating "document-format" and >"document-format-version" is how can a Printer describe what versions are >supported, since the versions have to be associated with the document >format. > >ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. >ISSUE 12: Or should the official ISO standard number, part number and date, >be used instead, e.g., "ISO nnnnn.n-2001"? >No opinion > >ISSUE 13: The definition of "document-natural-language" in [rfc2911] >?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document >Description attribute isn't 1setOf? Or should we extend >"document-natural-language" to 1setOf naturalLanguage) and keep the same >name? Or change the name to "document-natural-languages"? >Keep single-valued. It will handle the vast majority of cases and >keep things simple > >ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table >14 that go with the Document Template attributes. >OK > >ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Document Template attributes. >OK > >ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx >in the IANA Registration of Job Template attributes being defined. >OK > >ISSUE 17: TBD - Need to list the keyword attribute values in the IANA >Registration section. Do so by reference to the values registered for >corresponding attributes. >OK > >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 > > > >ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf > >Send any comments to the SM mailing list. > >Thanks, >Tom > > >----- >This message was submitted by Tom Hastings (Xerox) >Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5383 >Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 ----- This message was submitted by Martin Bailey (Global Graphics Software) Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5407 Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1 From AMcCarthy at crt.xerox.com Thu Mar 20 11:17:07 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:39 2009 Subject: SM> RE: JDF FileSpec/@FileFormatVersionand IPP "document-form at-versi on"for PDF/X and TIFF/IT Message-ID: Martin, One question: What is FP? I did not see that in the 1998 standard - my impression from reading the spec is that TIFF/IT is the all inclusive designation. Is that not correct? Also, regarding your comment: >But, as I commented above, the list in the spec can only be regarded as >incomplete, so it might be better to explicitly make it a set of examples >and include only some of these? It seems better to me to put the complete list that you have provided into the spec. One benefit is that it clearly warns readers that each of these conformance levels is distinct. Regards, Ann -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E At 15:27 19/03/2003, Ann McCarthy wrote: >TIFF/IT files also have several possible conformance levels. >TIFF/IT conformance strings (given in section 5 of ISO 12639) >are: >TIFF/IT >TIFF/IT-CT >TIFF/IT-LW >TIFF/IT-HC >TIFF/IT-MP >TIFF/IT-BP >TIFF/IT-BL >TIFF/IT-P1 >TIFF/IT-CT/P1 >TIFF/IT-LW/P1 >TIFF/IT-HC/P1 >TIFF/IT-MP/P1 >TIFF/IT-BP/P1 >TIFF/IT-BL/P1 > -----Original Message----- From: Martin Bailey [mailto:Martin.Bailey@globalgraphics.com] Sent: Thursday, March 20, 2003 03:03 To: hastings@cp10.es.xerox.com Subject: CIP4 Forum Capabilities: Re:JDF FileSpec/@FileFormatVersionand IPP "document-format-version"for PDF/X and TIFF/IT Hi Tom Responses in-line. .... Ann's suggested list is almost what we need: - I'm not sure what "TIFF/IT" on its own means in that context - did you mean 'FP'? I know FP isn't normative in the 1998 standard (it is in the 2003 revision), but that doesn't stop people using it :-) - there's a 2003 revision of 12639 in ballot at the moment, so we need a date suffix on all of the above. In theory the P1 subset has not been changed in that revision (we tried not leave it unchanged, anyway), but I'd feel safer with a date suffix still, although that might complicate capabilities reporting somewhat. The revision also adds a new file subtype (SD), and a new conformance level (P2). The full list therefore gets a bit long: TIFF/IT-FP:1998 TIFF/IT-CT:1998 TIFF/IT-LW:1998 TIFF/IT-HC:1998 TIFF/IT-MP:1998 TIFF/IT-BP:1998 TIFF/IT-BL:1998 TIFF/IT-FP/P1:1998 TIFF/IT-CT/P1:1998 TIFF/IT-LW/P1:1998 TIFF/IT-HC/P1:1998 TIFF/IT-MP/P1:1998 TIFF/IT-BP/P1:1998 TIFF/IT-BL/P1:1998 TIFF/IT-FP:2003 TIFF/IT-CT:2003 TIFF/IT-LW:2003 TIFF/IT-HC:2003 TIFF/IT-MP:2003 TIFF/IT-BP:2003 TIFF/IT-BL:2003 TIFF/IT-SD:2003 TIFF/IT-FP/P1:2003 TIFF/IT-CT/P1:2003 TIFF/IT-LW/P1:2003 TIFF/IT-HC/P1:2003 TIFF/IT-MP/P1:2003 TIFF/IT-BP/P1:2003 TIFF/IT-BL/P1:2003 (no P1 conformance level of SD) TIFF/IT-FP/P2:2003 TIFF/IT-CT/P2:2003 TIFF/IT-LW/P2:2003 TIFF/IT-HC/P2:2003 TIFF/IT-MP/P2:2003 TIFF/IT-BP/P2:2003 TIFF/IT-BL/P2:2003 TIFF/IT-SD/P2:2003 But, as I commented above, the list in the spec can only be regarded as incomplete, so it might be better to explicitly make it a set of examples and include only some of these? At 07:32 19/03/2003, Bob Taylor wrote: > >I would think we'd just use the TIFF MIME type for these (application/TIFF >?). > No, because most TIFF/IT subfile types are not valid TIFF. Martin From hastings at cp10.es.xerox.com Thu Mar 20 18:49:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Document object, Meeting Notes, Thursday, March 20, 2003 Message-ID: Document object, Meeting Notes, Thursday, March 20, 2003 File: document-object-meeting-notes-20030320.doc Attendees: Peter Zehler, Dennis Carney, Gail Songer, Ira McDonald, Bob Tailor, Tom Hastings, Harry Lewis. The notes are edited into Peter's response to the outstanding issues. We resolved all of the issues on the telecon. See the notes below. Please send any comments on these minutes now, so I can reflect in the updated document. [Editor's note: we changed the semantics of the "document-format-details" operation attribute at the end of the telecon from the member attributes being Must Honor to being Best Effort, but didn't revisit the name of the corresponding "document-format-details-allowed" (1setOf collection) Printer attribute. Since the Printer will allow other attributes and values (and ignore them), the "-allowed" suffix is now mis-leading. So Ira and I suggest that we change the suffix from "-allowed" to "-implemented". So change "document-format-details-allowed" to "document-format-details-implemented". OK? I've assumed this change in the following notes.] ACTION ITEM (Tom): Update and post the spec today or tomorrow. ACTION ITEM (Pete): Update and post the Semantic Model to reflect the agreements (probably Monday). Hold a second one hour review, next Thursday, March 27, 2003, same time (10:00 AM PST, 1:00 PM EST). Peter and Bob to setup the teleconference and webex, respectively. Tom From: Zehler, Peter Sent: Tuesday, March 18, 2003 06:52 To: Hastings, Tom N; sm@pwg.org Subject: My response to some of the 18 Document issues...Comments? All, I saw many of the issues as "low hanging fruit". I have my responses to issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on and issues 14 to 17 are basically work to be done. This leaves issues 9 and 11. These involve how to represent the supported values for the document format detail attributes. I think we will need to dedicate a large chunk of time for this issue in Thursday's teleconference. Are there any comments on these issues or my responses? Pete ISSUE 00: Or should we just delete "input-document-number" operation attribute when we republish pwg5100.4 without "document-overrides? Delete "input-document-number". Document numbers start at 1 and monotonically increment as documents are added to the Job. AGREED. ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the object on which it operates? No, keep it Send-Data. I see no reason for the longer name. The only data we send is associated with a Document. We don't have CreateJob-Document or Create-Printer-Job. AGREED: to keep name as Send-Data ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support it, since PSI is using it? Yes AGREED. ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute for a Printer to support (if it supports the Document object)? Otherwise, clients won't support it and will be stuck with the "ipp-attribute-fidelity" attribute? It should be an OPTIONAL Operation Attribute that a Printer MUST support if the Printer supports the Document Object. AGREED: The Printer MUST support the "job-mandatory-attributes" operation attribute, client MAY supply. ISSUE 04: The "document-overrides" attribute is also useful in combination with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the Input Page stream concatenated across the Input Documents into separate Output Documents. For example, making every 10 Input Pages be a separate Output Document but the client only wants to staple the first Output Document. ISSUE 04: But what about Subset Finishing? Can we it be done without "document-overrides"? Get rid of "document-overrides" in favor of the Document. Place the burden of the example corner case on the Client. The results can be easily achieved through the use of Documents and page-overrides. AGREED: Subset finishing is how to staple ranges of pages that cover all of a single document? Do subset finishing with "page-overrides", instead of "document-overrides" (which is being deleted). One possibility is to use "pages-per-subset" (1setOf integer) as one of the member attributes of the "page-overrides" since "pages-per-subset" is a Job Template attribute that applies to an Input Document. Tom to talk to Claudia Alimpich from IBM as well, since the concept of subset finishing is also in the FSG Job Ticket API. ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE the Printer to continue to support the "page-overrides" as an operation attribute in Send-Document and Send-URI as well as a Document Template attribute? Yes AGREED: If a Printer supports "page-overrides": a. the Printer MUST support both the "page-overrides" as (1) an operation attribute (for backward compatibility and clients that don't support the Document object) and (2) as a Document Template attribute in Send-Document and Send-URI requests. The client MAY supply "page-overrides" as either a Job Template attribute or an operation attribute in Send-Document and Send-URI requests. b. the Printer MUST support "page-overrides" as a Document Template attribute, not as an operation attribute in Create-Document requests. ISSUE 06: OK that "document-container-summary" is only one level deep? Yes, this information is not a manifest of the contained documents. It is used to determine if a Printer can process the Document. Clients are free to send individual compressed Documents if a manifest of a Job's contents is required. AGREED: That is it OK to have only one level for the summary details attribute that the Printer uses to accept or reject jobs. 6.1 Should have two separate attributes, one for summary details and one for a "document-manifest" which has a separate entry for each file in a container and needs to allow nesting to be expressed. ACTION (Tom and Bob): Advocate two separate attributes with CIP4, rather than defining one form that tries to do both. 6.2 We'll won't add the manifest attribute to IPP Document object at this point. 6.3 Need a better word than container and a better word than summary. Agreed to go back to "document-format-details" and clarify that it is unordered and applies to a single document file as well as a container file containing multiple files. 6.4 Move the top level operation/Document Description attributes (except "document-format" which remains at both levels) back to be member attributes of the "document-format-details" collection operation/Document Description attribute. So the following Document Description attributes will be the member attributes of the "document-format-details" operation/Document Description attribute: document-creator-application-name (name(MAX)) document-creator-application-version (text(127)) document-creator-os-name (name(40)) document-creator-os-version (text(40)) document-format (mimeMediaType document-format-device-id (text(127)) document-format-version (text(127) document-natural-language (naturalLanguage) 6.5 Allow, but don't require, the client to supply one of the collection values to describe the details about the top level container format (application/zip and multipart/related) as well. 6.6 Add a "document-format-details-detected" Job Description attribute which the Printer MAY support and fill in with detected values. Keep "document-format-detected" as a separate Job Description attribute, so that collections aren't required by a Printer that only wants to reflect the document format detected. 6.7 The "document-format-details" will remain an operation attribute that the Printer MUST copy to the corresponding Document Description attribute, same as for the "document-format" operation/Document Description attribute. 6.8 Other Document Description attributes that the Printer detects/updates, such as "k-octets", are a separate concept and aren't to be added to "document-format-details" or "document-format-details-detected". ISSUE 07: Is the description of "document-container-summary" attribute OK? Clarify that a manifest can be accomplished by the Client sending individually compressed Documents. AGREED. ISSUE 08: Are the conformance requirements for the "document-container-summary" attributes OK? No opinion AGREED: A Printer MUST support the "document-format" and the "document-format-version" member attributes, and MAY support any of the other member attributes: document-creator-application-name (name(MAX)) document-creator-application-version (text(127)) document-creator-os-name (name(40)) document-creator-os-version (text(40)) document-format-device-id (text(127)) document-natural-language (naturalLanguage) ISSUE: 09: How can a Printer indicate which combinations of document-creator-application-name (name(MAX)), document-creator-application-version (text(127)), document-creator-os-name (name(40)), document-creator-os-version (text(40)), document-format-device-id (text(127)), document-format-version (text(127), document-format (mimeMediaType) and "document-natural-language (naturalLanguage) are supported? AGREED: 9.1 Add a "document-format-details-supported" (1setOf type2 keyword) Printer Description attribute which lists the member attributes of "document-format-details" that the Printer supports. Values: document-creator-application-name, document-creator-application-version, document-creator-os-name, document-creator-os-version, document-format, document-format-device-id, document-format-version, and document-natural-language. 9.2 We won't define "xxx-supported" attributes that go with each of the member attributes of "document-format-details", since the member attributes are not orthogonal to each other. Instead, define a "document-format-details-implemented" (1setOf collection) Printer Description attribute whose member attributes show collections of values that go together. The member attributes of "document-format-details-implemented" are: document-creator-application-name-implemented (1setOf name(MAX)) document-creator-application-version-implemented (1setOf text(127)) document-creator-os-name-implemented (1setOf name(40)) document-creator-os-version-implemented (1setOf text(40)) document-format-implemented (1setOf mimeMediaType document-format-device-id-implemented (1setOf text(127)) document-format-version-implemented (1setOf text(127) document-natural-language-implemented (1setOf naturalLanguage) 9.3 Except for "document-format", all other member attributes supplied by a client are supplied as "hints", that is Best Effort (i.e., treat as if fidelity is false), whether the Printer's "document-format-details-implemented" Printer Description attribute has that member attribute or not and whether or not the Printer's "document-format-details-supported" has that keyword for that member attribute. The "document-format" operation attribute and member attribute of "document-format-details" remain as a Must Honor attribute (i.e., treat as if fidelity is true and reject the job if the document-format isn't supported). 9.4 Currently, "ipp-attribute-fidelity" and the new "job-mandatory-attributes" do NOT apply to operation attributes, only to Job Template attributes. However as an exception, "ipp-attribute-fidelity" and the new "job-mandatory-attributes" will be defined to apply to the "document-format-details" operation attribute and all its member attributes. For example, the client can supply the following keyword value for the "job-mandatory-attributes" attribute: 'document-format-details.document-format-os-name' indicating that the Printer MUST honor the OS name or MUST reject the job. The "document-format" member attribute (and operation attribute) will remain forever mandatory (Must Honor) as in [RFC2911], independent of "ipp-attribute-fidelity" and "job-mandatory-attributes". Example of a single set of values for a Printer of "document-format-details-implemented" (1setOf collection): {{document-format=application/ps, document-format-version=1, 2, 3}, {document-format=application/ps, document-format-version=3, document-natural-language=en, fr, de}, {document-format=application/vnd.hp-PCL, document-format-version=5e}, {document-format=application/msword, document-format-version=5.0, 6.0, 2000, document-format-os-name=MACOS, WINDOWS} } Typically, there will only be one value for "document-format" in each collection. However, there can be more than one occurrence of a collection value with the same "document-format". See above example which has two PostScript collection values. ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to support? Yes AGREED: Printer MUST support the "document-format" and "document-format-version" member attributes if it supports the "document-format-details" collection attribute. The Printer MAY support additional member attributes. ISSUE: 11: The problem with separating "document-format" and "document-format-version" is how can a Printer describe what versions are supported, since the versions have to be associated with the document format. AGREED: The "document-format-details-implemented" (1setOf collection) Printer Description attribute describes which versions go with each document format. See ISSUE ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X. ISSUE 12: Or should the official ISO standard number, part number and date, be used instead, e.g., "ISO nnnnn.n-2001"? No opinion AGREED: Use examples as agreed in CIP4 from the ISO standard itself, such as 'PDF/X-1:2001' and 'PDF/X-1a:2001' which are from the same ISO standard. ISSUE 13: The definition of "document-natural-language" in [rfc2911] ?3.2.1.1 and [pwg5100.4] ?5.1.7 is single-valued. OK that this Document Description attribute isn't 1setOf? Or should we extend "document-natural-language" to 1setOf naturalLanguage) and keep the same name? Or change the name to "document-natural-languages"? Keep single-valued. It will handle the vast majority of cases and keep things simple AGREED: Clarify that the first language in the document is used as the value. ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table 14 that go with the Document Template attributes. OK AGREED ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Document Template attributes. OK AGREED ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx in the IANA Registration of Job Template attributes being defined. OK AGREED ISSUE 17: TBD - Need to list the keyword attribute values in the IANA Registration section. Do so by reference to the values registered for corresponding attributes. OK AGREED 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 ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf Send any comments to the SM mailing list. Thanks, Tom From hastings at cp10.es.xerox.com Mon Mar 24 04:07:12 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Updated Comparison of JDF FileSpec and corresponding IPP Document object available Message-ID: The downloaded document starts out with the proposed JDF FileSpec resource additions. Then the second half is a side-by-side comparison of the JDF FileSpec resource with IPP Document object attributes. I've included the changes to the specific IPP "document-format-details" member attributes from the Thursday, 20-March-2003 telecon. The document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030321.doc. zip ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/New-FileSpec-and-IPP-attrs-030321.pdf This document contains proposed additions and clarifications to the JDF FileSpec resource for JDF/1.2 and the corresponding IPP Document Description attribute proposed for the IPP Document object extensions. The reason for showing both in the same document is to try to align the semantics where possible. Some of us believe that there will be significant interworking between JDF and other systems, such as IPP. Having the same values of corresponding attributes will make gateways a lot simpler. Note: There is no need for the names of the attributes to be the same. The real gain is for the values. These proposals build on the proposals from Martin Bailey, Bob Taylor, and Israel Viente in CIP4 and the proposals from Bob Taylor, Dave Hall, and Peter Zehler in the PWG for inclusion in the IPP Document Object, PWG Semantic Model and PWG Print Services Interface (PSI) which is a follow on to Bluetooth. The most recent version results from a telecon on March 21 with Craig Benson, Bob Taylor, Steve Hiebert, and Tom Hastings attempting to accommodate all of the comments received in email. Please send any comments. I'm working on the full IPP Document object spec updating the agreements reached on Thursday, March 20 telecon and will have it out on Monday, March 24. Tom From PZehler at crt.xerox.com Mon Mar 24 12:16:08 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Inconsistent Action, Element, StatusString and Value Message-ID: All, Unless there is any objection I would like to keep the naming convention consistent across the PWG Semantic Model. We recently changed the StatusString to align with the way all the elements and actions are named. While working on appendix B I saw the mapping could be simplified if we apply the same rules to the values of elements as we do to the elements. Therefore I propose that the values for the elements be aligned with our convention of capitalizing the first letter, dropping the '-' and capitalizing the letter that follows it. Of course the values that we reference from non-PWG/IPP sources would remain the same (e.g. mime type names). I would also not change the values used for media types, media color, and media size since they are in a non-IPP specific registry(PWG5101.1) and are in use in other environments. Any objections? 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 From PZehler at crt.xerox.com Mon Mar 24 12:38:51 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Case sensitivity Message-ID: All, In the Semantic Model what is our position on case sensitivity? The Semantic Model and its associated schema use Pascal casing for element names to improve readability. I assume that 1) Semantic elements (actions, elements, keywords) must differ in more than case. That is, we will not define a mew semantic element such " Jobstate" since "JobState" is already defined. Do we mandate that how the equality of tokens (i.e. keywords) is handled in the Semantic Model document? 2) I assume keywords are compared without regard to case in the model and leave it to the mapping to determine what rules will be applied in that particular mapping of the Semantic Model. 2a) Implementations are simplified in low end mappings and in XML if case sensitive mapping is mandated. 2b) Server implementations would be more forgiving if they did case insensitive compares. Any objections to including the 2 statements above in the next SM release? 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 From imcdonald at sharplabs.com Mon Mar 24 12:45:18 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:39 2009 Subject: SM> Case sensitivity Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF45@mailsrvnt02.enet.sharplabs.com> Hi Pete, I agree with your positions on case sensitivity below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Monday, March 24, 2003 11:39 AM To: PWG Semantic Model WG (E-mail) Subject: SM> Case sensitivity All, In the Semantic Model what is our position on case sensitivity? The Semantic Model and its associated schema use Pascal casing for element names to improve readability. I assume that 1) Semantic elements (actions, elements, keywords) must differ in more than case. That is, we will not define a mew semantic element such " Jobstate" since "JobState" is already defined. Do we mandate that how the equality of tokens (i.e. keywords) is handled in the Semantic Model document? 2) I assume keywords are compared without regard to case in the model and leave it to the mapping to determine what rules will be applied in that particular mapping of the Semantic Model. 2a) Implementations are simplified in low end mappings and in XML if case sensitive mapping is mandated. 2b) Server implementations would be more forgiving if they did case insensitive compares. Any objections to including the 2 statements above in the next SM release? 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 From dhall at hp.com Mon Mar 24 13:13:44 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:39 2009 Subject: SM> Case sensitivity Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FABCB@xvan01.vcd.hp.com> I'll second that agreement. Case insensitive compares on keywords is a good thing. However, I would not like to see anyone having to deal with JobState vs. Jobstate as an element declaration (ie, everyone must always use JobState..) Dave -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, March 24, 2003 9:45 AM To: 'Zehler, Peter'; PWG Semantic Model WG (E-mail) Subject: RE: SM> Case sensitivity Hi Pete, I agree with your positions on case sensitivity below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Monday, March 24, 2003 11:39 AM To: PWG Semantic Model WG (E-mail) Subject: SM> Case sensitivity All, In the Semantic Model what is our position on case sensitivity? The Semantic Model and its associated schema use Pascal casing for element names to improve readability. I assume that 1) Semantic elements (actions, elements, keywords) must differ in more than case. That is, we will not define a mew semantic element such " Jobstate" since "JobState" is already defined. Do we mandate that how the equality of tokens (i.e. keywords) is handled in the Semantic Model document? 2) I assume keywords are compared without regard to case in the model and leave it to the mapping to determine what rules will be applied in that particular mapping of the Semantic Model. 2a) Implementations are simplified in low end mappings and in XML if case sensitive mapping is mandated. 2b) Server implementations would be more forgiving if they did case insensitive compares. Any objections to including the 2 statements above in the next SM release? 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 From PZehler at crt.xerox.com Mon Mar 24 14:32:11 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Placeholder for Thursday's Semantic Model Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be cover the Document Object, the Semantic Model and preparing for the upcoming Face-to-Face. The documents are not quite ready yet, but I wanted to make sure to get a meeting reminder out. The teleconference is one hour long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) Adjust agenda 3) Check out the latest changes to the Semantic Model Specification I'll post the latest version on Tuesday 2) Walk through Document Object Specification I'll post the latest version on Tuesday 3) What will be accomplished at the Face-to-Face 4) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 3/27/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From ElliottBradshaw at oaktech.com Mon Mar 24 16:38:05 2003 From: ElliottBradshaw at oaktech.com (ElliottBradshaw@oaktech.com) Date: Wed May 6 14:04:39 2009 Subject: SM> New CR document: Standard for Character Repertoire Interoperabiliy Message-ID: Folks, I have placed an updated version of the Chracter Repertoires document at: ftp://ftp.pwg.org/pub/pwg/Character-Repertoires/wd-pcr10-20030317.html This is a standards track document intended to serve as a reference for the Semantic Model. In addition to Yet Another Name, hightlights of recent changes include: -Changed the title to remove "Preferred" -Marked some sections as Informative -Formatting cleanup; addition of copyright notice, acknowledgements, etc. -Clarification in the Abstract and Introduction of goals and non-goals -More information about how this document relates to the Semantic Model -Changed the details of syntax for repertoire names -More information about rules for matching repertoire names -Clarified the wording regarding font sensitivity -Confirmed use of Unicode code charts for basic non-Asian repertoires -Changed from the notion of "Preferred Repertoire" to "Basic Repertoire"; this emphasizes that the printer is free to advertise additional repertoires -Included Latin-1 Supplement and Latin Extended-A as Basic Repertoires -Added requirement to support the euro character -References Open issues (that I know of) are highlighted in the document. Based on recent meetings I think we are approaching consensus on a number of issues. Some specific things I want to work on next week: -making this suitable for use by SM -applying the appropriate PWG process: name, number, approval, etc. Depending on how our discussion goes we may be able to move to Last Call in the fairly near future. Please send comments ASAP, esp. if you will not be in DC. Thanks, Elliott ------------------------------------------ Elliott Bradshaw Director, Software Engineering Oak Technology Imaging Group 781 638-7534 From hastings at cp10.es.xerox.com Tue Mar 25 05:52:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Updated IPP Document Object spec downloaded for Thur, March 27, S M telecon Message-ID: I've down loaded the updated versions of the IPP Document Object specification with the changes agreed to at the Thursday, March 20, 2003 telecon. They are at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) Change Log: Version 0.8, 24 March 2003, agreements from the March 20 telecon: 1. Changed the name of the Send-Document-Data back to Send-Data to keep the name short. There wasn't support for keeping the name of the object affected in the name of the operation. 2. Changed "job-mandatory-attributes" operation/Job Description attribute so that a Printer MUST support it. 3. Changed the name of the collection attribute back to "document-format-details". 4. Removed the Operation attributes and Document Description attributes that were already in the member attributes of "document-format-details", so that any details must use the "document-format-details" (1setOf collection). 5. Clarified that with the removal of "document-overrides", that the client can achieve subset finishing using "pages-per-subset" and "page-overrides". 6. Clarified that a Printer that supports "page-overrides" Document Template attribute MUST also support it as an Operation attribute in Send-Document and Send-URI, but not Create-Document, for backward compatibility. 7. Clarified that containers may contain containers, but that the "document-format-details" MUST be flattened, if present. 8. Clarified that the collection values MAY describe the container format itself, in which case, it must be the first collection value. 9. Added "document-format-details-detected (1setOf collection) Document Description attribute. 10. Clarified that "document-natural-language" identifies the primary or first language if a Document contains more than one language. 11. Added document-format-details-supported (1setOf type2 keyword) Printer Description attribute. 12. Added document-format-details-implemented (1setOf collection) Printer Description attribute. 13. Clarified that a Printer MUST support the "document-creation-attributes-supported" (1setOf type2 keywords) Printer Description attribute. One ISSUE remaining: Values of the "document-creator-application-version: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)"'V3.0.', 'V6.0' ISSUE: OK that the purpose of "document-creator-application-version is human consumption, instead of program consumption and that it be the same as the application shows in its help message? Tom From imcdonald at sharplabs.com Tue Mar 25 12:18:24 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:39 2009 Subject: SM> document-id-uri semantics Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF47@mailsrvnt02.enet.sharplabs.com> Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 16:48:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> document-id-uri semantics Message-ID: Is there any experimental scheme that we could use, so we don't have to muck with the "ipp:" scheme? If there is, we could just mention what that scheme is in the spec. Or since this is a URI data type, is there some URN form that we could use to give each document a unique identifiers? All we want is a unique identifier across that one Printer. Its doesn't have to be unique across all Printers, right? We also need to agree as to over what time period the ID has to be unique? If the Printer is powered off and comes back again, does it have to continue to generate unique URIs that it never generated before? Or don't we have to be that strict. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Tuesday, March 25, 2003 09:18 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> document-id-uri semantics Hi, The current "document-id-uri" in the IPP Document Object spec clearly that states that it is an opaque identifier, and cannot be used as the target of an operation (unlike the "job-uri" in RFC 2911). And it gives an example of an 'ipp:' schemed URI. I think I should write an Appendix to the Document Object that: (1) extends the IPP URL Scheme (adopted last month by the IETF for RFC publication as an IETF Proposed Standard) to apply to Document objects as well, (2) specifies the opaque identifier limitation, (3) is normatively referenced by the "document-id-uri" attribute definition in the main spec. As we discussed on the PSI telecon this morning, PSI doesn't care what the URL scheme is in the DocumentURI, just that it be unique within a print server. Comments? Cheers, - Ira McDonald, co-editor of IPP URL Scheme High North Inc From hastings at cp10.es.xerox.com Tue Mar 25 17:31:30 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Message-ID: Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From PZehler at crt.xerox.com Wed Mar 26 08:13:01 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Updated IPP Document Object spec downloaded for Thur, Mar ch 27, S M telecon Message-ID: Tom, Section 8.2.10 should reference section 6.1.2 for the definition of member attributes and semantics. 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: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 5:52 AM To: sm@pwg.org Subject: SM> Updated IPP Document Object spec downloaded for Thur, March 27, S M telecon I've down loaded the updated versions of the IPP Document Object specification with the changes agreed to at the Thursday, March 20, 2003 telecon. They are at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) Change Log: Version 0.8, 24 March 2003, agreements from the March 20 telecon: 1. Changed the name of the Send-Document-Data back to Send-Data to keep the name short. There wasn't support for keeping the name of the object affected in the name of the operation. 2. Changed "job-mandatory-attributes" operation/Job Description attribute so that a Printer MUST support it. 3. Changed the name of the collection attribute back to "document-format-details". 4. Removed the Operation attributes and Document Description attributes that were already in the member attributes of "document-format-details", so that any details must use the "document-format-details" (1setOf collection). 5. Clarified that with the removal of "document-overrides", that the client can achieve subset finishing using "pages-per-subset" and "page-overrides". 6. Clarified that a Printer that supports "page-overrides" Document Template attribute MUST also support it as an Operation attribute in Send-Document and Send-URI, but not Create-Document, for backward compatibility. 7. Clarified that containers may contain containers, but that the "document-format-details" MUST be flattened, if present. 8. Clarified that the collection values MAY describe the container format itself, in which case, it must be the first collection value. 9. Added "document-format-details-detected (1setOf collection) Document Description attribute. 10. Clarified that "document-natural-language" identifies the primary or first language if a Document contains more than one language. 11. Added document-format-details-supported (1setOf type2 keyword) Printer Description attribute. 12. Added document-format-details-implemented (1setOf collection) Printer Description attribute. 13. Clarified that a Printer MUST support the "document-creation-attributes-supported" (1setOf type2 keywords) Printer Description attribute. One ISSUE remaining: Values of the "document-creator-application-version: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)"'V3.0.', 'V6.0' ISSUE: OK that the purpose of "document-creator-application-version is human consumption, instead of program consumption and that it be the same as the application shows in its help message? Tom From PZehler at crt.xerox.com Wed Mar 26 11:30:49 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Updated SM spec for Thur, March 27, S M telecon Message-ID: All, Here is the document we will use for the Semantic Model teleconference this week. ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030326.pdf I Highlighted the sections in the table of contents and in the body of the document that we will cover. As usual both word and pdf file formats are provided as well as "-rev" version of the document in both formats. Below are March's change log entries from the document. 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 3/26/03 PJZ Updated with changes from Document Object Specification 3/21/03 PJZ Added Character Repertoire 3/17/03 PJZ Removed PSI specific actions, corrected list of excluded elements in appendix B 3/16/03 TNH/PJZ Updated with the Document Object specifications. Added CloseJob that PSI is using. Renamed SendData to SendDocumentData to indicate what data. Prefixed JobId, JobPrinterUri, and JobUri Document Description elements with Document, so no Document attributes have a Job prefix. Added the following Document Description elements: DocumentContainerSummary, DocumentCreatorApplicationName, DocumentCreatorApplicationVersion, DocumentCreatorOsName, DocumentCreatorOsVersion, DocumentFormatDetected, DocumentFormatDeviceId, DocumentFormatVersion, DocumentIdUri, DocumentMessage, ElementNaturalLanguage. From PZehler at crt.xerox.com Wed Mar 26 11:34:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Complete information for Thursday's Semantic Model Teleconference Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference will be cover the Document Object, the Semantic > Model and preparing for the upcoming Face-to-Face. The documents > are not quite ready yet, but I wanted to make sure to get a meeting > reminder out. > > The teleconference is one hour long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > > The agenda for the Semantic Model teleconference is : > > 1) Adjust agenda > 3) Check out the latest changes to the Semantic Model Specification > ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030326.pdf > 2) Walk through Document Object Specification > ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip > 3) What to do now that the Face-to-Face is canceled > 4) Next steps > > > Pete > > PS: Bob, Let me know if you can not host the Webex. > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > > Webex MEETING SUMMARY > ------------------------- > Name: PWG Semantic Model > Date: 3/27/2003 > Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) > 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) > Meeting Number: 21366675 > Meeting Password: pwg_sm > Host: > Bob Taylor (HP) > > ___________________________________________________ > > > > > 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 > > From hastings at cp10.es.xerox.com Wed Mar 26 18:05:00 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Message-ID: Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From PZehler at crt.xerox.com Mon Mar 31 09:26:27 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Semantic Model Teleconference 4/3 Message-ID: All, The Semantic Model group will be holding a teleconference on Thursday April 3. The primary focus of the teleconference is to complete the review of the Document Object Specification. The current plan is to hold the teleconference from 12:00 to 3:00 eastern (9:00 to 12:00 Pacific). The first hour we will discuss the latest schema (version 0.91) which will be posted some time this week. The agenda and teleconference information is included below. Will anyone be able to host a Webex for this teleconference? ___________________________________________________ Agenda: 12:00 to 12:10 EST (9:00 to 9:10 PST): Intros & adjust agenda 12:10 to 1:00 EST (9:10 to 10:00 PST) : Schema review Overview of changes Discuss any issues Schema structure and tool issues Schema reuse discussion Next steps 1:00 to 1:10 EST (10:00 to 10:10 PST): Intros & adjust agenda for Document Object 1:10 to 3:00 EST (10:10 to 12:00 PST): Document Object review Priority issue discussion Page turn review Next steps ___________________________________________________ Dial in info: Dial-In #: +1 719-457-0335 Participant Password: 400908# ___________________________________________________ Webex info: TBD ___________________________________________________ Document Links: Document Object Specification: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip PWG Semantic Model Schema v0.91 (To be posted this week): http://www.pwg.org/sm/index.html PWG Semantic Model v0.27 (To be posted later today): ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030331.pdf ___________________________________________________ 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 From hastings at cp10.es.xerox.com Tue Apr 1 21:46:05 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From PZehler at crt.xerox.com Wed Apr 2 07:34:16 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Semantic Model Teleconference 4/3 (Complete Information) Message-ID: All, The Semantic Model group will be holding a teleconference on Thursday April 3. The primary focus of the teleconference is to complete the review of the Document Object Specification. The current plan is to hold the teleconference from 12:00 to 3:00pm eastern (9:00am to 12:00 Pacific). The first hour we will discuss the latest schema (version 0.93). The agenda and teleconference information is included below. ___________________________________________________ Agenda: 12:00 to 12:10pm EST (9:00am to 9:10am PST): Intros & adjust agenda 12:10pm to 1:00pm EST (9:10am to 10:00am PST) : Schema review Overview of changes Discuss any issues Schema structure and tool issues Schema reuse discussion Next steps 1:00pm to 1:10pm EST (10:00am to 10:10am PST): Intros & adjust agenda for Document Object 1:10pm to 3:00pm EST (10:10am to 12:00 PST): Document Object review Priority issue discussion Process 9 outstanding issues Page turn review Next steps ___________________________________________________ Dial in info: Dial-In #: +1 719-457-0335 Participant Password: 400908# ___________________________________________________ Webex info: https://hp.webex.com/join/ Name: Semantic Model Date: 4/3/2003 Time: 12:00 EST(9:00am PST) Meeting Number: 29039952 Meeting Password: pwg_sm ___________________________________________________ Document Links: Document Object Specification: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip Document Object Outstanding Issues (9) http://www.pwg.org/hypermail/sm/0179.html PWG Semantic Model Schema v0.93: http://www.pwg.org/sm/index.html PWG Semantic Model v0.27: ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm010-20030331.pdf ___________________________________________________ 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 From hastings at cp10.es.xerox.com Wed Apr 2 21:23:31 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document obj ect tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) Message-ID: And a 10th issue for the Document Object spec: 10. At today's IPPFAX telecon, we discussed the following IPPFAX Printer Description attribute: digital-signatures-supported (1setOf type2 keyword) This attribute identifies which digital signatures technologies are supported by the Receiver. A Receiver MUST support this Printer Description attribute. TODO: Get list of keywords; can be found in "IPP driver install" spec We agreed that it should go in the IPP Document object spec, and that it should have a "digital-signature" (type2 keyword) operation/Document Description attribute that the client submits in a Document Creation operation as well. And therefore, the spelling of the corresponding "digital-signature-supported" (1setOf type2 keyword) Printer Description attribute should be without the "s". The description from the "IPP Driver Install" (IPP Printer Installation Extension) spec is: "digital-signature" One REQUIRED LOWER-CASE 'keyword' string identifying the mechanism used to ensure the integrity and authenticity of this set of Client Print Support Files. Standard values are: 'smime', 'pgp', 'dss', and 'xmldsig' which are defined in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively. In addition, the special keyword value: 'none' is valid. The 'none' value MUST be supported if this attribute is supported. Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 01, 2003 18:46 To: sm@pwg.org Cc: ps@pwg.org Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST) The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent out March 25: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip (1,225 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip (294 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip (649 KB) ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip (309 KB) This note summarizes the suggestions that have been and issues raised since the document was sent out, including discussions in CIP4 about the JDF/FileSpec resource and the SM telecon March 27. The first part of this mail note is a summary of the issues and point to earlier mail messages that are appended for more detail and rationale. 1. Close-Job operation needs the same timeout Printer requirements as RFC 2911 has for Send-Document. 2. Remove "document-id-uri" Document Description attribute. PSI agreed last week that they can use the IPP "document-number" (integer(1:MAX)) Document Description attribute to identify documents within a job. 3. Add a "document-format-version" (text(127)) operation/Document Description attribute with self-identifing values, such as 'PS/3.0', 'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more details). The prefix is from the Printer MIB langTC values used in the prtInterpretedLangFamily object and the version after the "/" can be used in the Printer MIB prtInterpreterLangLevel object. 4. Add a "document-format-version-default" (text(127)) and "document-format-version-supported" (1setOf text(127)) Printer Description attributes to describe the default and supported values. (See ISSUES 03 below for more details). So "document-format-version" and "document-format" would have parallel semantics, including also being member attributes of "document-format-details" (1setOf collection). 5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort (hint) unless "ipp-attribute-fidelity" = 'true" or "job-mandatory-attributes" = 'document-format-version' or do we make "document-format-version" be like "document-format" in that the Printer MUST reject the job if the Printer doesn't support the version? 6. Put the version strings into a flat text file that implementers and implementations can access on the PWG FTP site. Adding new values is simply done whenever they are registered or standardized with some recognized body, such as IANA, CIP4, ISO, etc. ISSUE 05: We need to convince CIP4 to use the same flat file for their FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow the other. 7. Add a "document-natural-language" (naturalLanguage) operation/Document Description attribute and a "document-natural-language-supported" (1setOf naturalLanguage) Printer Description attribute. The "document-natural-language" operation attribute is already defined in RFC 2911 for use with Print-Job, Send-Document, and Send-URI, so we are just continuing this RFC 2911 attribute for the Create-Document operation and making it a Document Description attribute as well, so that it can be queried. Also keep "document-natural-language" (naturalLanguage) as a member attribute of "document-format-details" for describing packages. The "document-natural-language" is needed in order to know how to display characters that depend on language. ISSUE 06: What about multiple languages in a single document for the top level attribute? ISSUE 06a: What about for the member attribute of "document-format-details"? 8. Add a "document-charset" (charset) operation/Document Description attribute and a "docuemnt-charset-supported" (1setOf charset) Printer Descrition attribute. This attribute is needed for the many plain text and markup languages in which the charset is not embedded in the data. For example, PCL often doesn't have the charset escape sequence in the data. Also many files use the various 8-bit ISO 8859 charsets in which the lower half is US-ASCII and the upper half is various Latin sets (about 8 or 9), Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the left half is US-ASCII, but the right half can be one of a number of things. But if the data doesn't contain the charset escape sequences, this attribute can help the Printer know what the charset is in the Document. 9. There is one issue embedded in the Document Object spec: 6.1.2.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip? 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft? Word 2000 (9.0.4119 SR-1)" ISSUE: OK that the purpose is human consumption, instead of program consumption and that it be the same as the application shows in its help message? The two other version attribute: "document-format-version" and "document-format-os-version" are intended for program consumption, not human consumption. Its possible that CIP4 will want to have both types of versions for: applications, operating systems, and documet-formats. Tom Here is last week's thread with more details: -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 26, 2003 15:05 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> More improvements to the IPP "document-format-version" and JDF Mi meOrFileTypeVersion attributes [4 ISSUES] Ira and I had even further thoughts about the IPP "document-format-version" (wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes since it is a top level attribute in the FileSpec resource): The proposal from yesterday is to make the values of IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes be self-identifying, because they start with a prefix that identifies the format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc. ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP "docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make the values self identifying indendent of the correspoding IPP "document-format" and JDF MimeType attributes? Today's further thought is that we can now promote the IPP "document-format-version" member Operation attribute back to being a top level Document object attribute to accompany the existing "document-format" Operation attribute. This is because "document-format-version-supported" attribute now makes sense as a Printer Descrition attribute on its own, since the values would be things like: "PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998", "DCS/2.0", "MSWORD/2000" and don't need to be paired up with the correspoding "document-format-supported" Printer attribute values: "applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and "application/msword" MIME type values. ISSUE 02: OK to add a "document-format-version" operation and Document Description attribute to the IPP Document object spec? Just like the "document-format" Operation attribute which is also a member attribute of the "document-format-details" (1setOf collection) Operation/Document Description attribute, we'd keep "document-format-version" as a member attribute as well with the same prefixed values. This now means that "document-format" and "document-format-version" have all parallel construction: a. They are both operation attributes. b. They both have correspoding Document Description attributes that the Printer copies to. c. They both have "xxx-supported" Printer attributes. d. There is a "document-format-default" which now can have a corresponding "document-format-version-default" Printer attribute. ISSUE 03: OK to add "document-format-default" printer attribute? e. The Printer MUST reject the request if the "document-format" isn't supported. ISSUE 04: Do we want to make the same rule for the "document-format-version" or keep it as a Best Effort, unless the client supplies "ipp-attribute-fidelity"='true' or "job-mandatory-attributes"='document-format-version'? Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 25, 2003 14:32 To: sm@pwg.org; ps@pwg.org Cc: CIP4 System Behaviour and Interoperability WG [system_behaviour@cip4.org]; CIP4 Capabilities WG [capabilities@cip4.org] Subject: SM> Improvements of the IPP "document-format-version" and JDF MimeOfF ileTypeVersion attributes Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion the current IPP "document-format-version" attribute in the IPP Document Object spec Working Draft, dated March 24, 2003 and the JDF MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March 21, 2003. This mail note has two specific proposals: 1. Put the version strings into a flat file that can be updated and used by implementers. The respective specs can have an initial sets of strings for the flat file. 2. Make the verson strings self-identifying. Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic Model WG and CIP4 System Behaviour and Interoperability WG). The current text for the IPP "document-format-version" attribute is: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel (not prtInterpreterLangVersion), such as: '3': For Postscript level 3 [rfc1759]. '5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as:: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 The current text for the JDF MimeOfFileTypeVersion attribute is: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangLevel, such as: "1", "2", "3" for MimeType = "application/postscript" "3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "5.0", "6.0", "2000", "XP" for MimeType = "application/msword" "1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See Appendix A.1 "FileSpec Resource examples for MimeType, FileType, MimeOrFileTypeVersion attributes" for additional examples in common use by JDF applications. The two suggestions for improvement is: 1. Put the version strings into a flat file so that implementers can get them, so that new values can be added to easily, after appropriate review, without having to republish either the IPP Document Object spec or the CIP4 JDF spec. ISSUE: Whether both the PWG and CIP4 would have their own flat files that they would co-ordinate is an issue to be discussed. 2. The version string should be self identifying, e.g., PDF/1.3, not just 1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the Language Family and the Language Level attributes for the version. The Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF. In the Printer MIB there are two attributes (MIBs call them "objects"): prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." The prtInterpreterLangFamily has a Textual Convention for the assignment of about 62 printer languages. The symbolic names are of the form: langXxxx For example there are the following: langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. ... langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' So take the prtInterpreterLangFamily textual convention after the "lang", follow it with a "/" and then have the prtInterpreterLangLevel. So the updated IPP "document-format-version" member attribute would become: 6.1.2.7 document-format-version (text(127)) This REQUIRED member Operation attribute contains the level or version of the document format identified by the "document-format" member attribute. The client MAY supply and the Printer MUST support this member attribute. Possible values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/", such as: 'PS/3': For Postscript level 3 [rfc1759]. 'PCL/5e': For PCL 5e [rfc1759]. Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such a: 'PDF/X-1:2001': For PDF/X-1 [iso15930]. "? 'PDF/X-1.2001': For PDF/X-1a [iso15930] 'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page - baseline. 'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone picture data - baseline 'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page - profile 1 'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone picture data - profile 1 See PWG www.pwg.org [need URL] for a flat file list of the version strings currently recognized for use in the PWG Semantic Model and derivative protocols, such as IPP and PSI. and the updated JDF MimeOrFileTypeVersion attribute would become: The level or version of the file format identified by MimeType or, FileType. Some example values are the same as the Printer MIB [rfc1759] prtInterpreterLangFamily textual convention (minus the "lang" prefix) and prtInterpreterLangLevel, such as: "PS/1", "PS/2", "PS/3" for MimeType = "application/postscript" "PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL" Other example values are for those document formats that have well-defined version identification, either in the specification or as an actual field in the document content, such as: "MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType = "application/msword" "PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType = "application/pdf" "DCS/2.0" for FileType = "DCS" "???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC Profiles? "TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType = "TIFF/IT" See CIP4 www.cip4.org [need URL] for the flat text file that contains the version strings currently recognized for the "FileSpec Resource attributes: MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications. Comments? Tom From hastings at cp10.es.xerox.com Thu Apr 3 20:16:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Minutes of the IPP Document object spec call Message-ID: Here are the minutes of today's IPP document object spec call. I'll update the spec with these agreed changes and issue early next week for a telecon next Thursday, April 10, at the usual time. We'll do a page by page of the document. I'll highlight the changed sections (rather than using revision marks) to make it easier to read. Please read the document ahead of time, since you won't be able to read the document during the one hour telecon. Also send comments that you find to the mailing list. That will help speed up the discussion and resolution. Thanks, Tom <> <> -------------- next part -------------- A non-text attachment was scrubbed... Name: Minutes-IPP Document object telecon Thur Apr 3.doc Type: application/msword Size: 87040 bytes Desc: not available Url : http://www.pwg.org/archives/sm/attachments/20030403/f4d6fd9c/Minutes-IPPDocumentobjectteleconThurApr3-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Minutes-IPP Document object telecon Thur Apr 3.pdf Type: application/octet-stream Size: 62950 bytes Desc: not available Url : http://www.pwg.org/archives/sm/attachments/20030403/f4d6fd9c/Minutes-IPPDocumentobjectteleconThurApr3-0001.obj From PZehler at crt.xerox.com Fri Apr 4 09:37:17 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> SM Meeting Minutes posted Message-ID: All, The meeting minutes for yesterday's teleconference are available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Minutes/PWG-SM-030403.pdf Send me any comments you have and I'll update the minutes. Pete PS to Gail Could you link the meeting minutes into the SM web page when you have a chance? Thanks 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 From PZehler at crt.xerox.com Tue Apr 8 12:43:25 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> PWG Semantic Model Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object. The document is not quite ready yet, but I wanted to make sure to get a meeting reminder out. Tom should be sending the document out later today. The teleconference is one hour long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) Page turner review of the Document Object specification Link to be provided by Tom later today 2) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY (Need comfirmation from Bob) ------------------------- Name: PWG Semantic Model Date: 4/10/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 (Need comfirmation from Bob) Meeting Password: pwg_sm (Need comfirmation from Bob) Host: Bob Taylor (HP) ___________________________________________________ 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 From imcdonald at sharplabs.com Tue Apr 8 14:49:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:39 2009 Subject: SM> PWG Semantic Model Teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF75@mailsrvnt02.enet.sharplabs.com> Hi Pete and Tom, Unfortunately, I will be out on the highway all day Thursday, so I'll miss the Document Object review. Darn. Cheers, - Ira PS - I'll also miss the next PSI last call telecon next Tuesday. -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, April 08, 2003 11:43 AM To: PWG Semantic Model WG (E-mail) Subject: SM> PWG Semantic Model Teleconference All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object. The document is not quite ready yet, but I wanted to make sure to get a meeting reminder out. Tom should be sending the document out later today. The teleconference is one hour long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) Page turner review of the Document Object specification Link to be provided by Tom later today 2) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY (Need comfirmation from Bob) ------------------------- Name: PWG Semantic Model Date: 4/10/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 (Need comfirmation from Bob) Meeting Password: pwg_sm (Need comfirmation from Bob) Host: Bob Taylor (HP) ___________________________________________________ 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 From hastings at cp10.es.xerox.com Wed Apr 9 07:54:04 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) Message-ID: I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From don at lexmark.com Wed Apr 9 16:07:59 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:39 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom From harryl at us.ibm.com Wed Apr 9 18:45:51 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:39 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In-Reply-To: Message-ID: We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030409/e4cf8fd8/attachment-0001.html From hastings at cp10.es.xerox.com Thu Apr 10 11:59:48 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030410/2bfcca2a/attachment-0001.html From don at lexmark.com Thu Apr 10 14:07:58 2003 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:39 2009 Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Message-ID: Tom: ANY use of the PWG machines for "production" purposes by either the printer itself, an application running on a computer platform or by an end-user administrator/installer is not something we (me or Lexmark) can support. ********************************************** Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances & Standards Lexmark International 740 New Circle Rd Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ********************************************** "Hastings, Tom N" on 04/10/2003 11:59:48 AM To: Harry Lewis , don@lexmark.com cc: ps@pwg.org, sm@pwg.org Subject: RE: SM> Dead-on-arrival proposal from "IPP Document Object Spec a vailable for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" Don, I think that you hit on the criteria that the file is intended for human use, not automatic machine use. So how about the idea that a human installer and/or administrator can go and fetch the flat file at any time. If the site isn't available, the human will have to try again later. Also I think that the scemas are only for human consumption. The URL is used as an ID to indicate version. Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Wednesday, April 09, 2003 15:46 To: don@lexmark.com Cc: ps@pwg.org; sm@pwg.org Subject: Re: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" We touched on this earlier in the year in the context of SM schemas. We backed off when we backed off the design point where devices would hit the server real-time. If we're drifting back in that direction, we'll have to develop our requirements in terms of bandwidth, QOS, and look for commercial solutions and determine how to fund this via ISTO PWG. I do think it should be feasible to find a commercial solution that meets our needs at an affordable price. I agree with Don that we can't expect a volunteer member to bear this responsibility! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-sm@pwg.org 04/09/2003 02:07 PM To: sm@pwg.org, ps@pwg.org cc: Subject: SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)" In regards to issue 4 and some background preceding it: ---------------- The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? ---------------- I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN BEINGS!!!!! Any proposal that endorses or proposes access by machines "at install time" or "at power-up time" is simply not workable unless some other company wants to support what will become multiple machines with giant bandwidth pipes to the internet to support millions of printers and other devices. I suggest you find another solution. ******************************************* Don Wright don@lexmark.com Chair, IEEE SA Standards Board Member, IEEE-ISTO Board of Directors f.wright@ieee.org / f.wright@computer.org Director, Alliances and Standards Lexmark International 740 New Circle Rd C14/082-3 Lexington, Ky 40550 859-825-4808 (phone) 603-963-8352 (fax) ******************************************* ---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003 04:01 PM --------------------------- "Hastings, Tom N" @pwg.org on 04/09/2003 07:54:04 AM Sent by: owner-ps@pwg.org To: sm@pwg.org cc: ps@pwg.org Subject: PS> IPP Document Object Spec available for Thursday, April 10, SM Tel econ, 10-11 PDT (1-2 EDT) I've finished the editing on the IPP Document Object Spec and have down loaded it to: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip 326 KB This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT). Sorry for the short notice, but the editing took way more time than I thought. Version 0.9, 7 April 2003, agreements from the April 3 telecon: 1. Added "document-charset" (charset), "document-digital-signature" (type2 keyword), "document-format-version" (text(127)), and "document-natural-language" (naturalLanguage) Operation and Document Description attributes and corresponding "xxx-default" and "xxx-supported" Printer Description attributes. 2. Changed the "document-natural-language" member attribute of "document-format-details" (1setOf collection) operation attribute to be 1setOf, but kept the top level "document-natural-language" Operation attribute as single-valued. 3. Added Summary Table 2 of new Operation/Document Description attributes. 4. Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms. 5. Deleted the "document-id-uri" Operation attribute no longer needed by PSI. 6. Changed "ipp-attribute-fidelity" so it doesn't affect operation attributes, so it is the same as in [RFC2911]. 7. Clarified the operation attributes supplied at the Job Level in Print-Job and Print-URI versus Create-Job by introducing the "p" notation in Table 7. 8. Added columns to Table 7 to show the corresponding Document Description attributes and the "xxx-default" and "xxx-supported" Printer Description attributes. 9. Clarified that all of the new Operation attributes are hints, except "document-charset" and "document-format" and that the client can turn them into Must Honor by supplying their keyword attribute names in the "job-mandatory-attributes Operation attribute. 10. Add the unique lang prefix from the Printer MIB to all "document-format-version" values, so that they can all be in a single flat list for the Printer's "document-format-version-supported" Printer Description attribute. There are four issues embedded in the document and a 5th from Dennis (see below): 6.1.1 document-charset (charset) ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? and here is ISSUE 05 from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. Tom (See attached file: C.htm) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030410/b322230e/iso-8859-1QC-0001.html From PZehler at crt.xerox.com Fri Apr 11 15:03:06 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> Extended PWG Semantic Model(Document Object) Teleconference Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference will cover the Document Object. The document we will use is unchanged from last week. It is available at > The teleconference is two hours long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > Please take the time to review this document so we can finish this document up. The changed text and current issues are highlighted in the document. Send any issues you uncover to the SM mail list. The 5 known issues will be sent out under separate cover on Monday. > The agenda for the Semantic Model teleconference is : > > 1) Page turner review of the Document Object specification > 2) Next steps > > > Pete > > PS: Bob, Let me know if you can not host the Webex. > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > > Webex MEETING SUMMARY (Need comfirmation from Bob) > ------------------------- > Name: PWG Semantic Model > Date: 4/10/2003 > Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) > 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) > Meeting Number: 21366675 (Need comfirmation from Bob) > Meeting Password: pwg_sm (Need comfirmation from Bob) > Host: > Bob Taylor (HP) > > ___________________________________________________ > > > > > 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 > > From PZehler at crt.xerox.com Tue Apr 15 10:41:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:39 2009 Subject: SM> My responses to existing issues and a reminder to be ready for Th ursday Message-ID: All, I hope you all are reading the Document Object specification and preparing for Thursday's teleconference. The Document Object specification we will use for review is still: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB Please forward any new issues or comments to the list. Below are my opinions on the 5 outstanding issues. Pete __________________________________________________________________________ ISSUE 1: Since we agreed that this attribute isn't a hint, OK to make it CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document formats? Yes ISSUE 2: If the Printer supports this "document-digital-signature" Operation attribute and the value supplied by the client, the Printer MUST verify the signature according to the rule for that signature format. If the signature does not verify, then the Printer MUST either (1) ignore the signature or (2) put the job on hold and wait for human intervention, depending on implementation. The Printer gives no additional indication to the client. ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the correct behavior for the Printer if the digital signature doesn't verify? It should also be valid to abort the job. In any event the JobState and JobStateReasons should give an indication to the client. I think we will need a new JobStateReason such as InvalidSignature. How does this apply to documents within a job? Do we (1) ignore the signature and print the document and job, (2) Put the job on hold and wait for human intervention (and what about partially printed jobs?) (3) abort the document and continue printing the job (4) abort the document and job (once again what about partially printed jobs. This would be cleaned up if we mandated that document-signatures are evaluated at submission time. This may not be practical given the latency involved in contacting the certificate authority ISSUE 3: This Printer behavior is backwards compatible with a Printer that doesn't support the "digital-signature" attribute. However, if the Printer supports the "job-mandatory-attributes" attribute (see section 8.1.2) and the client supplies the "job-mandatory-attribute" Operation attribute with the 'digital-signature' keyword value, then the Printer MUST reject the job if the "digital-signature" attribute is supplied with a value that isn't supported by the Printer (or the Printer doesn't support the "digital-signature" attribute at all). Thus the client can force the Printer to reject a signed document for a signature technology that the Printer does not support. ISSUE 03: What if the digital signature is supported, but the signature fails verification by the Printer when "job-mandatory-attributes" identifies 'document-digital-signature'? The digital-signature should be treated as any other mandatory value with an invalid value. The job should be rejected, Document-signature and its value should be returned. This assumes the signature is evaluated at submission time. ISSUE 4: The values of the "document-format" and their corresponding "document-format-version" values will be kept in a flat text file on the PWG server for use by the PWG and CIP4. Implementers and implementations will be able to access this file at any time (at CD writing time, install time, vendor update time, and/or at power-up time, etc.). New values will be added to the flat file by its Maintainer after sending to the PWG list for a two week review whenever they are registered with or standardized by some recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4 buy-in to use the same flat file (which will require an additional field for the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for the file. The URL is: ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for the flat file? What is the formatting conventions for the flat file. Is it a PWG Schema of sorts? I never thought that schemas would be retrieved real time from printers and print clients. I assumed that the namespace would indicate the schema used. Clearly Printers would not need to access the schema since it already knows what it has implemented and the instance document would be valid for the schema. Print clients do not need to know all the possible semantic elements and values. It only needs the elements and values for the target Printer. The client would have built in support for the PWG schema to validate a Printer's instance document against. That leaves a general purpose web service client that will somehow be able to derive and present the semantic meaning behind the PWG schema in a user friendly way. (yeah there are a lot of those out there) ISSUE 5: from Dennis Carney: - I brought this up on the call, but I'll mention it again, since I'm not sure whether it was resolved. You sell a printer. You happen to have found out that some specific thing goes wrong when a user uses Powerpoint 2000 on Windows NT 4.0, such that your printer always messes up the printout. How do you specify this in document-format-details-implemented? And a much simpler issue on these same lines: why would *anyone*, ever, return any values for the document-creator-application-name-implemented or document-creator-application-version-implemented member attributes--why would anyone want to try to list all applications they support? Similarly for the two "os" member attributes--I might know I don't provide special drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a PDF file, *can* print to me from Macintosh. Even if there *were* some OSes I wanted to say I don't support (which seems doubtful), I have to do this by listing all *other* OSes? I guess in summary: I can see the use for the 5th-8th member attributes of document-format-details-implemented, but not for the 1st-4th. These seem most useful for transformation services such as a PSI Server. Printers would probably try and describe the document formats they support in the most generic way. A transformation service may want to be very explicit about the source document formats it is able to transform into printer ready formats. Tom 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 From dcarney at us.ibm.com Tue Apr 15 19:16:28 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:39 2009 Subject: SM> Integrate "-actual" attributes into the document object spec Message-ID: In "Appendix A: Change Log" of the IPP "-actual" attributes extension (ftp://ftp.pwg.org/pub/pwg/ipp/new_ACT/pwg-ipp-actual-attrs-latest.pdf), is the following text: Version 0.3, 16 December 2002, as a result of the PWG Semantic Model telecon, December 12, 2002: 1. Removed all references to the document object. Extending this concept to the document object will be done in the document object specification only. In this way, moving this specification forward on the standards track will not be held up. As far as I can see, the concept of the "-actual" attributes has not been extended to the Document object in the latest version of the Document Object spec. I assume we still want to do this--is there any feeling otherwise among the group? If we *do* want to do this, how to do it? In fact, I'm not sure in reading the spec (maybe I missed it?) that it is ever made clear that Document Template attributes have corresponding "xxx-default" and "xxx-supported" attributes--is that because all Document Template attributes are also Job Template attributes and as such have "xxx-default" and "xxx-supported" attributes by definition (from 2911)? However, the "-actual" attributes are a bit different. For every *Document Template* attribute, there would be a corresponding *Document Description* "-actual" attribute. This fact cannot, I don't think, be considered to be implied by 2911 or by the "-actual" spec (which as shown above does not even mention the document object). So: ISSUE 1: In chapter 7, OK to add a mention of the extension of the "-actual" concept to the Document object? ISSUE 2: In addition, does the way that "xxx-default", "xxx-supported", and "xxx-ready" apply to the Document object need to be made more clear? In addition, in Table 7, which lists all the Operation attributes, there are columns for "xxx-default" and "xxx-supported". I guess the concept is to extend the concept of "xxx-default" and "xxx-supported" to certain Operation attributes, instead of simply having those concepts apply to Template attributes. ISSUE 3: In this case, would we want to do the same for "-actual"s? This is a complicated situation, I believe, since we already have two cases: 1) For job-impressions, job-k-octets, and job-media-sheets, we already have the concept that these are copied to Job Description attributes and that these three (and *only* these three, I believe) can be updated by the printer to contain a "more accurate" (see 2911, section 4.3.17) value than was provided. So for these, they are sort-of their own "actual" attribute. 2) For document-format and document-format-version, we have created new attributes to essentially be "actual" values: document-format-detected and document-format-version-detected. We created the "detected" name to make sure it was not confused with the "-actual"s, since the "-actual" concept (as written) doesn't extend to Operation attributes. My personal vote is to *not* extend the concept of "-actual"s to Operation attributes, but I wanted to bring it up to see what others think. My reason for not extending them is to keep the concept "clean"--it only applies to Template attributes, not to all Template attributes, plus those Operation attributes that have currently been identified as having them. Also, extending the concept to Operation attributes conflicts somewhat with the situation in #1 above--2911 says that those three *are* some sort of "actual"s. If we extend the concept, do we deprecate that behavior? But then clients that don't implement the document object will no longer get the same "results" from servers that do implement it. Comments anyone? Dennis Carney IBM Printing Systems From dhall at hp.com Wed Apr 16 13:53:38 2003 From: dhall at hp.com (HALL,DAVID (HP-Vancouver,ex1)) Date: Wed May 6 14:04:39 2009 Subject: SM> Where to publish xsd / wsdl Message-ID: <6F2B25E1D54DA6428013E7FB7CD84EBF9FAC70@xvan01.vcd.hp.com> Hey All.. As we create new WSDL and XSD documents, and their "simple" counterparts, where should we publish the schemas? I would propose the following: * The schemas should have the EXACT SAME NAMESPACE - this is required if the "on the wire" envelopes should look the same. * The Full schemas should be published where they are currently being published: (http://www.pwg.org/schemas//) * The simple schemas should be published at: (http://www.pwg.org/schemas//) What do you think? Dave From hastings at cp10.es.xerox.com Wed Apr 16 20:56:07 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> Integrate "-actual" attributes into the document object s pec Message-ID: Dennis, Thanks for the comments. Briefly: 1. I agree with you that the Document Template attributes need to be clarified that they share the same "xxx-default" and "xxx-supported" Printer attributes with the corresponding Job Template attributes. 2. I agree that we want the spec to extend Document Template attributes to have corresponding OPTIONAL "xxx-actual" Document Description attributes. 3. I agree that we don't want to extend the -actual concept to the Operation attributes that have corresponding "xxx-default" and "xxx-supported" Printer Description attributes. See my detailed replies bracked by and below. Tom -----Original Message----- From: Dennis Carney [mailto:dcarney@us.ibm.com] Sent: Tuesday, April 15, 2003 16:16 To: sm@pwg.org Cc: Harry Lewis Subject: SM> Integrate "-actual" attributes into the document object spec In "Appendix A: Change Log" of the IPP "-actual" attributes extension (ftp://ftp.pwg.org/pub/pwg/ipp/new_ACT/pwg-ipp-actual-attrs-latest.pdf), is the following text: Version 0.3, 16 December 2002, as a result of the PWG Semantic Model telecon, December 12, 2002: 1. Removed all references to the document object. Extending this concept to the document object will be done in the document object specification only. In this way, moving this specification forward on the standards track will not be held up. As far as I can see, the concept of the "-actual" attributes has not been extended to the Document object in the latest version of the Document Object spec. I assume we still want to do this--is there any feeling otherwise among the group? Yes, I would think we should extend the Document object to have "xxx-actual" Job Description attributes. If we *do* want to do this, how to do it? In fact, I'm not sure in reading the spec (maybe I missed it?) that it is ever made clear that Document Template attributes have corresponding "xxx-default" and "xxx-supported" attributes--is that because all Document Template attributes are also Job Template attributes and as such have "xxx-default" and "xxx-supported" attributes by definition (from 2911)? Yes, the spec could be clearer that Document Template attributes are just the same as Job Template attributes and share the same "xxx-supported", "xxx-default", and "xxx-ready" Document Template Printer attributes with the Job Template attributes. However, the "-actual" attributes are a bit different. For every *Document Template* attribute, there would be a corresponding *Document Description* "-actual" attribute. This fact cannot, I don't think, be considered to be implied by 2911 or by the "-actual" spec (which as shown above does not even mention the document object). Agree, so need to add some statement to the Document Description Attributes section about there being corresponding "xxx-actual" Document Description attributes for each Document Template attribute. So: ISSUE 1: In chapter 7, OK to add a mention of the extension of the "-actual" concept to the Document object? Yes. ISSUE 2: In addition, does the way that "xxx-default", "xxx-supported", and "xxx-ready" apply to the Document object need to be made more clear? Yes. In addition, in Table 7, which lists all the Operation attributes, there are columns for "xxx-default" and "xxx-supported". I guess the concept is to extend the concept of "xxx-default" and "xxx-supported" to certain Operation attributes, instead of simply having those concepts apply to Template attributes. Yes. ISSUE 3: In this case, would we want to do the same for "-actual"s? But I don't think that we want to extend these Operation attributes that have "xxx-default" and "xxx-supported" to also have "xxx-actual" Document Description attributes. The one that we do have is "document-format-details-detected", so named since it isn't a -actual, just as we have done for the "document-format" operation attribute with "document-format-detected". This is a complicated situation, I believe, since we already have two cases: 1) For job-impressions, job-k-octets, and job-media-sheets, we already have the concept that these are copied to Job Description attributes and that these three (and *only* these three, I believe) can be updated by the printer to contain a "more accurate" (see 2911, section 4.3.17) value than was provided. So for these, they are sort-of their own "actual" attribute. True. 2) For document-format and document-format-version, we have created new attributes to essentially be "actual" values: document-format-detected and document-format-version-detected. We created the "detected" name to make sure it was not confused with the "-actual"s, since the "-actual" concept (as written) doesn't extend to Operation attributes. Yes. My personal vote is to *not* extend the concept of "-actual"s to Operation attributes, but I wanted to bring it up to see what others think. My reason for not extending them is to keep the concept "clean"--it only applies to Template attributes, not to all Template attributes, plus those Operation attributes that have currently been identified as having them. Also, extending the concept to Operation attributes conflicts somewhat with the situation in #1 above--2911 says that those three *are* some sort of "actual"s. If we extend the concept, do we deprecate that behavior? But then clients that don't implement the document object will no longer get the same "results" from servers that do implement it. I agree with you that we don't want to extend these Operation attributes that have "xxx-default" and "xxx-supported" to also have "xxx-actual" Document Description attributes. The one that we do have is "document-format-details-detected", so named since it isn't a -actual, just as we have done for the "document-format" operation attribute with "document-format-detected". Comments anyone? Dennis Carney IBM Printing Systems From hastings at cp10.es.xerox.com Wed Apr 16 21:20:25 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:39 2009 Subject: SM> document-creator-application-version ISSUE: For human or program consumption? Message-ID: The CIP4 System Behaviour and Interoperability WG reviewed the corresponding FileSpec attributes and pushed back on the equivalent of the "document-creator-application-version" Operation/Document Description attribute as being for human consumption. They thought it would be needed by consuming programs to know how to process the data for those formats which different versions had different semantics. The current spec is as follows: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)" When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "Winzip* 8.1", "Acrobat 5.0", and "Microsoft* Word 2000" as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. The following fix would keep the definitions alligned, if the PWG also agrees that this attribute is for program consumption: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for purpose of affecting the interpreting by the Printer for any formats for which the creator application version might have different semantics. They value MAY include build or service pack numbers. Examples: "8.1 (4331)" for Winzip* , "5.0.5 10/26/2001" for Acrobat*, "2000 (9.0.4119 SR-1)" for Microsoft* Word When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "8.1", "5.0", and "2000", respectively, as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. Comments? Tom From AMcCarthy at crt.xerox.com Thu Apr 17 13:00:42 2003 From: AMcCarthy at crt.xerox.com (McCarthy, Ann L) Date: Wed May 6 14:04:39 2009 Subject: SM> document-creator-application-version ISSUE: For human or program consumption? Message-ID: Tom, I agree with the change you are recommending. Because semantics can change significantly from one version of an application to another - I recommend upgrading this to a required attribute. Regards, Ann -------------------------------------------------------------------- Ann L. McCarthy XIG/SSTC Imaging Systems Architect Internal:8*221-8701 External: 585-231-8701 FAX: 585-265-8871 Mailcode: B128-30E -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 16, 2003 9:20 PM To: sm@pwg.org Subject: SM> document-creator-application-version ISSUE: For human or program consumption? The CIP4 System Behaviour and Interoperability WG reviewed the corresponding FileSpec attributes and pushed back on the equivalent of the "document-creator-application-version" Operation/Document Description attribute as being for human consumption. They thought it would be needed by consuming programs to know how to process the data for those formats which different versions had different semantics. The current spec is as follows: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for display to a human being, rather than being parsed by the Printer for purpose of affecting the interpreting by the Printer and so may also include the name of the application, as well as build or service pack numbers. Examples: "Winzip* 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "Microsoft* Word 2000 (9.0.4119 SR-1)" When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "Winzip* 8.1", "Acrobat 5.0", and "Microsoft* Word 2000" as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. The following fix would keep the definitions alligned, if the PWG also agrees that this attribute is for program consumption: 6.1.4.2 document-creator-application-version (text(127)) This OPTIONAL member Operation attribute identifies the version number of the application that created the document. The intent of this attribute is for purpose of affecting the interpreting by the Printer for any formats for which the creator application version might have different semantics. They value MAY include build or service pack numbers. Examples: "8.1 (4331)" for Winzip* , "5.0.5 10/26/2001" for Acrobat*, "2000 (9.0.4119 SR-1)" for Microsoft* Word When populating the "document-creator-application-version-implemented" member attribute of the "document-format-details-implemented" Printer Description attribute, some of the trailing information MAY be omitted, so that a substring match of the Printer's value with the value supplied by the client is sufficient for a match. For example, the Printer's value MAY be "8.1", "5.0", and "2000", respectively, as compared to the corresponding example values above that MAY be supplied by the client. If the client omits this member attribute or supplies a zero length string, that matches with any version. Similarly, the Printer's member attribute MAY be omitted or be a zero length string to indicate any. Comments? Tom From hastings at cp10.es.xerox.com Thu Apr 17 17:00:59 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:40 2009 Subject: SM> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From harryl at us.ibm.com Fri Apr 18 13:16:11 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:40 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: Message-ID: I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030418/fc1bc6f2/attachment-0001.html From imcdonald at sharplabs.com Fri Apr 18 14:34:17 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8B@mailsrvnt02.enet.sharplabs.com> Hi Michael, Tom's notes are actually incomplete. A conforming implementation MUST support at least one scheme (I suggested we RECOMMEND that 'http:'), but an administrator _at_run_time_ may choose to disable this feature by reconfiguring "reference-uri-schemes-supported". I proposed making this operation (Send-URI) mandatory. But only if ALL implementations MUST support at least one reference scheme and SHOULD support 'http:' (note that PSI servers MUST support 'http:' for the AddDocumentByReference method). I contend that the burden of adding a minimal HTTP client to an existing IPP-based printer is minimal. That's the question. Cheers, - Ira McDonald -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Friday, April 18, 2003 6:50 AM To: Hastings, Tom N Cc: sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec [My initial comments; I still haven't finished going through the document object spec, so I may have more comments early next week] Hastings, Tom N wrote: > ... > 1. Change the Send-URI operation and the corresponding > "reference-uri-schemes-supported" (1setOf uriScheme) Printer > Description attribute from OPTIONAL to REQUIRED for a Printer to > support. We agreed that a conforming implementation MAY have an > empty list for the "reference-uri-schemes-supported" Printer > Description attribute. So in essense you are just changing the status code from server-error-operation-not-supported to client-error-uri-scheme-not-supported. > Reason: PSI requires this operation (and has no OPTIONAL > attributes). Optional operations are much less likely to get support > by clients. It is best practice for an OPTIONAL extension > specification (such as this spec) to have no OPTIONAL operations, so > that user clients will receive the same level of service from all > Printer implementations that support this extension. This reasoning makes no sense since you are also saying that "reference-uri-schemes-supported" can be an empty list, which means that you still have no service from an implementation that doesn't really support Send-URI. Also, I still question the usefulness of Send-URI and Print-URI since security issues (authentication and access control) make implementation for non-trivial URIs difficult, if not impossible. > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... (I didn't get messages about either on the IPP list) > 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for > the "pdl-overrides-supported" Printer Description attribute (REQUIRED > in [rfc2911] section 4.4.28) to augment 'not-attempted', and > 'attempted' values. Also add a REQUIRED > ... OK, no problem with this. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Fri Apr 18 14:38:46 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From dcarney at us.ibm.com Fri Apr 18 16:45:20 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:40 2009 Subject: SM> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: My comments below marked by . A couple overall comments: 1) It seems like the Document object spec is becoming a grab-bag for all the ideas we come up with, whether they make sense as part of the Document object or not--the spec risks becoming a "Here's a bunch of things that we thought of that would make IPP cooler" spec. 2) I don't like the argument that we should not have OPTIONAL things in the Document object spec. Here are some reasons: - Even if we did what was proposed below, there would still be many, many OPTIONALs in the spec. If we really believe in our argument, those should all be REQUIRED, right? No? Why not? Oh, so there *is* a line between what should be OPTIONAL and what should be REQUIRED? Well, if there *is* a line, that sort of invalidates our argument that there shouldn't be any OPTIONALs. - The Document object spec has become more than just an extension. I think it is seriously rivaling RFC2911 in term of complexity (not in pages, but in complexity, with all those tables for example). This is NOT a criticism--having a Document object is a good idea and this spec is a very good one. But once a spec gets as complex as this one, it is unreasonable to consider it as just an extension that can have the "luxury" of not having any OPTIONALs. Dennis Carney IBM Printing Systems -------------------------------------------------- 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. PSI and IPP are different. Look at the PSI "Use Cases" from the Developers Guide--there are no "Joe is at his desk and wants to print to the printer down the hall" use cases. That's not the point of PSI. PSI is very web-oriented, and as such, it makes sense to print by reference. With IPP, printing by reference is really not mainline, so it should be optional. And what does Send-URI have to do with the document object? Ok, it is a way to send a document, but the Document object spec should describe the Document object, NOT try to redefine the way IPP works, imho. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. It seems to have been a long-standing tradition in IPP that the ability to do "Set"s is optional. I don't see why this should change now. What is so special about Set-Document-Attributes? Why aren't we mandating the other "Set" operations as well while we're at it? 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. I have less problem here since we aren't going to REQUIRED, but my last comment is valid here as well. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. The 'guaranteed' value: So you are only listing this value that already exists in another spec in the interest of trying to get the value to be "official" as quick as possible? I guess I can't argue with that, but it does seem a bit strange to me. I guess [ippsave] is going to be updated to refer to the Document object spec rather than define this new value? The "pdl-override-attributes-guaranteed" attribute: I agree that this was a shortcoming of IPP--the printer had no ability to say which attributes it could override and which it couldn't. I wonder about its applicability to the Document object, but... From hastings at cp10.es.xerox.com Fri Apr 18 19:15:18 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:40 2009 Subject: SM> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From hastings at cp10.es.xerox.com Fri Apr 18 22:10:36 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:40 2009 Subject: SM> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec Message-ID: Michael, Thanks for your comments. See my replies bracketed by ... Michael wrote: ... > 2. Change the Set-Document-Attributes operation from OPTIIOAL to > REQUIRED for a Printer to support. OK, however I think the state <-> status table (table 5) isn't right - what if you want to restart a job but print only 1 copy of the first document? (It's Table 6 in the April 7 spec, which regrettably was not announced on the IPP DL, only on the SM and PS DLs. Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip ) Yes, the transition table doesn't allow the client to modify a document with Set-Document-Attributes after the Document has 'completed', 'aborted', or 'canceled'. This same transition table is in the published RFC 3380 for the Set-Job-Attributes operation as well. The reason is that a completed, canceled, or aborted job/document should have the record of what was requested, for accounting and/or the help desk trying to figure out what went wrong. If you want to modify a job and resubmit it as in your example to change the number of copies and reprint: the idea is that the client does a Restart-Job (or Reprocess-Job) with the "job-hold-until" operation attribute supplied (see [RFC 2911] section 3.3.7, Restart-Job(. Then the client can modify it with Set-Document-Attributes while the job is in the 'pending-held' state. Then the client can release the modified job for printing with Release-Job (section 3.3.6). > 3. Change the Set-Job-Attributes operation from OPTIONAL to > RECOMMENDED for a Printer to support. > > Reason: To go along with the change in the conformance requirements > for the Set-Document-Attributes operation. However, don't REQUIRE > Set-Job-Attributes, since most of the interesting attributes are > document attributes, not job attributes. Hmm, I'll have to review the current spec some more, but I don't remember a section on Set-Job-Attributes in the March 24th draft. Set-Job-Attributes wasn't in the March 24th draft or the April 7 th draft. However, in proposing to REQUIRE the Set-Document-Attributes operation it seemed reasonsable to increase the requirements for the Set-Job-Attributes operation to at lease RECOMMENDED. But that is what we are asking for feed back on. So in order to conform to the IPP Document object spec, it is RECOMMENDED that the Printer also support Set-Job-Attributes. Any chance you can post a message to the *IPP* list whenever you put a new draft up please? Also, it might be helpful to know when you plan on doing telecons - it can be difficult to schedule the time, but I *do* attend them occasionally... Peter and I will make sure to announce IPP specs and telecons on the IPP DL too. The April 7 spec is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip There wont' be a new spec either. We're continuing the page by page. Please send any othre comments and/or join the next telecon, Thursday, April 24, 1-3 PM EDT: > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# We're also using webex: > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- The meeting number and password will be announced next week. ... From harryl at us.ibm.com Sat Apr 19 12:03:05 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:40 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CF8C@mailsrvnt02.enet.sharplabs.com> Message-ID: 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030419/ba7a2581/attachment-0001.html From imcdonald at sharplabs.com Sat Apr 19 16:57:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF8E@mailsrvnt02.enet.sharplabs.com> Hi Harry, 1) Support for modifying document object after submission is present in the FetchJobs interface that can OVERRIDE existing job or document attributes as the job flows from PSI Print Service to PSI Target Device. Whereas IPP Resubmit/Restart do NOT allow the attributes to be modified in the operation but require "job-hold-until" to be set to allow SUBSEQUENT use of the (OPTIONAL) Set-Job-Attributes. But what I meant below was: Send-Document and Send-URI are both OPTIONAL in IPP/1.1, but the AddDocumentByValue and AddDocumentByReference are REQUIRED in PSI/1.0. Since we are only just now adding Document objects to IPP, I simply propose that we offer PSI-equivalent capabilities in the protocol (for implementations of the Document object specification _only_). 2) I agree that PDL override is hard to implement (in _some_ PDLs), but what Tom and I have proposed is to disambiguate _which_ attributes (if any) can be guaranteed to successfully override the PDL. Seems to me like a good clarity enhancement to IPP. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Saturday, April 19, 2003 11:03 AM To: McDonald, Ira Cc: Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec 1. Help me out as to where PSI states this it is mandatory to support modification of a Document object after the job is submitted. 2. I support healthy alignment with FSG and I've been pushing for a job ticket interface to PSI. It's just... every time I ask for a show of hands regarding actual support for PDL-override the response is always lackluster. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "McDonald, Ira" Sent by: owner-sm@pwg.org 04/18/2003 12:38 PM To: Harry Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N" cc: ipp@pwg.org, ps@pwg.org, sm@pwg.org Subject: RE: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Hi Harry, (1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED. I'm merely suggesting equivalent functionality for the IPP Document object implementors. And yes it _is_ like IPPv2 - the Document object is the main thing missing from IPP/1.1. But this is just and extension. We're not mandating that all IPP/1.1 implementations support the Document object and operations. (2) The FSG expects to (using PAPI/1.0 API) convert any job ticket instructions to IPP job stream instructions. The job ticket support of PDL override is useless in the Free Standards Linux environment without the correspond IPP attributes. Cheers, - Ira -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Friday, April 18, 2003 12:16 PM To: Hastings, Tom N Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec I'm afraid we are 1. Over complicating the Document Object - This is really beginning to look like IPPv2 2. Risking lackluster adoption based on unnecessary mandatory operations Look at the premise behind (2), below. "... users should be able to modify a document object after the job is submitted...". This might be something nice for some users but there are simpler alternatives (such as canceling the job and resubmitting it).... that don't require an architectural mandate. As for (4) guaranteeing pdl-override... I've always been opposed to the concept of pdl-override... it's premise being that we can't keep ourselves from generating Postscript with embedded production instructions and even if we could there is a mass of Postscript (still) being used for interchange. This was not true when me made the error of specifying pdl-override in IPP and it is less true today. Separating content from production instruction via the use of a job ticket has always been the goal. That goal is now within reach. I think, then, it is time to consider deprecating pdl-override...certainly not elevating the "feature" by mandating further complexity. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/17/2003 03:00 PM To: sm@pwg.org cc: ps@pwg.org, ipp@pwg.org Subject: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Attendees: Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail Songer, Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?) At today's PWG Semantic Model telecon we did a page by page review of the IPP Document Object Spec in preparation for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip This mail note contains several significant changes in Printer conformance requirements that we agreed to for the indicated reasons. However, because of their significance, we agreed to post these changes to the DL for a two week comment period. Objectsion and comments on these changes are due by Friday, May 2, end of business. Silence will be interpreted as approval, so if you object, please send email. The other less significant agreements will be posted in a separate mail note as minutes. We resolved all of the issues and did the page by page review up to page 42 Table 7. We will continue the page by page at another two hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT) with the same version of the specification. Same call-in number and HP webex. Agreed to significant conformance requirements changes: 1. Change the Send-URI operation and the corresponding "reference-uri-schemes-supported" (1setOf uriScheme) Printer Description attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed that a conforming implementation MAY have an empty list for the "reference-uri-schemes-supported" Printer Description attribute. Reason: PSI requires this operation (and has no OPTIONAL attributes). Optional operations are much less likely to get support by clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED for a Printer to support. Reason: This is the Document object spec and users should be able to modify a Document object after the job is submitted. Optional operations are much less likely to get support by users clients. It is best practice for an OPTIONAL extension specification (such as this spec) to have no OPTIONAL operations, so that user clients will receive the same level of service from all Printer implementations that support this extension. 3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for a Printer to support. Reason: To go along with the change in the conformance requirements for the Set-Document-Attributes operation. However, don't REQUIRE Set-Job-Attributes, since most of the interesting attributes are document attributes, not job attributes. 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the "pdl-overrides-supported" Printer Description attribute (REQUIRED in [rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted' values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf type2 keyword) Printer Description attribute. The values indicate those Job Template and Document Template attributes for which the Printer guarrantees success in overriding the corresponding instruction in the PDL data. The values of this attribute returned in the Get-Printer-Attributes response MAY be colored by the "document-format" operation attribute supplied by the client in the request, if the Printer's guarrantee depends on the document format. A conforming Printer MAY return 'none' as the value. Reason: The IPPFAX needs the ability for the Printer to indicate which Job Template and Document Template attributes the Printer is able to guarantee success in overriding the PDL. Waiting for the Production Printing Set2 [ippsave] to be updated does meet the schedule for IPPFAX which is also trying to go out to last call. Also this extension is analoguous to our addition of "job-mandatory-attributes" to give a finer granularity to "ipp-attribute-fidelity" (boolean) operation attribute. Please send comments by Friday, May 2, 2003. Thanks, Tom From imcdonald at sharplabs.com Sun Apr 20 16:54:02 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> RE: [SPAM] RE: IPP> 4 significant proposed increases in conforman ce requirem ents for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF92@mailsrvnt02.enet.sharplabs.com> Hi Michael, Inline comments below. Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:11 PM To: McDonald, Ira Cc: Hastings, Tom N; sm@pwg.org; ps@pwg.org; ipp@pwg.org Subject: Re: [SPAM] RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec McDonald, Ira wrote: > ... > Tom's notes are actually incomplete. A conforming implementation > MUST support at least one scheme (I suggested we RECOMMEND that > 'http:'), but an administrator _at_run_time_ may choose to disable > this feature by reconfiguring "reference-uri-schemes-supported". Well, then you will likely find very few implementations. We've been working on Print-URI/Send-URI support for CUPS 1.2 and the authentication/security/performance issues are a real hassle for a real-world implementation. Also, you can be sure that any CUPS implementation of the spec WILL NOT enable print-by-reference by default for serious security reasons, and there will be extremely high barriers in place to limit how and where you can print from. > I proposed making this operation (Send-URI) mandatory. But only > if ALL implementations MUST support at least one reference scheme > and SHOULD support 'http:' (note that PSI servers MUST support > 'http:' for the AddDocumentByReference method). Is there any practical reason why PSI can't just require stricter requirements than the basic IPP mapping? It seems idiotic to require print-by-reference for IPP whose goals are different than PSI. _my_ goal is full-bandwidth application gateways between IPP and PSI. Everywhere that IPP doesn't have a feature at all (the out-of-band push in PSI's AddDocumentByPush) or has made a feature optional (PSI's AddDocumentByReference), the gateway will fail entirely. Note, PSI _is_ sending (over a TLS-secured channel) whatever username and password or certificate necessary to do the SMTP, IMAP, HTTPS, or whatever connection for the AddDocumentByReference, from the client embedded in the PSI Print Service or Target Device. If this is security nightmare for IPP, then the same applies to PSI - why is it so hard if the Print Service simply impersonates the end user? (I know this can't work if the end user's TLS certificate is restricted to access from a pre-configured source FQDN for the end user's system, but that problem _isn't_ soluble.) > I contend that the burden of adding a minimal HTTP client to an > existing IPP-based printer is minimal. That's the question. For a server that will only handle a single connection at a time, and for simple accesses without authentication, it can be implemented fairly easily. However, for any non-trivial implementation there are authentication, security, and performance issues that MUST be dealt with. Consider a typical web application like email which uses HTTP authentication, cookies, encryption, and probably some sort of host/ip-based session key; a print-by-reference approach is doomed to fail even if we can pass all of the required info to the IPP server, since it will somehow have to re-login and go to the right URL. Assuming it *does* work somehow, you need to securely manage this authentication information or risk compromising a remote system. I don't doubt that there is some minimal functionality that can be provided by Print-URI and friends, however the cost/benefit ratio is too high and I believe will hurt adoption of the document object spec. Well, print by reference is the main design center of PSI, so if it will hurt adoption of IPP Document objects, then it will equally hurt PSI adoption. Do you think PSI is in trouble?? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Sun Apr 20 16:44:03 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF91@mailsrvnt02.enet.sharplabs.com> Hi Michael, Actually scaling, centering, and cropping are all addressed for IPPFAX (extensions that will certainly migrate to general IPP/1.1 implementations). Cheers, - Ira -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Saturday, April 19, 2003 10:14 PM To: McDonald, Ira Cc: 'Harry Lewis'; Hastings, Tom N; ipp@pwg.org; ps@pwg.org; sm@pwg.org Subject: Re: SM> Re: IPP> 4 significant proposed increases in conformance requirements for the IPP Document object spec McDonald, Ira wrote: > ... > 2) I agree that PDL override is hard to implement (in _some_ PDLs), but > what Tom and I have proposed is to disambiguate _which_ attributes > (if any) can be guaranteed to successfully override the PDL. Seems > to me like a good clarity enhancement to IPP. PDL override is not even well-defined; what do you do with a PDF file that was formatted for a different media size? Scale it? Center it? Crop it? What constitutes an override??? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hastings at cp10.es.xerox.com Mon Apr 21 12:08:26 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:40 2009 Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From dcarney at us.ibm.com Mon Apr 21 12:11:46 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:40 2009 Subject: SM> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: This might be an awful idea, so feel free to shoot it down with vicious force... Based on the desire to have extensions that do not include OPTIONAL items, might it make sense to break the current Document object spec into two: - The "Base Document object" spec, which defines the basics of the Document object and has no OPTIONAL items: everything is mandatory. This would make interop a breeze, and would hopefully also encourage adoption since the spec would hopefully be relatively small. - The "Extended Document object" spec, containing all the currently OPTIONAL items. This spec *could* also make all the extensions mandatory (I would think that making absolutely *everything* mandatory would discourage adoption, however). The process of going through the current spec to determine which items are "Base" and which are "Extended" might also result in determining which items aren't "Document object" items at all. Dennis Carney IBM Printing Systems Mike Sweet To: "Hastings, Tom N" Sent by: cc: sm@pwg.org, ps@pwg.org, ipp@pwg.org owner-ipp@pwg.org Subject: Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec 04/19/03 08:54 PM Hastings, Tom N wrote: > ... > 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the > Jobs following the limit requested in a previous request. > > So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. This is a nice addition, but has ABSOLUTELY NOTHING TO DO WITH DOCUMENT OBJECTS. It doesn't belong here. If anything, you should put together a single, small spec that adds this functionality to Get-Jobs separately. A pain, but this single attribute is useful on its own. Also, you probably need to have a way to let the client know that this attribute is supported, e.g. "start-after-job-id-supported (boolean)"... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From dcarney at us.ibm.com Mon Apr 21 18:52:41 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:40 2009 Subject: SM> Re: IPP> 2 more significant proposed increases in conformance requirements for the IPP Document object spec Message-ID: I think that these ideas are good ones. However, I wonder why we didn't do anything about this before. In fact, in 2911, it is specifically called out that we purposely didn't handle this situation (2911, section 3.2.6.1: "There is no mechanism to allow for the next 'M' jobs after the first 'N' jobs."). Does anyone remember whether there was a good reason this issue was sidestepped? I've made 3 specific comments inline below, marked with . Dennis Carney IBM Printing Systems "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: IPP> 2 more significant proposed increases in conformance requirements for the IPP owner-ipp@pwg.org Document object spec 04/18/03 05:15 PM In summarizing the significant conformance requirement increases that we agreed to today in the review of the IPP Document Object spec review, I forgot two more: 1. Add a REQUIRED way to the Get-Documents operation for the client to get the Documents following the limit requested in a previous request. So add the "start-after-document-number" (integer (0:MAX)) Operation attribute. 2. Add a REQUIRED way to the Get-Jobs operation for the client to get the Jobs following the limit requested in a previous request. So add the "start-after-job-id" (integer (0:MAX)) Operation attribute. Please send any comments on these additions by Friday, May 2, COB. Here are the complete proposed text for these attributes and the updated "limit" Operation attribute: 1.1 Get-Jobs ([rfc2911] section 3.2.6) This REQUIRED Job operation returns requested attributes of either completed or not completed Jobs. The following (new) "start-after-job-id" (integer(0:MAX)) Operation attribute is defined which in combination with the "limit" operation attribute ([rfc2911] section 3.2.6) permits a client to request selected ranges of jobs: 1.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Jobs that a client will receive from the Printer even if "which-jobs" or "my-jobs" constrain which jobs are returned. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' jobs are returned in the Get-Jobs Response. If the client does not supply the "limit" attribute, the Printer responds with all applicable Jobs. However, if the client also supplies the "start-after-job-id" Operation attribute (section 4.2.2) with a value 'M', the Printer returns the N Jobs starting with the Job following the one with "job-id" = 'M'. We need to say what happens if job-id M is no longer in the list. I think the answer could be different for the two cases (non-completed vs. completed), making this a bit more complicated. If asking for *non-completed* jobs after job-id M, it is possible that M has completed since the client made the last call and is therefore no longer in the non-completed list. Unfortunately, this gets messy: 1) If M completed successfully, the printer should return the first N non-completed jobs (i.e. the same as if M hadn't been specified at all). 2) If M was canceled/aborted, it seems like the printer should ideally return the next job after M, *if* M hadn't been canceled/aborted. This extra attempt at correctness is, I guess, not really necessary, since the text below states that the caller can get strange results. Otherwise, if asking for *completed* jobs after job-id M, it is possible that M has been managed out of the completed list since the client made the last call. In *this* case, since completed jobs are returned in the opposite order of non-completed jobs, the printer should return an empty list. That is, since completed jobs are returned from newest to oldest, if M was managed out, jobs "after" (but actually printed before!) M are presumably also managed out, so there are actually no jobs "after" M in the completed list. This is the "correctly functioning" case of job-id M not being in the list, but there is also the "error" case where job-id M is just a bad value--it does seem strange to mandate that the printer return an empty list and success whenever the caller sends a bad "start-after-job-id" value. Maybe we want some new status-code: something like client-error-bad-start-id. Or we could possibly reuse client-error-gone or client-error-not-possible or some other existing status-code. Then there is just one answer for all the above cases: if M is not in the list, return an error and let the client decide what to do. 1.1.2 "start-after-job-id" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a job-id value 'M', the Printer MUST return Jobs starting with the Job that is after the one with "job-id" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return any Jobs with any "job-id" that meet the requested criteria (specified by "which-jobs" and/or "my-jobs", etc.). When the client steps through the jobs N at a time, the client MUST set the "start-after-job-id" attribute from the "job-id' of the last Job returned in a previous Get-Jobs response (rather than just adding 'N', since Printers MAY assign job-ids out or order). The client can detect when there are no more jobs when the Printer returns fewer jobs than requested by the "limit" Operation attribute ('N'). In the case when the last number of jobs returned is exactly N jobs, the client will make an extra request and receive no jobs back (still with a 'successful-ok' success code). However, this case still meets the criteria for no more Jobs since the number of Jobs returned (0) is less than "limit".. Note when the client steps through the Jobs supplying the "limit" and "start-after-job-id" Operation attributes in successive Get-Jobs requests, there are some race conditions which the client implementer needs to take into account: * For 'non-completed' Jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the Jobs in the order of the "expected time to complete" with the first expected to complete being returned first, etc. Because some Printers MAY: (1) process jobs out of order received, and/or (2) assign "job-id" in a non-monotonically increasing manner, occasionally a race condition MAY cause some jobs not be returned and some jobs MAY be returned more than once. The only way for a client to eliminate this race condition for 'not-completed' Jobs is to request all Jobs by supplying neither the "limit" nor the "start-after-job-id" Operation attribute. * For 'completed' jobs (see [rfc2911] section 3.2.6.2), the Printer MUST return the jobs in the order of "newest to oldest" to complete. Therefore, no jobs will be missed and/or doubly returned. 1.2 Get-Documents Operation This REQUIRED Job operation allows a client to retrieve the list of Document objects belonging to the target Job object. The client MAY also supply a list of Document attribute names and/or attribute group names. A group of Document object attributes will be returned for each Document object in the Job. This operation is similar to the Get-Document-Attributes operation (see section 3.5), except that this Get-Documents operation returns attributes from all Document objects contained in the Job object, instead of from a single selected Document object in the Job object. As with the Get-Document-Attributes operation the Printer MUST only return attributes that were submitted by a client when the Document object was created by the Create-Document, Send-Document, or Send-URI operations and possibly modified by the Set-Document-Attributes operation (see section 3.7). 1.2.1 Get-Documents Request The client submits the Get-Documents request to a Printer. The Get-Documents is similar to the Get-Jobs operations (see [rfc2911] section 3.2.6) except that there are no equivalents to the "which-jobs" and "my-jobs" Operation attributes. The following groups of attributes are part of the Get-Documents Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes as described in [rfc2911] section 3.1.4.1. Target: Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) or (2) the "job-uri" (uri) Operation attribute(s) which define the target Job object for this operation as described in [rfc2911] section 3.1.5. Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client as described in [rfc2911] section 8.3. 1.2.1.1 "limit" (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. It is an integer value that determines the maximum number of Documents that a client will receive from the Printer. If the client supplies the "limit" attribute with a value 'N' and the "start-after-document-number" attribute with a value 'M', the Printer returns the N Documents starting with the Document after the one with "document-number" = 'M'. The limit is a "stateless limit" in that if the value supplied by the client is 'N', then only the first 'N' Documents are returned in the Get-Documents Response. If the client does not supply the "limit" attribute, the Printer responds with all Documents in the Job. However, if the client also supplies the "start-after-document-number" Operation attribute (section 4.3.1.2) with a value 'M', the Printer returns the N Documents starting with the Document following the one with "document-number" = 'M'. Editorial: The above paragraph would flow better without the fourth sentence (the one starting "If the client supplies..."). 1.2.1.2 "start-after-document-number" (integer(0:MAX)): The client OPTIONALLY supplies this Operation attribute. The Printer MUST support this Operation attribute. If the client supplies this attribute with a document-number value 'M', the Printer MUST return Documents starting with the Document that is after the one with "document-number" = 'M'. If the client does not supply this attribute, the Printer assumes a '0' value which causes the Printer to return Documents starting with "document-number" = '1' (which is the first document in the Job). Note: canceled Documents (see section 3.7) are still returned, but deleted Documents (see section 3.8) are skipped over, since they don't exist (leaving gaps in the "document-number" sequence). Due to the fact that deleted Documents disappear, we have the same problem as discussed above: Document number M might no longer exist. The expected behavior for this should be similar to that decided upon for jobs, I would think; however, for Document objects, the "ideal" behavior would be to return the Documents starting with the first after Document M that hasn't been deleted. Unfortunately, this "pretend like M is still there" strategy doesn't really work as a general solution in the Get-Jobs case. Please send any comments on these additions by Friday, May 2, COB. Thanks, Tom From dcarney at us.ibm.com Mon Apr 21 19:14:18 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:40 2009 Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec Message-ID: I'm a bit confused: I had the (apparently flawed) impression that the plan was to deprecate, for a client, using the "last-document" operation attribute entirely--that is, say the "correct" way to say a job was done was to do Close-Job. If we do that, we will by definition deprecate the special case you're discussing below, right? Am I thinking of PSI or maybe SM? Since deprecation is only a suggestion, might it make sense to deprecate "last-document" entirely? (The Printer will still have to support it, but we're encouraging clients to move to Close-Job.) Do we want to make such a stand? Dennis "Hastings, Tom N" cc: ps@pwg.org, ipp@pwg.org Sent by: Subject: SM> 1 more significant proposed conformance change to the IPP Documen t object spec owner-sm@pwg.org 04/21/03 10:08 AM In going over my notes I discovered one more significant conformance changes proposed change for the IPP Document object from Thursday's April 17, telecon. This proposal will also go through the two-week comment period. 1. DEPRECATE the way a client can close a Job by supplying an empty Send-Document operation supplying the "last-document" = 'true' operation attribute for a Job created with Create-Job and any of (1) Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When the Printer accepts this no-data Send-Document operation with "last-document" = 'true' the Printer MUST set the still REQUIRED "last-document" Document Description attribute. Instead, the client SHOULD use the new Close-Job operation (which also sets the "last-document" Document Description attribute). The Printer MUST continue to support this method of closing a job with an empty Send-Document request for backward compatibility with existing clients. As with the other two mail messages on significant conformance requirements changes, I will not edit this comment into the spec until we reach consensus on Friday, May 1. Please send comments. Tom From PZehler at crt.xerox.com Tue Apr 22 10:19:38 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Extended PWG Semantic Model(Document Object) Teleconference Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will continue the review of the Document Object. We will continue to use the April 7 version of the document. It is available at The teleconference is two hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. Please take the time to review this document and comment on the outstanding issues so we can finish this document up. The changed text and current issues are highlighted in the document. Send any issues you uncover to the IPP mail list. The agenda for the Semantic Model teleconference is : 1) Continue page turner review of the Document Object specification 2) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY (Need confirmation from Bob) ------------------------- Name: PWG Semantic Model Date: 4/34/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From PZehler at crt.xerox.com Mon Apr 28 15:33:20 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Extended PWG Semantic Model(Document Object Final) Teleconference Message-ID: > All, > > This Thursday at 1pm EDT is the Semantic Model teleconference. This > week's teleconference should complete the review of the Document Object. > > We will continue to use the April 7 version of the document. It is > available at > > > The teleconference is two hours long. It will be run using phone and > Webex. Anyone that does not yet have Webex installed > should do that before Thursday. Information for the phone and > Webex are included below. > > The agenda for the Semantic Model teleconference is : > > 1) Finish discussion of any issues raised > > 2) Next steps > > > Pete > > PS: Bob, Let me know if you can not host the Webex. > > 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 > > > ________________________________________________________ > > Dial in Info: > Phone Number: (877) 776-6306 > (Phone Number for Xerox Employees: 8*594-0576) > PARTICIPANT PASSCODE: 437874# > ________________________________________________ > webex info: > We will also use an on line tool called webex, > if you have not used this before, setup up by > following the First Time Users instructions. > Do this in advance of the meeting. > > ------------------------- > FIRST TIME USERS > ------------------------- > For fully interactive meetings, including the ability > to present your documents and applications, a one-time > setup takes less than 10 minutes. Click this URL to set up now: > > http://hp.webex.com > > Then click New User. > ------------------------- > > On Thursday use: > https://hp.webex.com/join/ > > Then click join unlisted meeting. > Use the info below: > ------------------------- > > Webex MEETING SUMMARY (Need confirmation from Bob) > ------------------------- > Name: PWG Semantic Model > Date: 5/1 /2003 > Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) > 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) > Meeting Number: 21366675 > Meeting Password: pwg_sm > Host: > Bob Taylor (HP) > > ___________________________________________________ > > > > > 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 > > > From PZehler at crt.xerox.com Wed May 7 14:32:47 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> No teleconference this week. Message-ID: All, I am busy trying to break the Document Object document into 3 separate documents. I will get them out as soon as possible. The objective is to begin the review next week. 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 From PZehler at crt.xerox.com Fri May 9 13:05:53 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Page Overrides Spec Message-ID: All, Here is the link to the Page Overrides spec that hopefully will supercede the trial use PWG 5100.4. The Document Object specification will take care of overrides at the document level. (I should have that out soon.) This document covers page overrides. I also removed the non-override specific attributes out and will include them in one to the specifications being broken out from the Document Object specification. (I should have that out early next week) Take a look at it. It is 17 pages long including boilerplate. I have 2 issues identified. Any discussion of the specification should take place on the IPP list. Pete ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030509.pdf 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 From PZehler at crt.xerox.com Fri May 9 15:30:37 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> First breakout document for Document Object Message-ID: All, Here is my first installment of splitting the document object up into 3 documents. This document covers the Document Object extension to IPP. I would appreciate any comments since I may have cut out things that shouldn't be, left things in that should be out or made other changes that aren't correct. I hope to have the other main document out early next week that will cover the extensions that were added to the document object but are not critical to its definition, some things cut out of the old overrides document as well as things from IPPFAX and PSI. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509pdf.zip Also available is the doc version with and without revision marks. ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509docrev.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509doc.zip 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: Zehler, Peter > Sent: Friday, May 09, 2003 1:06 PM > To: PWG Semantic Model WG (E-mail); IPP Discussion List (E-mail) > Subject: Page Overrides Spec > > All, > Here is the link to the Page Overrides spec that hopefully will supercede > the trial use PWG 5100.4. The Document Object specification will take > care of overrides at the document level. (I should have that out soon.) > This document covers page overrides. I also removed the non-override > specific attributes out and will include them in one to the specifications > being broken out from the Document Object specification. (I should have > that out early next week) > > Take a look at it. It is 17 pages long including boilerplate. I have 2 > issues identified. Any discussion of the specification should take place > on the IPP list. > > Pete > > ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030509.pdf > > 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 > > From PZehler at crt.xerox.com Mon May 12 08:41:08 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Semantic Model Teleconference (New Document Specification) Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the new Document Object specification. The new Document Object Specification is the first of 3 specifications to be split out from the previous version. This specification is limited to the Document Object extension to IPP. The specification has been available since Friday. This is the first of the documents that has been broken out of the previous specification. There are currently 2 issues in this specification. Please raise any additional issues on the IPP mailing list. The teleconference is scheduled for one hour. If the conversation is productive we can extend the meeting up to 2 hours. The meeting will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509pdf.zip The agenda for the Semantic Model teleconference is : 1) Discuss the new specification a) Collect comments b) Raise issues c) Resolve issues 2) Plan how to drive this and associated documents to closure a) Relationship between this spec (a), the JobX spec (b), the futures spec (c), and the Override spec b) Schedule for closure and dependencies between specs c) Semantic Model and Schema updates d) Work items for Portland Face-to-Face 3) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 4/10/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From imcdonald at sharplabs.com Mon May 12 20:19:41 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> FW: WBMM> XML Schema of RFC 1759 - valid in XMLSPY Message-ID: <116DB56CD7DED511BC7800508B2CA53735CFC8@mailsrvnt02.enet.sharplabs.com> FYI, - Ira McDonald -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, May 12, 2003 8:12 PM To: wbmm@pwg.org Subject: WBMM> XML Schema of RFC 1759 - valid in XMLSPY Hi folks, I've just opened this machine translation of RFC 1759 (Printer MIB v1) with XML SPY and it validated without warnings as a free-standing schema (no imports required). The whole original RFC 1759 text (i.e., all the documentation, Cathy M) is captured in XML comments in this XML schema translation. The XML Schema (.xsd) is 157KB. The ZIP file is 23KB at: ftp://ftp.pwg.org/pub/pwg/wbmm/schemas/rfc1759-20030512.zip Now anyone can define some new grouping or subset grouping of elements from the Printer MIB by simply defining a second XML schema that imports the elements and type definitions from this base schema. I'm still working on the translation tool: 1) I want to add a final object 'Printer-MIB' that is a sequence of: a) all table elements; and b) all scalar elements (not columns in some table definition), which can be keyed by a local key that holds that _value_ of 'hrDeviceIndex' (but _not_ actually import 'hrDeviceIndex' from RFC 2790). Presently the highest containment is at the table level. 2) I want to enhance my translator to accept old-style SMIv1 MIBs as _input_ and translate them also to XML schema (most vendor private MIBs are still written in SMIv1 - some vendors have migrated to SMIv2). This may take some while (SMIv1 is both simpler and _different_ from SMIv2 - less information is available for machine translation). 3) I want to add a verbose symbol map feature to my translator. (The current verbose log covers only errors). 4) I need to test translate a number of other IETF standards track MIBs to catch corner cases in my translator. Comments are welcome. Cheers, - Ira McDonald High North Inc From PZehler at crt.xerox.com Mon May 19 14:25:52 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Semantic Model Teleconference (Document Specification) Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object specification. The Document Object Specification is the first of 3 specifications to be split out from the previous version. This specification is limited to the Document Object extension to IPP. I will post the document shortly. The teleconference is scheduled for one hour. If the conversation is productive we can extend the meeting up to 2 hours. The meeting will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030509pdf.zip The agenda for the Semantic Model teleconference is : 1) Discuss the new specification section by section a) Collect comments b) Raise issues c) Resolve issues 3) Next steps Pete PS: Bob, Let me know if you can not host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 5/22/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 21366675 Meeting Password: pwg_sm Host: Bob Taylor (HP) ___________________________________________________ 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 From PZehler at crt.xerox.com Mon May 19 15:36:37 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Semantic Model (doc obj) Teleconference (Complete/correct informa tion) Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will cover the Document Object specification. The Document Object Specification is the first of 3 specifications to be split out from the previous version. This specification is limited to the Document Object extension to IPP. The teleconference is scheduled for one hour. If the conversation is productive we can extend the meeting up to 2 hours. The meeting will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519pdf.zip Also available are the Word and rev versions and the meeting minutes that were used for the edits. ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519pdf.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519pdfrev.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519doc.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030519docrev.zip ftp://www.pwg.org/pub/pwg/ipp/new_DOC/Minutes-IPP-doc-object-20030501.pdf The agenda for the Semantic Model teleconference is : 1) Discuss the new specification section by section a) Collect comments b) Raise issues c) Resolve issues 3) Next steps Pete PS:Alan, Let me know if something comes up and you are unable to host the Webex. 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 ________________________________________________________ Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 5/22/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 22820422 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ 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 From PZehler at crt.xerox.com Tue May 27 13:09:50 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Page Override Review Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Page Overrides and replacing the deprecated 5100.4-2001. (The document contains 20 pages. The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) PWG Semantic Model & Schema status 2) Walk through issues and sections in the Override spec The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030527.pdf 3) Next Steps Pete PS: Alan, Let me know if there is a problem with you hosting the WebEx 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 Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: PWG Semantic Model Date: 5/22/2003 Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 22820422 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ From PZehler at crt.xerox.com Wed May 28 14:58:55 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Corrected info for Page Override Review telecon Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Page Overrides and replacing the deprecated 5100.4-2001. (The document contains 20 pages. The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. The agenda for the Semantic Model teleconference is : 1) PWG Semantic Model & Schema status 2) Walk through issues and sections in the Override spec The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030527.pdf 3) Next Steps 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 Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: Semantic Model Date: 5/29/2003 Time: 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 26605116 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ From imcdonald at sharplabs.com Fri May 30 19:09:05 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> PWG SM bindings for new RepertoireSupported element Message-ID: <116DB56CD7DED511BC7800508B2CA53735D00F@mailsrvnt02.enet.sharplabs.com> Hi Elliot, Friday (30 May 2003) Per our conversation this afternoon, below is the complete verbatim text of Appendix C for the CR spec. Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ C. Bindings to the PWG Semantic Model (Normative) To add the RepertoireSupported element to the PWG Semantic Model, the following XML Schema fragments SHALL be added to the specified files. Add the following simple type to the file 'PwgWellKnownValues.xsd': Add the following element reference to the file 'PrinterDescription.xsd' in the complex type "PrinterDescription": Add the following simple element to the file 'PrinterDescription.xsd' after the complex type "PrinterDescription": RepertoireWKV KeywordNsExtensionPattern From PZehler at crt.xerox.com Mon Jun 2 14:11:35 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Overrides Telecon *NEW NUMBER & PASSCODE* Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Page Overrides that is replacing the obsolete 5100.4-2001. (The document contains 20 pages. About 4 pages have changed significantly) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is : 1) Review each section of the spec with particular attention to the highlighted portions. 2) Next Steps & plan to get to Last Call The file for review is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030602.pdf Pete PS to Alan: Let me know if you can not host the Webex 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 Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Name: Semantic Model Date: 6/5/2003 Time: 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (DayLight Time) 10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time) Meeting Number: 26605116 Meeting Password: pwg_sm Host: Alan Berkema (HP) ___________________________________________________ From dcarney at us.ibm.com Thu Jun 5 09:30:03 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:40 2009 Subject: SM> Some comments on the Overrides spec Message-ID: All, Unfortunately, I am not going to be able to make the telecon today discussing the Overrides spec. I have sent Pete an email with some editorial updates to the Overrides spec, and also have some comments. My comments have to do with Table 2, "Job Template Attribute Override Scope". 1) I think some explanation of the "min" and "max" columns is needed. If nothing else, it needs to be made clear what the "order" of the scopes is. I assume that going from min to max it is: page, impression, sheet, document, job. I think an explanation would help in understanding why the values that are there have the values they do. 2) I assume that you are going to discuss today whether the values for the min and max scopes in the table are correct. I believe that the folks who have been very active in the Document object for a long time know this stuff much better than I do, but some of the values seem suspect to me. A few questions I had: a) "cover-back" and "cover-front" seem to me to be Document scope. b) Why would "feed-orientation" have different scopes than "media"? c) Without the Document object, it is actually possible to specify "insert-sheet", "output-bin", and "separator-sheets" at either the Document or the Job level? I hope these comments are not silly! 3) By the way, if by chance a long involved discussion ensues about what the values should be for each attribute, would it maybe be an alternative to replace the min and max columns with one single column that says simply whether the attribute is a valid Override or not? In theory, that is what this table is trying to convey, isn't it? 4) There are some rows that have a ** after the attribute name--is there a missing table footnote, or should the ** be deleted? 5) Is the reference for "pages-per-subset" correct? Dennis From PZehler at crt.xerox.com Mon Jun 9 15:17:04 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> JobX Telecon *NEW NUMBER & PASSCODE* Message-ID: All, This Thursday at 1pm EDT is the Semantic Model teleconference. This week's teleconference will be dedicated to IPP Jobx. I will post the document later today. This review will prepare the document for the Face-to-Face. The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is : 1) Discuss the remaining issue and reach consensus The following issue came up during the Review of the JOBX specification on June 4, which affects the Job Extension spec, the Document Object spec, and the PWG Semantic Model spec. For IPP there are the following Operation attributes that a client MAY supply in a Print-Job or Print-URI operation for specifying Document Attributes that do not have corresponding Description attributes defined until the Document Object specification: compression (type2 (keyword)) document-charset (charset) document-digital-signature (type2 (keyword)) document-format (mimeMediaType) document-format-details (1setOf (collection)) document-format-version (text(127)) document-message (text(MAX)) document-name (name(MAX)) document-natural-language (naturalLanguage) The preceding attributes are attributes of a Document. Therefore, unless the Document object is implemented, it is not possible for a client to completely determine what a client had submitted. As a consequence, it is also not possible for an application to completely archive a single document job using the Get-Job-Attributes operation. Furthermore FSG is using these attributes at the Job level in its APIs. When implementing the Document object, these same attributes can be supplied in the Send-Document and Send-URI operation as well. These attribute have slightly different semantics at the Job level than they do at the Document level. A solution for IPP JOBX (whether or not implementing the Document object) would be to define corresponding Job Description attributes for these specific operation attributes with the semantics that they are the defaults for the all the Document objects in the Job (even single document jobs created with Print-Job and Print-URI). These new Job Description attributes would be : compression-default (type2 (keyword)) document-charset-default (charset) document-digital-signature-default (type2 (keyword)) document-format-default (mimeMediaType) document-format-details-default (1setOf (collection)) document-format-version-default (text(127)) document-message-default (text(MAX)) document-name-default (name(MAX)) document-natural-language-default (naturalLanguage) These new attributes would be populated by the associated operational attribute if supplied. The file for telecon is the pdf file: ftp://www.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030609.pdf NOTE: This file does not include the above proposal for the remaining issue. However, given the time and my schedule I wanted to get something out. If possible I will get an update out later this week. The main issue and resolution proposal is explained fairly well above. Pete ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, June 12, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From imcdonald at sharplabs.com Tue Jun 17 22:55:21 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Prototype PWG Job Ticket schema - 17 June 2003 Message-ID: <116DB56CD7DED511BC7800508B2CA53735D05D@mailsrvnt02.enet.sharplabs.com> Hi folks, Tuesday (17 June 2003) Earlier today, I suggested that writing a PWG Job Ticket compatible with the FSG Job Ticket API was a small effort. Apropos, I wrote one... It's appended below and also posted at: ftp://ftp.pwg.org/pub/pwg/Semantic-Model/JobTicket-20030617.xsd Also below is a complete mapping from the JobTicketInfo object in the latest UML diagrams of the FSG Job Ticket API to objects and elements defined in the latest (0.93) PWG Semantic Model. My source documents for this mapping and prototype schema were: ftp://ftp.pwg.org//pub/pwg/fsg/jobticket/JTAPI_Diagrams/06Jun2003/ - file '03_JobTicketInfo.png' - JTAPI UML diagram ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mapping/ - file 'ippjdf-mapping-06-Jun-2003.pdf' - IPP/JDF mapping table Comments? Cheers, - Ira McDonald High North Inc PS - This PWG Job Ticket schema validates without errors with the (free) XSV schema validator from University of Edinburgh (see the W3C site under 'XML Schema' for the link for a Win32 self-installing download). ------------------------------------------------------------------------ FSG Job Ticket Element Mapping to PWG SM Object and Element ---------------------- ------------------------------------ -- JT API metadata -- jt-api-charset [not applicable] - JTAPI methods charset jt-api-version [not applicable] - JTAPI version -- JT instance metadata -- jt-author-name JobTicket.JTAuthorName - e.g., instance author "Ira McDonald" jt-version JobTicket.JTVersion - e.g., instance version "1.14" jt-syntax-version JobTicket.JTSyntaxVersion - e.g., PWG SM version "0.93" jt-type [not applicable] - hard-wired to PWG SM Job Ticket -- JT instance data -- jt-id JobTicket.JTId - e.g., identifier "uuid:blah..." jt-comment JobTicket.JTComment - e.g., "Weekly Accounts" jt-mandatory-attributes JobDescription.JobMandatoryElements - e.g., "media" jt-job JobTicket.Job and JobTicket.Document - contained job and document(s) jt-charset [XML 'encoding' attribute] - e.g., encoding="UTF-8" jt-length-units [not applicable??] - millimeters, points, etc. ------------------------------------------------------------------------ PWG Job Ticket schema - prototype 17 June 2003 - IEM NOTE: To use this schema you MUST include Job.xsd, Document.xsd, and all of their schema dependencies (see their documentation). Job Ticket Type definition Job Ticket instance author, e.g. 'Joe Smith' Job Ticket instance version, e.g. '1.14' PWG Semantic Model syntax version, e.g. '0.93' Job Ticket id, e.g. 'urn:uuid:f81d4fae-7dec-11d0-a765' Job Ticket comment, e.g. 'Weekly Accounts' Job Ticket Element From imcdonald at sharplabs.com Wed Jun 18 22:46:59 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> posted a photo of Ira McD Message-ID: <116DB56CD7DED511BC7800508B2CA53735D064@mailsrvnt02.enet.sharplabs.com> Hi, Claudia Alimpich asked yesterday if I would send a photo to further the rumor that I exist... Posted a JPEG photo (320KB) to the PWG FTP server at: ftp://ftp.pwg.org/pub/pwg/general/pictures/ira_2001.jpg I'm standing in front of my wife Nancy's 1956 International Harvester pickup truck with the blue EUPSAR (Eastern Upper Peninsula Search & Rescue) shield, on the grounds at 20th Annual Grand Marais Music & Arts Festival in August 2001. Cheers, - Ira McDonald High North Inc From imcdonald at sharplabs.com Thu Jun 19 19:57:33 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Background on "output-device-xxx" new attributes Message-ID: <116DB56CD7DED511BC7800508B2CA53735D065@mailsrvnt02.enet.sharplabs.com> Hi folks, Thursday (19 June 2003) Ever since IPP/1.0 (RFC 2566), the IPP Job object has had a Description attribute named "output-device-assigned" (the _single_ name of the print device assigned by the IPP Printer to process the job). Earlier today, during the Semantic Model session in Portland, Oregon we discussed the IPP Job Extensions proposals for adding: IPP Job Object -------------- "output-device-requested" - device name requested by client IPP Printer Object ------------------ "output-device-supported" - device name(s) supported by Printer "output-device-default" - device name of Printer default, if any, or _absent_ if no default is configured (so that "output-device-requested" will select from "output-device-supported") Note that DPA (ISO 10175) does NOT define a Printer attribute analogous to the JobX proposed "output-device-default" (which has odd semantics). I suggest that we abandon "output-device-default" and solve the problem. Cheers, - Ira McDonald High North Inc ------------------------------ Background: Below are the (more numerous and complex) corresponding attributes defined in DPA (ISO 10175, Document Printing Application): DPA Server Object (roughly analogous to PSI Print Service) ---------------------------------------------------------- "physical-printers-supported" - physical device(s) supported (multi-valued) - source attribute for (single-valued) IPP "output-device-supported" "physical-printers-ready" - physical devices currently ready (multi-valued) "logical-printers-supported" - logical printers supported (multi-valued) "logical-printers-ready" - logical printers currently ready (multi-valued) DPA Printer Object (analogous to IPP Printer _or_ IPP Device) ------------------------------------------------------------- "printer-realization" - logical, physical, or both "printer-associated-printers" - logical/physical associated printers "printers-ready" - logical/physical associated ready DPA Job Object (analagous to IPP Job) ------------------------------------- "printer-name-requested" - logical printer or physical device requested by client - source attribute for (single-valued) IPP "output-device-requested" "physical-printers-requested" - physical device(s) requested by client if "printer-name-requested" is logical "printers-assigned" - physical device(s) assigned by Printer (multi-valued and ordered) - source attribute for (single-valued) IPP "output-device-assigned" "printer-state-of-printers-assigned" - state of each assigned physical device (multi-valued and ordered) From PZehler at crt.xerox.com Mon Jun 23 10:43:44 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> PWG Semantic Model/Schema: Call for Intellectual Property Message-ID: All, This is a call for Patents that are essential to the IEEE ISTO PWG Semantic Model specification and associated Schema. Until the new process documents are finalized we will use the policy and a procedure of the IEEE since the ISTO is an affiliate. The IEEE call, is for essential Patents. The PWG specifies a 10 day call for Intellectual Property(IP). This call will close on July 8, 2003. If you believe you have IP essential to the PWG Semantic Model and/or PWG Schema you should file a Letter of Assurance (LOA). (http://www.pwg.org/chair/pwg-loa.doc ) If you have IP related to the PWG Semantic Model and/or PWG Schema you are encouraged to submit an LOA. If you know of a company that has IP in this space that does participate in the working group please let me know and I will send them the appropriate letter asking them to file an LOA. The completed form should be sent to: Secretariat, Printer Working Group c/o IEEE-ISTO 445 Hoes Lane Piscataway, NJ 08855 USA FAX (+651-318-7292) with a copy to Me. Thanks, Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030623/0dd42a8c/attachment-0001.html From PZehler at crt.xerox.com Wed Jun 25 07:50:30 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Next Semantic Model Teleconference will be on July 10 Message-ID: All, I am busy doing the edits from the Portland meeting (Document Object, Overrides, and JobX). I am also updating the Semantic Model and Schema with the Schema taking priority to get it posted this week(v0.95). Therefore there will be no teleconference this week. Next week is July 3rd and I doubt attendance would be high. I will get the next version of JobX out and hopefully get some email discussion going identifying issues and possible resolutions. The July 10th teleconference will, most likely, focus on JobX. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030625/b5aaed34/attachment-0001.html From PZehler at crt.xerox.com Fri Jun 27 12:41:17 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> PWG Semantic Model Schema v0.95 posted Message-ID: All, I have posted the PWG Schema v0.95 to the PWG website. Please let me know if you find any problem. I have only had time to make the edits and check the schema with XMLSPY v5.4. I got a new system while I was in Portland and have not yet put my development environment back together. I do not expect the structure of the schema to change. There may be minor changes to element/value names or a limited set of additions/deletions mostly associated with the JobX specification. We will determine the best way to handle these updates at a later time. There are 2 valid "views" of the PWG schema. These schemas include the subschema below. By including all the required schema these two schema are valid. The first is flat and the second hierarchical. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel.xsd The following schemas describe the Printer. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Printer.xsd http://www.pwg.org/schemas/sm/0.95/PrinterDescription.xsd http://www.pwg.org/schemas/sm/0.95/PrinterStatus.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingActual.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingDefault.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingReady.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingSupported.xsd The following schemas describe the Job. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Job.xsd http://www.pwg.org/schemas/sm/0.95/JobDescription.xsd http://www.pwg.org/schemas/sm/0.95/JobProcessing.xsd http://www.pwg.org/schemas/sm/0.95/JobStatus.xsd The following schemas describe the Document. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Document.xsd http://www.pwg.org/schemas/sm/0.95/DocumentDescription.xsd http://www.pwg.org/schemas/sm/0.95/DocumentProcessing.xsd http://www.pwg.org/schemas/sm/0.95/DocumentStatus.xsd The following schemas describe the Media. http://www.pwg.org/schemas/sm/0.95/MediaElements.xsd http://www.pwg.org/schemas/sm/0.95/MediaWellKnownValues.xsd The following schemas describe the types and elements common to Printers, Jobs and Documents. Note that PwgCommon.xsd individually valid. It has a dependency on MediaElements.xsd. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgWellKnownValues.xsd For those of you that use XMLSPY, here is a project file for v0.95. http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel095.spp I've also included a local version of the schema. In this version each schema includes the necessary files and is valid. http://www.pwg.org/schemas/sm/0.95/local-0.95.zip Though not part of the schema, I've included a master list of complex types and elements. http://www.pwg.org/schemas/sm/0.95/MasterListOfPwgSemanticElements.xsd Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030627/f9b2bf61/attachment-0001.html From PZehler at crt.xerox.com Fri Jun 27 14:48:41 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> PWG Semantic Model Schema v0.95 posted (Correction) Message-ID: All, Below is the correct announcement for the PWG Semantic Model Schema. The only two differences are the link to Local-0-95.zip has been fixed and the schemas in the zip file now have the appropriate namespace. (Sorry about that Bob) Pete All, I have posted the PWG Schema v0.95 to the PWG website. Please let me know if you find any problem. I have only had time to make the edits and check the schema with XMLSPY v5.4. I got a new system while I was in Portland and have not yet put my development environment back together. I do not expect the structure of the schema to change. There may be minor changes to element/value names or a limited set of additions/deletions mostly associated with the JobX specification. We will determine the best way to handle these updates at a later time. There are 2 valid "views" of the PWG schema. These schemas include the subschema below. By including all the required schema these two schema are valid. The first is flat and the second hierarchical. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel.xsd The following schemas describe the Printer. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Printer.xsd http://www.pwg.org/schemas/sm/0.95/PrinterDescription.xsd http://www.pwg.org/schemas/sm/0.95/PrinterStatus.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingActual.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingDefault.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingReady.xsd http://www.pwg.org/schemas/sm/0.95/ProcessingSupported.xsd The following schemas describe the Job. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Job.xsd http://www.pwg.org/schemas/sm/0.95/JobDescription.xsd http://www.pwg.org/schemas/sm/0.95/JobProcessing.xsd http://www.pwg.org/schemas/sm/0.95/JobStatus.xsd The following schemas describe the Document. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/0.95/Document.xsd http://www.pwg.org/schemas/sm/0.95/DocumentDescription.xsd http://www.pwg.org/schemas/sm/0.95/DocumentProcessing.xsd http://www.pwg.org/schemas/sm/0.95/DocumentStatus.xsd The following schemas describe the Media. http://www.pwg.org/schemas/sm/0.95/MediaElements.xsd http://www.pwg.org/schemas/sm/0.95/MediaWellKnownValues.xsd The following schemas describe the types and elements common to Printers, Jobs and Documents. Note that PwgCommon.xsd individually valid. It has a dependency on MediaElements.xsd. http://www.pwg.org/schemas/sm/0.95/PwgCommon.xsd http://www.pwg.org/schemas/sm/0.95/PwgWellKnownValues.xsd For those of you that use XMLSPY, here is a project file for v0.95. http://www.pwg.org/schemas/sm/0.95/PwgSemanticModel095.spp I've also included a local version of the schema. In this version each schema includes the necessary files and is valid. http://www.pwg.org/schemas/sm/0.95/Local-0-95.zip Though not part of the schema, I've included a master list of complex types and elements. http://www.pwg.org/schemas/sm/0.95/MasterListOfPwgSemanticElements.xsd Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030627/c4d9c80f/attachment-0001.html From PZehler at crt.xerox.com Tue Jul 1 13:14:40 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Remaining issue in Document object spec Message-ID: All, I did not capture the resolution (if any) on the following issue from Dennis Carney. ISSUE: I definitely believe that we need a "Document-equivalent" of job-collation-type. It would have different semantics, since the Job level semantics include the concept of documents, but I believe that since it is useful to know whether a Job is doing collated or uncollated copies, it would also be useful to know the same for Documents. Proposed resolutions: I disagree. If we did add a Document attribute, it would need to have the same value as at the Job Level, since you can't collate some documents and not collate other documents in the same job. We don't duplicate on the Document object other Job level attributes that apply to the job as a whole, such as "job-name", "job-hold", "job-priority", "job-finishing". Before I put the updated document I would like to get consensus. Please respond on the IPP list. Opinions? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030701/e22c41d2/attachment-0001.html From dcarney at us.ibm.com Tue Jul 1 17:35:19 2003 From: dcarney at us.ibm.com (Dennis Carney) Date: Wed May 6 14:04:40 2009 Subject: SM> Remaining issue in Document object spec Message-ID: Pete, It is easy for me to say :-), but I believe that we *did* resolve this issue, in favor of my proposal. The following appeared on the IPP mailing list: Maybe I'm not understanding. Can't you specify the "copies" attribute at the Document level? Therefore, you could have a Job that was made up of 1 copy of Document 1, 3 copies of Document 2, and 1 copy of Document 3, couldn't you? If you did, you might want to know if the 3 copies of Doc2 were collated or uncollated. I must be missing something--is there a section that would straighten me out? Now I see what you are suggesting. I suppose for consistency we could have a "collation-type" as a Document Template attribute. As long as it is clear that an implementation can implement the "job-collation-type" Job Template attribute without having to do the "collation-type" Document Template attribute (and vice versa). And I *thought* I remembered being on a call where Tom and Ira agreed with the concept. Anybody remember anything different? Dennis |---------+----------------------------> | | "Zehler, Peter" | | | | | | Sent by: | | | owner-sm@pwg.org | | | | | | | | | 07/01/03 11:14 AM| | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------| | | | To: "IPP Discussion List (IPP@pwg.org)" | | cc: "PWG Semantic Model WG (sm@pwg.org)" | | Subject: SM> Remaining issue in Document object spec | | | >------------------------------------------------------------------------------------------------------------------| All, I did not capture the resolution (if any) on the following issue from Dennis Carney. ISSUE: I definitely believe that we need a "Document-equivalent" of job-collation-type. It would have different semantics, since the Job level semantics include the concept of documents, but I believe that since it is useful to know whether a Job is doing collated or uncollated copies, it would also be useful to know the same for Documents. Proposed resolutions: I disagree. If we did add a Document attribute, it would need to have the same value as at the Job Level, since you can't collate some documents and not collate other documents in the same job. We don't duplicate on the Document object other Job level attributes that apply to the job as a whole, such as "job-name", "job-hold", "job-priority", "job-finishing". Before I put the updated document I would like to get consensus. Please respond on the IPP list. Opinions? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Jul 2 11:15:38 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Semantic Model (JobX) teleconference Message-ID: All, Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This week's Teleconference will be dedicated to IPP JobX. The document is available on the PWG server at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc (If someone could convert this to PDF I would appreciate it. I haven't found my copy of distiller to put on my new system yet.) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is: 1) Discuss the print-quality issue (see included notes below) 2) Discuss the document-xxx-supplied changes in JobX 3) Discuss the output-device resolution Pete PS: Bob let me know if there is a problem hosting Webex. ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, July 10, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Print Quality Issue: Last Tuesday during the PWG/FSG meeting in Portland we had a discussion about the IPP print-quality attribute and FSG's desire to add two new values, "economy" and "fine", where "economy" is lower than "draft" and "fine" is higher than "high". After some discussion we all pretty much decided that it is not possible to add these new values to the already existing "draft", "normal", and "high" values because of the current definitions of the existing values (high is defined as the highest quality and draft is defined as the lowest quality). It also seemed like what FSG wanted was a way to specify print optimization and not additional levels of print quality. The FSG working group met today, and based on the input from last Tuesday's meeting, we would like to propose the addition of a new attribute, called print-optimize, that is defined as follows: print-optimize (type2 keyword) This attribute refines the value specified by the print-quality attribute. The standard keyword values are: 'image': optimize for image clarity 'photo': optimize for photo clarity 'text': optimize for text clarity 'text-and-image': optimize for both text and image clarity 'save-toner': optimize for minimal toner usage 'speed': optimize for printing speed We would appreciate your feedback on this proposal including suggestions for additional values. If this proposal looks good, we would like to propose that it be included in the JobX Spec. If the print-optimize attribute is approved by PWG by the end of August, then we can propose that it be added to the JDF 1.2 Spec that is being finalized in early September. Thank you for your time and feedback. Claudia Alimpich IBM Printing Systems Division Boulder CO 303-924-4418 alimpich@us.ibm.com Response to Print Quality Issue: I understand the desire to avoid violating the semantics of the IPP attribute - but adding these enumerations to print-quality does not feel as objectionable to me as splitting a single semantic concept into two different attributes. If this is the precedent we take for extending the semantic model, I'm worried that we'll end up with an increasingly confusing and complex. I would rather we take the minor hit and fix the high & draft definitions in the semantic model than create another ~equivalent attribute with a whole bunch of special semantic rules (e.g. - what should the service do if print-quality=high and print-optimize=save-toner?). bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:bobt@hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030702/98d0b0ff/attachment-0001.html From PZehler at crt.xerox.com Mon Jul 7 12:59:36 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> PWG "latest" schema directory updated Message-ID: All, I have posted the "latest" PWG Schema to the PWG website. The "latest" version is nearly identical to v0.95. The main differences are the namespace and the schemas location on the website. Please let me know if you find any problem. There are 2 valid "views" of the PWG schema. These schemas include the subschema below. By including every required schema these two schemas are valid. The first is flat and the second hierarchical. http://www.pwg.org/schemas/sm/latest/PwgCommon.xsd http://www.pwg.org/schemas/sm/latest/PwgSemanticModel.xsd The following schemas describe the Printer. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/latest/Printer.xsd http://www.pwg.org/schemas/sm/latest/PrinterDescription.xsd http://www.pwg.org/schemas/sm/latest/PrinterStatus.xsd http://www.pwg.org/schemas/sm/latest/ProcessingActual.xsd http://www.pwg.org/schemas/sm/latest/ProcessingDefault.xsd http://www.pwg.org/schemas/sm/latest/ProcessingReady.xsd http://www.pwg.org/schemas/sm/latest/ProcessingSupported.xsd The following schemas describe the Job. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/latest/Job.xsd http://www.pwg.org/schemas/sm/latest/JobDescription.xsd http://www.pwg.org/schemas/sm/latest/JobProcessing.xsd http://www.pwg.org/schemas/sm/latest/JobStatus.xsd The following schemas describe the Document. Note that they are not individually valid. Documentation in each schema lists the dependency each has on other schema. http://www.pwg.org/schemas/sm/latest/Document.xsd http://www.pwg.org/schemas/sm/latest/DocumentDescription.xsd http://www.pwg.org/schemas/sm/latest/DocumentProcessing.xsd http://www.pwg.org/schemas/sm/latest/DocumentStatus.xsd The following schemas describe the Media. http://www.pwg.org/schemas/sm/latest/MediaElements.xsd http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd The following schemas describe the types and elements common to Printers, Jobs and Documents. Note that PwgCommon.xsd individually valid. It has a dependency on MediaElements.xsd. http://www.pwg.org/schemas/sm/latest/PwgCommon.xsd http://www.pwg.org/schemas/sm/latest/PwgWellKnownValues.xsd For those of you that use XMLSPY, here is a project file for "latest". http://www.pwg.org/schemas/sm/latest/PwgSmPostedLatest.spp I've also included a local version of the schema. In this version each schema includes the necessary files and is valid. http://www.pwg.org/schemas/sm/latest/Local.zip Though not part of the schema, I've included a master list of complex types and elements. http://www.pwg.org/schemas/sm/latest/MasterListOfPwgSemanticElements.xsd Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030707/f6436a8f/attachment-0001.html From imcdonald at sharplabs.com Wed Jul 9 11:46:26 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Request to discuss "print-optimize" first Message-ID: <116DB56CD7DED511BC7800508B2CA53735D097@mailsrvnt02.enet.sharplabs.com> Hi, Several FSG (Free Standards Group) people would like to attend the IPP Job Extensions (JobX) review tomorrow to discuss their recent proposal for a new "print-optimize" attribute - instead of additional values for "print-quality" (as Bob Taylor has recently suggested). To facilitate FSG participation, we request that "print-optimize" be discussed first, at the beginning of the telecon. Pete - please consider accomodating FSG participation this way. I'll forward replies to the FSG lists (also closed). Thanks, - Ira McDonald, member of FSG Architecture and Job Ticket WG's High North Inc From PZehler at crt.xerox.com Wed Jul 9 11:58:42 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Request to discuss "print-optimize" first Message-ID: Ira, After some very short status we will proceed with the print-quality discussion. Pete > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: Wednesday, July 09, 2003 11:46 AM > To: 'ipp@pwg.org'; 'sm@pwg.org' > Subject: SM> Request to discuss "print-optimize" first > > Hi, > > Several FSG (Free Standards Group) people would like to attend > the IPP Job Extensions (JobX) review tomorrow to discuss their > recent proposal for a new "print-optimize" attribute - instead > of additional values for "print-quality" (as Bob Taylor has > recently suggested). > > To facilitate FSG participation, we request that "print-optimize" > be discussed first, at the beginning of the telecon. > > Pete - please consider accomodating FSG participation this way. > I'll forward replies to the FSG lists (also closed). > > Thanks, > - Ira McDonald, member of FSG Architecture and Job Ticket WG's > High North Inc From hastings at cp10.es.xerox.com Wed Jul 9 19:08:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:40 2009 Subject: SM> Semantic Model (JobX) teleconference Message-ID: I've down loaded the .pdf for the .doc files as Peter requested for tomorrow's telecon. I've also put all four in the proper place in the IPP spec hierarchy as well under the new_JOBX arc (but I did not delete them from the Semantic_Model sub-tree): ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.doc Tom -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Wednesday, July 02, 2003 08:16 To: PWG Semantic Model WG (sm@pwg.org) Cc: 'Claudia Alimpich'; IPP Discussion List (IPP@pwg.org); printing-jobticket@freestandards.org; printing-driver@freestandards.org Subject: SM> Semantic Model (JobX) teleconference All, Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This week's Teleconference will be dedicated to IPP JobX. The document is available on the PWG server at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc (If someone could convert this to PDF I would appreciate it. I haven't found my copy of distiller to put on my new system yet.) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is: 1) Discuss the print-quality issue (see included notes below) 2) Discuss the document-xxx-supplied changes in JobX 3) Discuss the output-device resolution Pete PS: Bob let me know if there is a problem hosting Webex. ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, July 10, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ BM__MailAutoSigPeter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Print Quality Issue: Last Tuesday during the PWG/FSG meeting in Portland we had a discussion about the IPP print-quality attribute and FSG's desire to add two new values, "economy" and "fine", where "economy" is lower than "draft" and "fine" is higher than "high". After some discussion we all pretty much decided that it is not possible to add these new values to the already existing "draft", "normal", and "high" values because of the current definitions of the existing values (high is defined as the highest quality and draft is defined as the lowest quality). It also seemed like what FSG wanted was a way to specify print optimization and not additional levels of print quality. The FSG working group met today, and based on the input from last Tuesday's meeting, we would like to propose the addition of a new attribute, called print-optimize, that is defined as follows: print-optimize (type2 keyword) This attribute refines the value specified by the print-quality attribute. The standard keyword values are: 'image': optimize for image clarity 'photo': optimize for photo clarity 'text': optimize for text clarity 'text-and-image': optimize for both text and image clarity 'save-toner': optimize for minimal toner usage 'speed': optimize for printing speed We would appreciate your feedback on this proposal including suggestions for additional values. If this proposal looks good, we would like to propose that it be included in the JobX Spec. If the print-optimize attribute is approved by PWG by the end of August, then we can propose that it be added to the JDF 1.2 Spec that is being finalized in early September. Thank you for your time and feedback. Claudia Alimpich IBM Printing Systems Division Boulder CO 303-924-4418 alimpich@us.ibm.com Response to Print Quality Issue: I understand the desire to avoid violating the semantics of the IPP attribute - but adding these enumerations to print-quality does not feel as objectionable to me as splitting a single semantic concept into two different attributes. If this is the precedent we take for extending the semantic model, I'm worried that we'll end up with an increasingly confusing and complex. I would rather we take the minor hit and fix the high & draft definitions in the semantic model than create another ~equivalent attribute with a whole bunch of special semantic rules (e.g. - what should the service do if print-quality=high and print-optimize=save-toner?). bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:bobt@hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030709/eaa72de2/attachment-0001.html From imcdonald at sharplabs.com Thu Jul 10 11:49:56 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Semantic Model (JobX) teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA53735D09B@mailsrvnt02.enet.sharplabs.com> Hi Tom and Pete, Are we reviewing the '-rev.pdf' or the plain '.pdf' today? Will you be using the WebEx to edit the document? I picked up the '-rev.pdf', because it seemed most useful. Cheers, - Ira -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, July 09, 2003 7:09 PM To: Zehler, Peter; PWG Semantic Model WG (sm@pwg.org) Cc: 'Claudia Alimpich'; IPP Discussion List (IPP@pwg.org); printing-jobticket@freestandards.org; printing-driver@freestandards.org Subject: RE: SM> Semantic Model (JobX) teleconference I've down loaded the .pdf for the .doc files as Peter requested for tomorrow's telecon. I've also put all four in the proper place in the IPP spec hierarchy as well under the new_JOBX arc (but I did not delete them from the Semantic_Model sub-tree): ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.doc Tom -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Wednesday, July 02, 2003 08:16 To: PWG Semantic Model WG (sm@pwg.org) Cc: 'Claudia Alimpich'; IPP Discussion List (IPP@pwg.org); printing-jobticket@freestandards.org; printing-driver@freestandards.org Subject: SM> Semantic Model (JobX) teleconference All, Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This week's Teleconference will be dedicated to IPP JobX. The document is available on the PWG server at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc (If someone could convert this to PDF I would appreciate it. I haven't found my copy of distiller to put on my new system yet.) The teleconference is 2 hours long. It will be run using phone and Webex. Anyone that does not yet have Webex installed should do that before Thursday. Information for the phone and Webex are included below. NOTE: New Dial in number and passcode The agenda for the Semantic Model teleconference is: 1) Discuss the print-quality issue (see included notes below) 2) Discuss the document-xxx-supplied changes in JobX 3) Discuss the output-device resolution Pete PS: Bob let me know if there is a problem hosting Webex. ________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# ________________________________________________ webex info: We will also use an on line tool called webex, if you have not used this before, setup up by following the First Time Users instructions. Do this in advance of the meeting. ------------------------- FIRST TIME USERS ------------------------- For fully interactive meetings, including the ability to present your documents and applications, a one-time setup takes less than 10 minutes. Click this URL to set up now: http://hp.webex.com Then click New User. ------------------------- On Thursday use: https://hp.webex.com/join/ Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- Topic: PWG Semantic Model Date: Thursday, July 10, 2003 Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) Meeting number: 21366675 Meeting password: pwg_sm1! Host: Bob Taylor (HP) ___________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Print Quality Issue: Last Tuesday during the PWG/FSG meeting in Portland we had a discussion about the IPP print-quality attribute and FSG's desire to add two new values, "economy" and "fine", where "economy" is lower than "draft" and "fine" is higher than "high". After some discussion we all pretty much decided that it is not possible to add these new values to the already existing "draft", "normal", and "high" values because of the current definitions of the existing values (high is defined as the highest quality and draft is defined as the lowest quality). It also seemed like what FSG wanted was a way to specify print optimization and not additional levels of print quality. The FSG working group met today, and based on the input from last Tuesday's meeting, we would like to propose the addition of a new attribute, called print-optimize, that is defined as follows: print-optimize (type2 keyword) This attribute refines the value specified by the print-quality attribute. The standard keyword values are: 'image': optimize for image clarity 'photo': optimize for photo clarity 'text': optimize for text clarity 'text-and-image': optimize for both text and image clarity 'save-toner': optimize for minimal toner usage 'speed': optimize for printing speed We would appreciate your feedback on this proposal including suggestions for additional values. If this proposal looks good, we would like to propose that it be included in the JobX Spec. If the print-optimize attribute is approved by PWG by the end of August, then we can propose that it be added to the JDF 1.2 Spec that is being finalized in early September. Thank you for your time and feedback. Claudia Alimpich IBM Printing Systems Division Boulder CO 303-924-4418 alimpich@us.ibm.com Response to Print Quality Issue: I understand the desire to avoid violating the semantics of the IPP attribute - but adding these enumerations to print-quality does not feel as objectionable to me as splitting a single semantic concept into two different attributes. If this is the precedent we take for extending the semantic model, I'm worried that we'll end up with an increasingly confusing and complex. I would rather we take the minor hit and fix the high & draft definitions in the semantic model than create another ~equivalent attribute with a whole bunch of special semantic rules (e.g. - what should the service do if print-quality=high and print-optimize=save-toner?). bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:bobt@hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- From imcdonald at sharplabs.com Wed Jul 16 13:32:52 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Simple Device extension to Semantic Model Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0AE@mailsrvnt02.enet.sharplabs.com> Hi folks, Wednesday (16 July 2003) Proposal for a simple Device extension to the PWG Semantic Model: (1) Add a "PrinterRole" element to the Printer object, with legal values 'logical' (PSI Print Service, IPP Printer, etc.), 'physical' (PSI Target Device, SNMP Device, etc.), or 'logical-and-physical' (for consistency with ISO 10175 DPA's "printer-realization" attribute and a number of shipping vendor implementations of DPA). (2) Any 'logical' Printer object MAY support (e.g., via PSI's GetTargetDeviceElements) returning its 'best effort knowledge' of the elements of local surrogate 'physical' Printers (Devices). The URI of each local surrogate 'physical' Printer is formed by concatenating: (a) Any URI value of the "PrinterUriSupported" element (e.g., a 'pwg-psips:' value), and (b) a single dot '.', and (c) any value of the "OuputDeviceSupported" element. (3) A 'physical' Printer supports all standard Printer elements and MAY also support the "PrtXXX" elements extracted from the IESG-approved final draft of Printer MIB v2 (for the WBMM effort). Comments? Cheers, - Ira McDonald High North Inc PS - Mapping this PWG Semantic Model extension back to IPP is trivial. The latest IPP Job Extensions spec defines "output-device" (a client supplied Job Creation operation attribute) and "output-device-supported" (a Printer attribute that bounds the values of "output-device" and the existing "output-device-assigned", a Job Description attribute). An 'ipp:' value of "printer-uri-supported" on an IPP 'logical' Printer MAY be suffixed with a dot and a value of "output-device-supported" to form the URI of an IPP 'physical' Printer with "prt-xxx" attributes. Existing Get-Printer-Attributes and Set-Printer-Attributes operations MAY be used to manage and configure an IPP 'physical' Printer. No new IPP operations are required to add Device support to IPP. From imcdonald at sharplabs.com Wed Jul 16 15:58:15 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> RE: IPP> Simple Device extension to Semantic Model Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0B0@mailsrvnt02.enet.sharplabs.com> Hi Carl-Uno, As it's an OPTIONAL extension attribute, obviously if the IPP Printer Description attribute "printer-role" is NOT present, then the IPP Printer MUST behave (as in RFC 2911) as a 'logical' Printer (a service, not a device) - which is perfectly backwards compatible. Further, a client that doesn't understand "printer-role" will never ignore it erroneously in an IPP 'physical' Printer (a device), because that URL is NOT advertised - it's only constructed from the associated IPP 'logical' Printer's URL, as I proposed. OK? Cheers, - Ira McDonald High North Inc -----Original Message----- From: Carl [mailto:carl@manros.com] Sent: Wednesday, July 16, 2003 3:29 PM To: McDonald, Ira; sm@pwg.org; ipp@pwg.org Subject: RE: IPP> Simple Device extension to Semantic Model Ira, Unless you suggest this to be an mandatory element, what is the default assumption if it is not present? Carl-Uno Carl-Uno Manros 700 Carnegie Street #3724 Henderson, NV 89052, USA Tel +1-702-617-9414 Fax +1-702-617-9417 Mob +1-702-525-0727 Email carl@manros.com Web www.manros.com > -----Original Message----- > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of McDonald, > Ira > Sent: Wednesday, July 16, 2003 10:33 AM > To: 'sm@pwg.org'; 'ipp@pwg.org' > Subject: IPP> Simple Device extension to Semantic Model > > > Hi folks, Wednesday (16 July 2003) > > Proposal for a simple Device extension to the PWG Semantic Model: > > (1) Add a "PrinterRole" element to the Printer object, with legal values > 'logical' (PSI Print Service, IPP Printer, etc.), 'physical' (PSI > Target Device, SNMP Device, etc.), or 'logical-and-physical' (for > consistency with ISO 10175 DPA's "printer-realization" attribute > and a number of shipping vendor implementations of DPA). > > (2) Any 'logical' Printer object MAY support (e.g., via PSI's > GetTargetDeviceElements) returning its 'best effort knowledge' > of the elements of local surrogate 'physical' Printers (Devices). > The URI of each local surrogate 'physical' Printer is formed by > concatenating: > > (a) Any URI value of the "PrinterUriSupported" element (e.g., a > 'pwg-psips:' value), and > (b) a single dot '.', and > (c) any value of the "OuputDeviceSupported" element. > > (3) A 'physical' Printer supports all standard Printer elements and MAY > also support the "PrtXXX" elements extracted from the IESG-approved > final draft of Printer MIB v2 (for the WBMM effort). > > Comments? > > Cheers, > - Ira McDonald > High North Inc > > > PS - Mapping this PWG Semantic Model extension back to IPP is trivial. > > The latest IPP Job Extensions spec defines "output-device" (a client > supplied Job Creation operation attribute) and "output-device-supported" > (a Printer attribute that bounds the values of "output-device" and the > existing "output-device-assigned", a Job Description attribute). > > An 'ipp:' value of "printer-uri-supported" on an IPP 'logical' Printer > MAY be suffixed with a dot and a value of "output-device-supported" to > form the URI of an IPP 'physical' Printer with "prt-xxx" attributes. > > Existing Get-Printer-Attributes and Set-Printer-Attributes operations > MAY be used to manage and configure an IPP 'physical' Printer. No new > IPP operations are required to add Device support to IPP. > From imcdonald at sharplabs.com Thu Jul 17 12:12:17 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> Is there an SM call in one hour (17 July)?? Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0B3@mailsrvnt02.enet.sharplabs.com> Hi Pete and Tom, Is there an SM telecon today? Did I just miss the announcement? Cheers, - Ira From imcdonald at sharplabs.com Thu Jul 17 12:26:34 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> NO - Is there an SM call in one hour (17 July)?? Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0B6@mailsrvnt02.enet.sharplabs.com> Hi, Tom says Pete's on vacation and today's SM call is CANCELLED. Cheers, - Ira McDonald -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Thursday, July 17, 2003 12:12 PM To: 'sm@pwg.org' Subject: SM> Is there an SM call in one hour (17 July)?? Hi Pete and Tom, Is there an SM telecon today? Did I just miss the announcement? Cheers, - Ira From imcdonald at sharplabs.com Mon Jul 21 13:43:35 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0BA@mailsrvnt02.enet.sharplabs.com> Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From PZehler at crt.xerox.com Wed Jul 23 09:46:56 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Next PWG Semantic Model Meeting Will Be July 31 Message-ID: All, Given vacation and subsequent work load I will be unable to get the JobX updates sent out prior to this Thursday. I will get it out ASAP and be ready for a review next Thursday. The objective is to get to a stable version. Soon after that the PWG Semantic Model document will be brought up to date and sent out for a final review. Minor updates will also be made to the schema. The proposed agenda for the 31st will be as follows. 1) Quick Status 2) JobX Review a. Section by section with focus on recently changed text b. Any issues raised by the group 3) Schema changes and update plans 4) Schedule for Semantic Model stable document I will get the JobX document, updated agenda (given any suggestions from the group), and the details for the teleconference out later this week. Any issues should be sent to the SM mail list. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030723/8d0ea1b1/attachment-0001.html From PZehler at crt.xerox.com Mon Jul 28 11:45:53 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:40 2009 Subject: SM> Semantic Model (JobX) Teleconference Message-ID: All, This Thursday will be a review of the JobX specification. We will focus on the new and modified text. The text has been highlighted in turquoise. There are two issues highlighted in yellow. Please send out any issues or comments you have prior to Thursday so I can collect them and we can address them at the teleconference. The objective of this teleconference is to get to a stable version. Once this document is stable the PWG Semantic Model document will be brought up to date and sent out for a final review. Minor updates will also be made to the schema. The proposed agenda for the 31st will be as follows. 1) Quick Status 2) JobX Review a. Section by section with focus on recently changed text b. Any issues raised by the group 3) Schema changes and update plans 4) Schedule for Semantic Model stable document The JobX document is available on the PWG ftp server at < ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030728.pdf >. (There are also .doc, -rev.pdf and -rev.doc versions available in the same directory) The teleconference is 2 hours long. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. NOTE: New Webex site and possibly new software needs to be downloaded. Pete _____________________________________________________________ Meeting Date: 07/31/2003 Meeting Time: 1:00 PM Eastern (-4:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030728/2ededdec/attachment-0001.html From hastings at cp10.es.xerox.com Mon Jul 28 16:25:24 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:40 2009 Subject: SM> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Tue Jul 29 18:31:32 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:40 2009 Subject: SM> RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0CB@mailsrvnt02.enet.sharplabs.com> Hi Tom, I agree with your suggested rewording below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, July 28, 2003 4:25 PM To: McDonald, Ira; 'sm@pwg.org'; 'ps@pwg.org' Subject: RE: ISSUE 17: about server-error-too-many-jobs (0x050B) [comment on Document Object spec] Here are the current specifications for these two new error status codes from the current Document Object spec (circa June 3 with Dennis's comments added): 13.1 server-error-too-many-jobs (0x050B) The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer and/or the policy for this user or type of Job. The client SHOULD NOT try again later. DMC ISSUE17: I would have said SHOULD try again later, because resources might have been freed up. That is, I would have read "too many jobs" as a resource issue and "too many documents" as a policy issue. If we're saying not to try again, we should be clear that this error should only be returned if the problem is not expected to go away. 13.2 server-error-too-many-documents (0x050C) The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job and/or the policy for this user or type of Job. The client SHOULD NOT try again later. For server-error-too-many-jobs: "The client SHOULD NOT try again later" Dennis proposes: "The client SHOULD try again later." Michael proposes: Remove the policy possibility from the description and use 'client-error-not-possible' to mean a hard error and use MAY: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try again later. Looking at the status codes descriptions in [rfc2911], I'd suggest: The client has attempted to create a Job using any of the Job Creation operations which would exceed the capacity of the Printer. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. For server-error-too-many-documents: "The client SHOULD NOT try again later" Dennis proposes no change. Michael proposes the same change: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try again later. How about to align more with [rfc2911]: The client has attempted to create a Document using any of the Document Creation operations which would exceed the capacity of the Printer for this Job. The client MAY try the unmodified request again at some later point in time with an expectation that the capacity condition may have changed. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, July 21, 2003 10:44 To: 'sm@pwg.org'; 'ps@pwg.org' Subject: SM> FW: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hi, Michael Sweet's comments on 'server-error-too-many-jobs/documents'. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, July 21, 2003 11:09 AM To: Hastings, Tom N Cc: ipp@pwg.org Subject: IPP> Re: ISSUE 17: about server-error-too-many-jobs (0x050B) Hastings, Tom N wrote: > Michael, > > Do you have some input on this issue in the Document object spec about what > we should say about whether or not the client should try again (later) on > the proposed new server-error-too-many-jobs (0x050B): > > 22. About ISSUE17: > 13.1 server-error-too-many-jobs (0x050B) > The client has attempted to create a Job using any of the Job Creation > operations which would exceed the capacity of the Printer and/or the policy > for this user or type of Job. The client SHOULD NOT try again later. DMC > ISSUE17: I would have said SHOULD try again later, because resources might > have been freed up. That is, I would have read "too many jobs" as a > resource issue and "too many documents" as a policy issue. If we're saying > not to try again, we should be clear that this error should only be returned > if the problem is not expected to go away. > > Good ISSUE! It would be good to get Michael Sweet's input on this, since he > requested these error codes. I think that the status codes for both too-many-jobs and too-many-documents should be worded such that a client MAY try again later, not SHOULD or SHOULD NOT. If we want to differentiate hard and soft errors, I would recommend using server-error-not-possible to specify that it is not possible to create a new job or document (i.e. not-possible means don't retry, too-many-foos means you MAY retry...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com From PZehler at crt.xerox.com Mon Aug 4 12:27:58 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Return of the Semantic Model (JobX) Teleconference Message-ID: All, Given that only Xerox attended last week's JobX teleconference I will assume that everyone was on vacation and try again. I would also like to discuss the next phase for JobX, Overrides, Document Object, Semantic Model and its associated schema. This Thursday will be a review of the JobX specification. We will focus on the new and modified text. The text has been highlighted in turquoise. There are two issues highlighted in yellow. Please send out any issues or comments you have prior to Thursday so I can collect them and we can address them at the teleconference. The objective of this teleconference is to get to a stable version. Once this document is stable the PWG Semantic Model document will be brought up to date and sent out for a final review. Minor updates will also be made to the schema. The proposed agenda for the 31st will be as follows. 1) Status of JobX, Overrides, Document Object, Semantic Model and its associated schema a. Next steps 2) JobX Review a. Section by section with focus on recently changed text b. Any issues raised by the group 3) Schema changes and updates plans 4) Schedule for Semantic Model stable document The JobX document is available on the PWG ftp server at < ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030728.pdf >. (There are also .doc, -rev.pdf and -rev.doc versions available in the same directory) The teleconference is 2 hours long. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. NOTE: New Webex site and possibly new software needs to be downloaded. Pete _____________________________________________________________ Meeting Date: 08/07/2003 Meeting Time: 1:00 PM Eastern (-4:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030804/2621a794/attachment-0001.html From PZehler at crt.xerox.com Mon Aug 11 10:06:01 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> SM teleconference Message-ID: All, There will be no Semantic Model teleconference this week. . If we have enough content and interest we will hold a teleconference on August 21. I will be collecting comments from the PWG on moving the Document Object, Overrides and JobX to 'Prototype' maturity level. This week (when I'm not vacationing) I will be updating the Semantic Model and Schema. Bob Taylor has raised a few issues and I will send them out under separate cover. I have found several oversights and typing/paste errors that I will correct. I will also do a cross check with the three specifications listed above Please send ANY comments on the Semantic Model and Schema to this mail list. I would also like to get proposed agenda items for a teleconference on the 21st. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030811/2e9499ce/attachment-0001.html From PZehler at crt.xerox.com Mon Aug 11 11:42:34 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Current Schema issues Message-ID: All, Here are the issues I am currently aware of regarding v0.95 of the PWG Schema. If you have any comments on one of these issues please cut and paste the issue into a new mail note with a subject line of "Schema Issue #" where # is the number of the issue from the list below Thanks, Pete 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030811/919afa71/attachment-0001.html From PZehler at crt.xerox.com Tue Aug 19 13:02:00 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Next SM meeting will be 8/28/03 Message-ID: All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030819/c1e4d537/attachment-0002.html From PZehler at crt.xerox.com Tue Aug 19 13:02:00 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Next SM meeting will be 8/28/03 Message-ID: All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030819/c1e4d537/attachment-0003.html From PZehler at crt.xerox.com Thu Aug 28 09:30:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Updated "Latest" PWG Semantic Model Schema Message-ID: All, The "Latest" version (v0.96) of the PWG Semantic Model Schema has been posted on the PWG web site. (See "Semantic Model: Latest Version" under "Documents" on http://www.pwg.org/sm/ ) The list of differences is available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/ChangesToPwgSchemaV95.pdf . Any issues or comments on the latest schema should be sent to mailto:sm@pwg.org We will discuss the schema in the SM teleconference scheduled for Thursday August 28. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030828/8728a14b/attachment-0001.html From imcdonald at sharplabs.com Thu Aug 28 11:16:55 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:41 2009 Subject: SM> Next SM meeting will be 8/28/03 ??? Message-ID: <116DB56CD7DED511BC7800508B2CA537B00183@mailsrvnt02.enet.sharplabs.com> Hi Pete, I haven't seen any announcement this week of today's (8/28) SM telecon. Are we still having it, two hours from now? Cheers, - Ira McDonald High North Inc -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, August 19, 2003 1:02 PM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> 8/21 cancelled - Next SM meeting will be 8/28/03 All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 From alan.berkema at hp.com Thu Aug 28 12:06:48 2003 From: alan.berkema at hp.com (BERKEMA,ALAN C (HP-Roseville,ex1)) Date: Wed May 6 14:04:41 2009 Subject: SM> PWG Semantic Model Mtg. 8/28/03 Message-ID: <0806DAA43B1555479D53B58675D3468345844B@xrose01.rose.hp.com> On behalf of Peter Zehler: All, The next teleconference for the Semantic Model will be on August 28. My proposed agenda is 1) Status of JobX, Overrides and Document Object specifications 2) Status of PWG Semantic Model 3) Status of PWG Schema a. Changes b. Release update strategy and naming 4) Review issues raised (list included below) 5) Other items? 6) Next steps Please send me any additional items, comments or issues. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 You are invited to join a meeting on the PWG Semantic Model. Meeting details are listed below. Meeting Date: 08/28/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Meeting Details: ------------------------------- USA Toll Free Number: 877-707-6056 Participant Passcode: 437874 Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324 &p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current PWG Semantic Model/Schema Issues: 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual in JobProcessingActual - I pulled it out and it was fine in sqc Duplicate was supposed to be "OutputDeciceActual". Fixed in all sub-schemas. 2) the PWG SM schemas liberally use . The sqc apparently dislikes using ##any for the namepace wildcard if the xs:any is in a sequence with any other elements. If I switch this to , the problem goes away. I couldn't find any documentation on why this is a problem, but the sqc doesn't like it. Interestingly, it looks like you can add !both! and and it works fine - which in theory is the equivalent of . I did find this pattern in a sample online, but I haven't yet found any description on why is a real problem. It does, however, fail the sqc, and we think it may be what is causing some of the MS tools to give up on the SM schemas as well Actually the replacement for would be and . We do NOT want locally defined elements. All extensions MUST be fully qualified with the namespace to federate extensions to the schema. In all examples I have seen from the W3C they use '##any" for this type of extensibility. I still have not reinstalled all my XML tools yet or have not had time to try them on this issue. It seems to me that '##any' is exactly what we mean. 3) The PWG copyright on the schemas still says 2002. I'm assuming we need to roll this to 2003. Added ", 2003" to copyright notices 4) "JobPriority" need minimum value of '1' and maximum value of '100'. Added to "JobPriority" and "JobPriorityDefault" 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. Fixed 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and image MIME types Added 'application/vnd.pwg-xhtml-print+xml', image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. 7) "DocumentFormat" does not allow certain extension values. The "MimeExtentionPattern" SimpleType is not correct. As a quick fix I changed it to have a value of '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone with time to create a proper pattern describing MIME would be appreciated. 8) "PrinterStateReasons" should include the values 'AttentionRequired' and 'MarkerFailure'. Added them 9) "DocumentFormat" need the value 'unknown'. Added it 10) "JobAccountingId" should be "JobAccountingID". Fixed 11) How should we release the updated PWG Schema v0.95? Release as version 0.96 ____________________________________________________________________________ __ -----Original Message----- From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com] Sent: Thursday, August 21, 2003 11:37 AM To: 'Zehler, Peter' Subject: RE: PWG-ANNOUNCE> PWG Semantic Model Specification v0.90 Hi Pete, Is there a call today? I think I fell off of the reflector Thanks, Alan -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Thursday, August 21, 2003 8:03 AM To: PWG Announce (pwg-announce@pwg.org) Subject: PWG-ANNOUNCE> PWG Semantic Model Specification v0.90 All, The v0.90 of the PWG Semantic Model has been posted on the PWG web site. The document is available at ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20030820.pdf . The changes from the last review are listed below. The changes are primarily clean-up and incorporating the final changes in the JobX, Overrides and Document Object Specifications. Any issues or comments on the v0.90 specification should be sent to mailto:sm@pwg.org We will set the schedule for the final review of this specification in the SM teleconference scheduled for Thursday August 28. Pete Change Log: 8/20/03 PJZ cross checked tables and figures 8/15/03 PJZ Synched specification with [jobx], [override] and [doc-obj], 6/30/03 PJZ Added Overrides 4/21/03 PJZ Removed Tumble value from Sides 3/31/03 PJZ Cleaned up Naming of Classes, Elements and Values (? 4.1) and IPP Mapping (?14). Fixed case of element values in tables 3/26/03 PJZ Updated with changes from Document Object Specification 3/21/03 PJZ Added Character Repertoire 3/17/03 PJZ Removed PSI specific actions, corrected list of excluded elements in appendix B 3/16/03 TNH/PJZ Updated with the Document Object specifications. Added CloseJob that PSI is using. Renamed SendData to SendDocumentData to indicate what data. Prefixed JobId, JobPrinterUri, and JobUri Document Description elements with Document, so no Document attributes have a Job prefix. Added the following Document Description elements: DocumentContainerSummary, DocumentCreatorApplicationName, DocumentCreatorApplicationVersion, DocumentCreatorOsName, DocumentCreatorOsVersion, DocumentFormatDetected, DocumentFormatDeviceId, DocumentFormatVersion, DocumentIdUri, DocumentMessage, ElementNaturalLanguage. 1/29/03 PJZ Incorporated comments from Face to Face preparing document for Last Call. Updated abstract, introdusction and terminology sections. Added section to capture known semantic elements "waiting in the wings". Sorted status strings alphabetically. Added PSI specific actions and status strings. Corected Job & Doc state transition diagrams. Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030828/e14ed377/attachment-0001.html From PZehler at crt.xerox.com Thu Aug 28 11:54:52 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> REMINDER: Next SM meeting will be 8/28/03 Message-ID: > -----Original Message----- > From: Zehler, Peter > Sent: Thursday, August 28, 2003 11:29 AM > To: PWG Semantic Model WG (E-mail) > Subject: REMINDER: Next SM meeting will be 8/28/03 > > > > -----Original Message----- > From: Zehler, Peter > Sent: Tuesday, August 19, 2003 1:02 PM > To: PWG Semantic Model WG (sm@pwg.org) > Subject: Next SM meeting will be 8/28/03 > > All, > > The next teleconference for the Semantic Model will be on August 28. My > proposed agenda is > 1) Status of JobX, Overrides and Document Object specifications > 2) Status of PWG Semantic Model > 3) Status of PWG Schema > a. Changes > b. Release update strategy and naming > 4) Review issues raised (list included below) > 5) Other items? > 6) Next steps > > Please send me any additional items, comments or issues. > > Pete > > Peter Zehler > XEROX > Xerox Innovation Group > Email: PZehler@crt.xerox.com > Voice: (585) 265-8755 > FAX: (585) 422-7961 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > You are invited to join a meeting on the PWG Semantic Model. Meeting > details are listed below. > > Meeting Date: 08/28/2003 > Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) > > Instant Meeting Details: > ------------------------------- > USA Toll Free Number: 877-707-6056 > > Participant Passcode: 437874 > > Instant Net Conference Details: > ------------------------------- > Meeting Number: 747275324 > Meeting Passcode: PwgSm > Meeting Host: Pete Zehler > > Join Instructions for Instant Net Conference: > > REPEAT USERS > 1. Join the meeting now: > http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c > 2. Enter your name > 3. Agree to the Terms & Conditions and click Proceed. > > NEW USERS > 1. Go to http://www.mymeetings.com/nc/ > 2. Type in the Meeting Number > 3. Type in the Meeting Passcode (if one was provided) > 4. Choose "Conference" and click Proceed > 5. If you are a new user, click on "New Users" to check your system > and download the software and go back to Join Net Conference page > 6. Enter your name > 7. Agree to the Terms & Conditions and click Proceed. > Current PWG Semantic Model/Schema Issues: > 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual > in JobProcessingActual - I pulled it out and it was fine in sqc > Duplicate was supposed to be > "OutputDeciceActual". Fixed in all sub-schemas. > 2) the PWG SM schemas liberally use . The > sqc apparently dislikes using ##any for the namepace wildcard if the > xs:any is in a sequence with any other elements. If I switch this to > , the problem goes away. I couldn't find any > documentation on why this is a problem, but the sqc doesn't like it. > Interestingly, it looks like you can add !both! namespace="##other"/> and and it works fine > - which in theory is the equivalent of . I did > find this pattern in a sample online, but I haven't yet found any > description on why is a real problem. It > does, however, fail the sqc, and we think it may be what is causing some > of the MS tools to give up on the SM schemas as well > Actually the replacement for namespace="##any"/> would be namespace="http://www.pwg.org/schemas/sm/latest/"/> and namespace="##other"/>. We do NOT want locally defined elements. All > extensions MUST be fully qualified with the namespace to federate > extensions to the schema. In all examples I have seen from the W3C they > use '##any" for this type of extensibility. I still have not reinstalled > all my XML tools yet or have not had time to try them on this issue. It > seems to me that '##any' is exactly what we mean. > 3) The PWG copyright on the schemas still says 2002. I'm assuming we > need to roll this to 2003. > Added ", 2003" to copyright notices > 4) "JobPriority" need minimum value of '1' and maximum value of '100'. > Added to "JobPriority" and > "JobPriorityDefault" > 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation > 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. > Fixed > 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and > image MIME types > Added 'application/vnd.pwg-xhtml-print+xml', > image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. > 7) "DocumentFormat" does not allow certain extension values. > The "MimeExtentionPattern" SimpleType is not > correct. As a quick fix I changed it to have a value of > '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone > with time to create a proper pattern describing MIME would be > appreciated. > 8) "PrinterStateReasons" should include the values 'AttentionRequired' > and 'MarkerFailure'. > Added them > 9) "DocumentFormat" need the value 'unknown'. > Added it > 10) "JobAccountingId" should be "JobAccountingID". > Fixed > 11) How should we release the updated PWG Schema v0.95? > Release as version 0.96 > > From PZehler at crt.xerox.com Thu Aug 28 11:54:52 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> REMINDER: Next SM meeting will be 8/28/03 Message-ID: > -----Original Message----- > From: Zehler, Peter > Sent: Thursday, August 28, 2003 11:29 AM > To: PWG Semantic Model WG (E-mail) > Subject: REMINDER: Next SM meeting will be 8/28/03 > > > > -----Original Message----- > From: Zehler, Peter > Sent: Tuesday, August 19, 2003 1:02 PM > To: PWG Semantic Model WG (sm@pwg.org) > Subject: Next SM meeting will be 8/28/03 > > All, > > The next teleconference for the Semantic Model will be on August 28. My > proposed agenda is > 1) Status of JobX, Overrides and Document Object specifications > 2) Status of PWG Semantic Model > 3) Status of PWG Schema > a. Changes > b. Release update strategy and naming > 4) Review issues raised (list included below) > 5) Other items? > 6) Next steps > > Please send me any additional items, comments or issues. > > Pete > > Peter Zehler > XEROX > Xerox Innovation Group > Email: PZehler@crt.xerox.com > Voice: (585) 265-8755 > FAX: (585) 422-7961 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-25E > Webster NY, 14580-9701 > > You are invited to join a meeting on the PWG Semantic Model. Meeting > details are listed below. > > Meeting Date: 08/28/2003 > Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) > > Instant Meeting Details: > ------------------------------- > USA Toll Free Number: 877-707-6056 > > Participant Passcode: 437874 > > Instant Net Conference Details: > ------------------------------- > Meeting Number: 747275324 > Meeting Passcode: PwgSm > Meeting Host: Pete Zehler > > Join Instructions for Instant Net Conference: > > REPEAT USERS > 1. Join the meeting now: > http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c > 2. Enter your name > 3. Agree to the Terms & Conditions and click Proceed. > > NEW USERS > 1. Go to http://www.mymeetings.com/nc/ > 2. Type in the Meeting Number > 3. Type in the Meeting Passcode (if one was provided) > 4. Choose "Conference" and click Proceed > 5. If you are a new user, click on "New Users" to check your system > and download the software and go back to Join Net Conference page > 6. Enter your name > 7. Agree to the Terms & Conditions and click Proceed. > Current PWG Semantic Model/Schema Issues: > 1) ProcessingActual.xsd has a duplicate definition of OutputBinActual > in JobProcessingActual - I pulled it out and it was fine in sqc > Duplicate was supposed to be > "OutputDeciceActual". Fixed in all sub-schemas. > 2) the PWG SM schemas liberally use . The > sqc apparently dislikes using ##any for the namepace wildcard if the > xs:any is in a sequence with any other elements. If I switch this to > , the problem goes away. I couldn't find any > documentation on why this is a problem, but the sqc doesn't like it. > Interestingly, it looks like you can add !both! namespace="##other"/> and and it works fine > - which in theory is the equivalent of . I did > find this pattern in a sample online, but I haven't yet found any > description on why is a real problem. It > does, however, fail the sqc, and we think it may be what is causing some > of the MS tools to give up on the SM schemas as well > Actually the replacement for namespace="##any"/> would be namespace="http://www.pwg.org/schemas/sm/latest/"/> and namespace="##other"/>. We do NOT want locally defined elements. All > extensions MUST be fully qualified with the namespace to federate > extensions to the schema. In all examples I have seen from the W3C they > use '##any" for this type of extensibility. I still have not reinstalled > all my XML tools yet or have not had time to try them on this issue. It > seems to me that '##any' is exactly what we mean. > 3) The PWG copyright on the schemas still says 2002. I'm assuming we > need to roll this to 2003. > Added ", 2003" to copyright notices > 4) "JobPriority" need minimum value of '1' and maximum value of '100'. > Added to "JobPriority" and > "JobPriorityDefault" > 5) The "MediaSizeSelfDescribingNameWKV" element has an enumberation > 'om_large-photo_200x300' that should be 'om_large-photo_200x300mm'. > Fixed > 6) "DocumentFormatWKV" needs 'application/vnd.pwg-xhtml-print+xml' and > image MIME types > Added 'application/vnd.pwg-xhtml-print+xml', > image/g3fax', 'image/jpeg', 'imag/tiff'and 'image/tiff-fx'. > 7) "DocumentFormat" does not allow certain extension values. > The "MimeExtentionPattern" SimpleType is not > correct. As a quick fix I changed it to have a value of > '(\i|\d|\.)*/(\i|\d|\.\p{P})*'. I have not tested it yet. Anyone > with time to create a proper pattern describing MIME would be > appreciated. > 8) "PrinterStateReasons" should include the values 'AttentionRequired' > and 'MarkerFailure'. > Added them > 9) "DocumentFormat" need the value 'unknown'. > Added it > 10) "JobAccountingId" should be "JobAccountingID". > Fixed > 11) How should we release the updated PWG Schema v0.95? > Release as version 0.96 > > From hastings at cp10.es.xerox.com Fri Aug 29 20:05:45 2003 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:41 2009 Subject: SM> FW: Status of JobX, Overrides and Document Object specifications [from Pete Zehler] Message-ID: I've not seen this email from the PWG site, so I'm forwarding it to the sm@pwg.org, as Pete has requested. He'll be traveling next week with a new laptop. Tom -----Original Message----- From: Zehler, Peter Sent: Friday, August 29, 2003 12:51 PM To: PWG Semantic Model WG (sm@pwg.org) Subject> : Status of JobX, Overrides and Document Object specifications All, In the Semantic Model teleconference we discussed the status of the JobX, Overrides and Document Object specifications. They have been stable for quite some time. The requirements for entering into last call are that the specifications must be prototyped first. It was agreed that PSI satisfied this requirement for the Document Object and JobX. Overrides have been prototyped by Xerox on their DocuSP platform. This prototype was done independently of the Overrides specification and based on PWG 5100.4. However the implementation was greatly simplified and aligns with the Overrides specification. I will be generating clean versions of these three specifications. The only comments received so far are editorial in nature. I will post them on the PWG and formally announce the start of Last Call on the specifications. The Last Call will end on the Thursday (10/9/03) of our next PWG meeting. Once these documents have completed Last Call we will proceed with Last Call on the Semantic Model and Schema. Peter Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030829/145c5c2e/attachment-0001.html From PZehler at crt.xerox.com Fri Aug 29 12:51:28 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Status of JobX, Overrides and Document Object specifications Message-ID: All, In the Semantic Model teleconference we discussed the status of the JobX, Overrides and Document Object specifications. They have been stable for quite some time. The requirements for entering into last call are that the specifications must be prototyped first. It was agreed that PSI satisfied this requirement for the Document Object and JobX. Overrides have been prototyped by Xerox on their DocuSP platform. This prototype was done independently of the Overrides specification and based on PWG 5100.4. However the implementation was greatly simplified and aligns with the Overrides specification. I will be generating clean versions of these three specifications. The only comments received so far are editorial in nature. I will post them on the PWG and formally announce the start of Last Call on the specifications. The Last Call will end on the Thursday (10/9/03) of our next PWG meeting. Once these documents have completed Last Call we will proceed with Last Call on the Semantic Model and Schema. Peter Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030829/9acc4893/attachment-0001.html From PZehler at crt.xerox.com Wed Sep 17 09:13:34 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> FW: Sematic model and Media question Message-ID: All, Below is a Schema issue raised by Geoff Soord and my response. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 > -----Original Message----- > From: Geoff Soord [mailto:geoff_soord@sw2000.com] > Sent: Tuesday, September 16, 2003 12:25 PM > To: Zehler, Peter > Subject: Sematic model and Media question > > > > Peter, > > I have a few questions about the semantic model - please see the > attached bitmap. > > My understanding is for an insertSheet can contain 0 or more Isheets. An > ISheet can optional contain "Media" or "MediaCol". > > My first question is: From DocumentProcessing, should Media and MediaCol > be mutually exclusive as is the case for Isheet? Yes they should Is this a mistake in > the schema or I am missing the point somewhere along the way? Just one of the mistakes lurking in the schema > > Second question: If I wanted to know the media size for an inserted > sheet where should I look to find the information? Media or > MediaCol\MediaSize or MediaCol\MediaKey or MediaCol\MediaSizeName or do > a search of all of the above? It depends on how the client intends to specify the inserted sheet. The standard way to specify inserted sheets, or desired media, is "Media". The well known values for media are taken from PWG51001.1 and have well defined sizes. There are also standard ways to define custom sizes. "MediaCol" is used on higher end Printers. So you may use "MediaCol" to specify media on high end machines to precisely define the intent for you media selection. The "MediaCol" element contains "MediaSize" that is a numerical width and height dimension pair. Determining the available sizes for inserted sheets depends on how the client intends to specify the "InsertSheet". You could use the element "Printer.ProcessingSupported.DocumentProcessing.InsertSheetSupported.Media Supported" that contains a sequence of available "Media". Alternatively you could use the "Printer.ProcessingSupported.DocumentProcessing.InsertSheetSupported.Media ColSupported.MediaSizeSupported" that contains a sequence of available "MediaSize"s. As for what you would query to determine the available sizes that would depend on the protocol mapping. PSI uses the elements above. IPP does not distinguish "JobProcessing" From "DocumentProcessing" and uses "job- template". You would use "GetPrinterAttributes" to request "insert-sheet- supported.media-supported" or "insert-sheet- supported.MediaColSupported.media-size-supported". A protocol like UPnP does things quite differently and you would need to pull down the SCPD file and parse the SST to find the "MediaSize" element that contains an "allowedValueList" of "allowedValues". UPnP's "MediaSize" maps directly to the Semantic Model's "MediaCol.MediaSizeName" > > Last question: has the PWG got any working examples or well formed XML > documents? It maybe is would be useful to try working with some real > world example. I generate them to help me check the Schema. Perhaps we can post some to help with the Last Call of the Schema > > Thanks for you time in reading this. > > Regards, > Geoff From PZehler at crt.xerox.com Wed Sep 17 10:46:24 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, I have no plans for a Semantic Model Teleconference until October 2nd. There are currently 3 IPP/SM specifications out for Last Call. Those specifications are for JobX, Overrides, and the Document Object. Please send any comment you have on them to the IPP mailing list. I would like to have a list of issues before the start of the upcoming NYC meeting. The SM Web page update is almost complete. I will announce when the new page goes live. Please raise any issues you have with the Semantic Mode on the Semantic Model mail list. The latest update brings the MasterListOfSemanticElements.xsd up to date, makes the copyright date format consistent in all the files, and corrects some spelling and sorting errors. A running list of changes is maintained at http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf . The only outstanding Semantic Model/Schema issues I am aware of are: 1) The use of #any for element extensions 2) Fixing the patterns for keyword/name/mime extensions 3) The recent submission from Geoff Soord regarding "Media" and "MediaCol" being mutually exclusive. (Comments on the SM mail list welcome) The SM teleconference on October 2nd will be the prep meeting for the face to face. If anyone has need of a meeting before that please let me know and I can schedule one. I will send out the phone/webex information and proposed agenda the week before the October 2nd teleconference. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030917/02622c29/attachment-0001.html From imcdonald at sharplabs.com Wed Sep 17 11:09:48 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA537B001B3@mailsrvnt02.enet.sharplabs.com> Hi Pete, I'll be travelling on Thursday (2 October), so I'll miss your SM prep telecon - sorry about that. Cheers, - Ira -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Wednesday, September 17, 2003 10:46 AM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> Semantic Model Teleconference All, I have no plans for a Semantic Model Teleconference until October 2nd. There are currently 3 IPP/SM specifications out for Last Call. Those specifications are for JobX, Overrides, and the Document Object. Please send any comment you have on them to the IPP mailing list. I would like to have a list of issues before the start of the upcoming NYC meeting. The SM Web page update is almost complete. I will announce when the new page goes live. Please raise any issues you have with the Semantic Mode on the Semantic Model mail list. The latest update brings the MasterListOfSemanticElements.xsd up to date, makes the copyright date format consistent in all the files, and corrects some spelling and sorting errors. A running list of changes is maintained at http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf . The only outstanding Semantic Model/Schema issues I am aware of are: 1) The use of #any for element extensions 2) Fixing the patterns for keyword/name/mime extensions 3) The recent submission from Geoff Soord regarding "Media" and "MediaCol" being mutually exclusive. (Comments on the SM mail list welcome) The SM teleconference on October 2nd will be the prep meeting for the face to face. If anyone has need of a meeting before that please let me know and I can schedule one. I will send out the phone/webex information and proposed agenda the week before the October 2nd teleconference. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Sep 17 12:39:31 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Web Page Update Message-ID: All, The SM Web page (http://www.pwg.org/sm ) has been updated. (Thanks Gail) The page has links to the v0.95 and "Latest" schemas. The current version of the Semantic Model (v0.90 8/20/03) is linked in. Other updates include the registry of PWG Semantic Model elements, complex types, and keywords as well as the change log for the "Latest" schema. Please send any comments or issues on the Semantic Model and Schema to mailto:sm@pwg.org Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030917/a8b5bcfb/attachment-0001.html From PZehler at crt.xerox.com Thu Sep 25 11:44:25 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Teleconference/Last Call Message-ID: All, There will be no SM teleconference today. The next scheduled teleconference is October 2nd. The JobX, Overrides and Document Object specifications are in Last call. Please send any comments and/or issues to mailto:ipp@pwg.org and I will collect them for review next week and at the Face-to-Face. I will send out the teleconference information later this week. At this time we have 4 editorial comments on JobX, 16 editorial comments and 3 issues with Document Object and nothing on Overrides. (Thanks Jerry) Please take a look at the documents so we can complete Last Call on these and move on to finalizing the Semantic Model and Schema. I've included Jerry's comments and issues below. Thanks, Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf ) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf ) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf ) No comments -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030925/7c0e773b/attachment-0001.html From PZehler at crt.xerox.com Tue Sep 30 13:09:36 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Teleconference info (10/02) Message-ID: All, We will have a Semantic Model Teleconference this week. The teleconference details are below. The agenda is below. Please send out any comments/issues you wish to discuss during the teleconference by cob Wednesday. Current list of comments is appended below. Agenda: 1) Adjust agenda 2) Quick status of SM, Schema, JobX, Overrides and Document Object 3) Discuss upcoming face to face a. Tuesday SM (1/2 day pm) b. Thursday IPP extensions (1/2 day am) c. Thursday JobX (1/2 day pm) 4) Review any comments/issues a. Handle editorial first b. Discuss more involved comments and issues 5) Next steps Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 10/02/2003 Meeting Time: 11:50 AM CENTRAL TIME Instant Meeting Details: --------------------------- USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 Meeting Date: 09/30/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current list of comments.issues (9/30/03): Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf ) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf ) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf ) No comments -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20030930/a86f58e7/attachment-0001.html From imcdonald at sharplabs.com Tue Sep 30 13:28:54 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Teleconference info (10/02) Message-ID: <116DB56CD7DED511BC7800508B2CA537B001D9@mailsrvnt02.enet.sharplabs.com> Hi Pete, Your SM agenda doesn't agree with the agenda posted by Harry Lewis (Amy's note this morning was out-of-date). The agenda for next week (according to Harry's note last Friday, 26 Sept): PWG - NYC Meeting - 2003 Details ---------------------------------------------------------------------------- ---- October 6 - 10, 2003 Grand Hyatt New York, NY ---------------------------------------------------------------------------- ---- Schedule: WBMM Monday 9:30 - 5:00 pm PSI Tuesday 8:30 - 5:00 pm Plenary Wednesday 8:30 - Noon and 1:00 pm - 2:30 pm CR Wednesday 2:30 - 5:30 pm IPP Exts Thursday 8:30 am - Noon /JobX Semantic Thursday 1:00 - 5:00 pm Model(SM) Notify / Friday 8:30 - 1:00 pm Discovery BOF Location: Park Avenue at Grand Central Station New York, New York 10017 USA 1 212 883 1234 http://grandnewyork.hyatt.com/property/index.jhtml Registration: https://www.ieee-isto.org/pwg/registration.html Cheers, - Ira McDonald High North Inc PS - I'll probably have to miss the SM telecon this Thursday, due to a time conflict. Good luck. -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, September 30, 2003 1:10 PM To: PWG Semantic Model WG (sm@pwg.org); IPP Discussion List (IPP@pwg.org) Subject: SM> Semantic Model Teleconference info (10/02) All, We will have a Semantic Model Teleconference this week. The teleconference details are below. The agenda is below. Please send out any comments/issues you wish to discuss during the teleconference by cob Wednesday. Current list of comments is appended below. Agenda: 1) Adjust agenda 2) Quick status of SM, Schema, JobX, Overrides and Document Object 3) Discuss upcoming face to face a. Tuesday SM (1/2 day pm) b. Thursday IPP extensions (1/2 day am) c. Thursday JobX (1/2 day pm) 4) Review any comments/issues a. Handle editorial first b. Discuss more involved comments and issues 5) Next steps Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 10/02/2003 Meeting Time: 11:50 AM CENTRAL TIME Instant Meeting Details: --------------------------- USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 Meeting Date: 09/30/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current list of comments.issues (9/30/03): Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf) No comments From PZehler at crt.xerox.com Thu Oct 2 11:54:59 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> REMINDER/corrected: Semantic Model Teleconference info (10/02) Message-ID: All, We will have a Semantic Model Teleconference this week at the usual time. The teleconference details are below. The agenda is below. Bring any new comment/issues you have with you and email them to me if possible. The current list of comments is appended below. Agenda: 1) Adjust agenda 2) Quick status of SM, Schema, JobX, Overrides and Document Object 3) Discuss upcoming face to face a. Thursday(1/2 day am) IPP extensions, JobX b. Thursday (1/2 day pm) SM 4) Review any comments/issues a. Handle editorial first b. Discuss more involved comments and issues 5) Next steps Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Meeting Date: 10/02/2003 Meeting Time: 1:00 PM EASTERN (10:00 AM Pacific) Instant Meeting Details: --------------------------- USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 Meeting Date: 10/02/2003 Meeting Time: 1:00 PM Eastern (11:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. Current list of comments.issues (10/02/2003): Document Object (ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030908.pdf ) Editorial Comments: 1) Cover Page Line 26: The sentence about listing "all" of the attributes defined in other IPP specifications is probably not going to be accurate for very long.....if now.. 2) Page 9, line 311: The sentence should read.... "The semantics of the "document-state..."...(missing "the"). 3) Page 9, line 317-320: This paragraph needs to be reworded to state what the spec. is, not what it's proposed to be. 4) Page 13, line 403: The Job operatations that MUST NOT have any ..... (remove the word "that" ) 5) Page 14, line 413: The semantic of Fidelity on a Job are intended..... (The "semantics" of Fidelity....) 6) Page 15, line 446,447,451 The sentence "For example, such Job Template attributes as "job-priority"...." sounds odd.. (should read "For example, Job Template attributes such as .....) Same comment for line 447 and 451 "Printer MUST NOT copy down any..." (should be "Printer MUST NOT copy any Job Level attributes ...") 7) Page 21, line 653: ..it is only an empty job which is.... (recommend: "it is an empty job that is scheduled and...) 8) Page 24, line 777: ..Document object was submitted...(should be: ...Document object is submitted...) 9) Page 24, line 781: ..The only differences are that the Set-Job-Attibutes operation is... (should be: ..The only difference is that the ...operation is...) 10) Page 26, line 831,832: Formatting problem (unnecessary indentation....) 11) Page 26, line 833: First sentence worded funny. (suggest: Most Document Description attributes (see...)are NOT settable, i.e., they are defined to be READ-ONLY.) 12) Page 45, line 1258: First character space on that line is inadvertently highlighted... 13) Page 48, line 1305, 1309; Page 51, line 1389; Remove the names of the attribute at the beginning of the description. It's both unnecessary and inconsistent with the other attribute descriptions. (There are other descriptive paragraphs with the same problem..Page 58,59 14) Page 57, line 1571: First printed character (') is highlighted for no reason. 15) Page 65,66,67 Remove highlighted areas... lines 1776-1778, 1785-1787, 1795-1797, 1830, 1844-1846, 1847-1849. Page 66, line1828 (PrintBasic: 1.0) is in red.... 15) Page 75, line 2221,2224 Broken reference links..... Issues: 16) Page 14, line 430-431: After a strong conformance statement on the client, the printer is required to accept a non-conformant client operation..... (should be an error if the client supplies this attribute in a Doc Creation operation.. and the Printer should be allowed to flag it..) 17) Page 26, line 837-839: The note that provides guidance for future extensions doesn't belong in a specification, it belongs in the requirements doc of the future extension.....it'll get lost in this spec.... (suggest removing the note) 18) Page 28 Cancel-Document operation (and line 922) Question/Comment: What happens to the document DATA when a document is cancelled (assuming it's already been sent to the Printer)? Line 922 should read ....which only cancels the processing of the document, and doesn't delete the document object itself..... But it still says nothing about the document DATA. If the DATA is kept after a Cancel Document then there may be a security issue for the overly security conscious since this is the only way a client can request a document NOT be processed (then the data hangs around in the print spool for some unknown time). (Cancel Doc is mandatory for Printer, Delete Doc is optional) If the Data is not kept, what is the mechanism for the reprocess job operation if the data is expected to be there? JobX (ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030908.pdf ) Editorial Comments: 19) Page 13, footnote 5 Operation is partially italicized....(shouldn't be) 20) Page 34, line 1051 Need a little more informative test explaining what these are in addition too..... 21) Page 37, line 1162 the word "PrintBasic:1.0" is in red.... 22) See page 16 Lines 497 - 500 of the Sept. 8 Draft.... Action Item: (Tom and Ira): Propose a format for the file...... Did this get resolved and/or just missed in the final edits? Overrides (ftp://www.pwg.org/pub/pwg/ipp/new_EXC/wd-ippOverride10-20030910.pdf ) No comments -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031002/b8e33f34/attachment-0001.html From imcdonald at sharplabs.com Fri Oct 10 09:24:08 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:41 2009 Subject: SM> Correct PHONE # below - Friday: Notification / Discovery BOF, 8:3 0 - 1:00 pm EDT Message-ID: <116DB56CD7DED511BC7800508B2CA537B001F3@mailsrvnt02.enet.sharplabs.com> Hi, As planned, today's Friday PWG Discovery/Notification BOF turns out to be on the IEEE/ISTO PWG conference bridge at: 1-866-365-4406 Passcode: 2635888# Do not use the Xerox bridge in Tom's note below. Cheers, - Ira -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Thursday, October 09, 2003 3:07 PM To: pwg-announce@pwg.org Subject: PWG-ANNOUNCE> Order of Agenda for Friday: Notification / Discovery BOF, 8:30 - 1:00 pm EDT Ira informed me that I was wanted for the Notification part of the BOF. I have a meeting conflict for the time 9:00-10:30 AM EDT. So if you could reverse the order of the topics and cover Discovery first starting at 8:30 EDT, I'll join you at 10:30 AM for the Notification discussion. I have converted the Notification spec [ipp-ntfy] to an IEEE-ISTO format for someone to take over as editor. I've moved 'job-forwarded-operation-failed' keyword value for use with the "notify-events" attribute from the IETF Internet-Draft Job and Printer Administrative Operations - Set2 to [ipp-ntfy], so that Set2 can make progress in the IETF without any mention of [ipp-ntfy]. I've made notes that other TO DO things for [ipp-ntfy] include: 1. Add event 'job-state-change-only' for PSI. (no state reason changes) 2. Add 'job-progress-error' and 'job-progress-warning-or-error' events for IPPFAX, etc Tom Call-in details: USA Toll Free Number: 877-707-6056 VNET Number(Xerox): 8*594-0077 Participant Passcode: 437874 From PZehler at crt.xerox.com Wed Oct 15 12:25:43 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, There will be no teleconference this week. I would appreciate it if in its place you could send your votes for the Document Object, JobX and Overrides specifications. The announcements were sent out on the PWG Announce mailing list. I will let you know later this week if we will have a telecom next week on the SM and Schema. If anyone has any items for the teleconference please send them to me. Thanks, Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031015/d67ec41e/attachment-0001.html From PZehler at crt.xerox.com Tue Oct 21 10:49:42 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> No SM Telecon this week, Next on 10/30 Message-ID: All, I should be caught up by then and have stuff sent out this week. Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031021/81817fca/attachment-0001.html From PZehler at crt.xerox.com Mon Oct 27 11:40:07 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Semantic Model Teleconference Message-ID: All, This Thursday there will be a Semantic Model teleconference. The main objective of this teleconference is to begin the Last Call of the Semantic Model and associated schema. The proposed agenda for the 30th will be as follows. 1) Quick Status a. Results of vote on three IPP extension specifications b. Current state of Semantic Model and Schema 2) Walk through known issues a. Exact location of Media related elements within schema b. Pattern problems for extension of well known values (Schema only) c. Post some valid XML document to assist in Last Call d. Other issues 3) Next steps The Latest (i.e. October 24, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031024.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.96) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 10/30/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031027/722c818b/attachment-0001.html From PZehler at crt.xerox.com Wed Nov 5 09:18:09 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> No SM Telecon this week...keep reviewing spec and raising those Last Call issues Message-ID: Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031105/f4523632/attachment-0001.html From PZehler at crt.xerox.com Mon Nov 10 14:00:45 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> No SM teleconference this week Message-ID: Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031110/8ff064c2/attachment-0001.html From PZehler at crt.xerox.com Mon Nov 10 14:24:46 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> JobStateReasons issue Message-ID: All, The values in the Semantic Model document do not line up with those in the Schema or in the referenced specifications. In order to keep the mapping clean and to maintain alignment with JDF I propose the following changes in the JobStateReasons keywords entry on page 44 of the Semantic Model spec (JobStateReasons entry in Job Element Table). Below are the corrected values. I also need to update the reference column to include JobX and Prod-Print. Current SM value -> Corrected SM Value __________________________________ CanceledAtDevice -> JobCanceledAtDevice CanceledByOperator -> JobCanceledByOperator CanceledByUser -> JobCanceledAtUser CompletedSuccessfully -> JobCompletedSuccessfully CompletedWithErrors -> JobCompletedWithErrors CompletedWithWarnings -> JobCompletedWarnings Incoming -> JobIncoming Interpreting -> JobInterpreting Outgoing -> JobOutgoing Printing -> JobPrinting Queued -> JobQueued QueuedForMarker -> JobQueuedForMarker Transforming -> JobTransforming Comments? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031110/c577edb3/attachment-0001.html From imcdonald at sharplabs.com Mon Nov 10 20:11:38 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:41 2009 Subject: SM> JobStateReasons issue Message-ID: <116DB56CD7DED511BC7800508B2CA537B0022F@mailsrvnt02.enet.sharplabs.com> Hi Pete, I agree with your proposed changes - clean 'em up! Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Monday, November 10, 2003 2:25 PM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> JobStateReasons issue All, The values in the Semantic Model document do not line up with those in the Schema or in the referenced specifications. In order to keep the mapping clean and to maintain alignment with JDF I propose the following changes in the JobStateReasons keywords entry on page 44 of the Semantic Model spec (JobStateReasons entry in Job Element Table). Below are the corrected values. I also need to update the reference column to include JobX and Prod-Print. Current SM value -> Corrected SM Value __________________________________ CanceledAtDevice -> JobCanceledAtDevice CanceledByOperator -> JobCanceledByOperator CanceledByUser -> JobCanceledAtUser CompletedSuccessfully -> JobCompletedSuccessfully CompletedWithErrors -> JobCompletedWithErrors CompletedWithWarnings -> JobCompletedWarnings Incoming -> JobIncoming Interpreting -> JobInterpreting Outgoing -> JobOutgoing Printing -> JobPrinting Queued -> JobQueued QueuedForMarker -> JobQueuedForMarker Transforming -> JobTransforming Comments? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Nov 12 13:27:03 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> JobStateReasons issue Message-ID: Bob, The change was not intentional. It was a cut and paste error in the mail note. The actual values are derived directly from the IPP specs. The correct values are CanceledByUser -> JobCanceledByUser CompletedWithWarnings -> JobCompletedWithWarnings I cut and pasted the full contents of JobStateReason's "Description (values)" entry below. Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 Provides additional information about this Job's current state. (Keywords: AbortedBySystem, CompressionError, DigitalSignatureDidNotVerify, DigitalSignatureTypeNotSupported, DocumentAccessError, DocumentFormatError, ErrorsDetected, JobCanceledAtDevice, JobCanceledByOperator, JobCanceledByUser, JobCompletedSuccessfully, JobCompletedWithErrors, JobCompletedWithWarnings, JobDataInsufficient, JobDigitalSignatureWait, JobHoldUntilSpecified, JobIncoming, JobInterpreting, JobOutgoing, JobPasswordWait, JobPrinting, JobQueued, JobQueuedForMarker, JobRestartable, JobResuming, JobSavedSuccessfully, JobSaveError, JobSaving, JobScheduling, JobSpooling, JobStreaming, JobSuspended, JobSuspendedByOperator, JobSuspendedBySystem, JobSuspendedByUser, JobSuspending, JobTransforming, None, PrinterStopped, PrinterStoppedPartly, ProcessingToStopPoint, ProofPrintWait, QueuedInDevice, ResourcesAreNotReady, ResourcesAreNotSupported, ServiceOffLine, SubmissionInterrupted, UnsupportedCompression, UnsupportedDocumentFormat, WarningsDetected) -----Original Message----- From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com] Sent: Wednesday, November 12, 2003 1:05 PM To: Zehler, Peter; PWG Semantic Model WG (sm@pwg.org) Subject: RE: SM> JobStateReasons issue Hi Pete, While most of these just pre-pend "Job" on value, a few change the value (CanceledByUser -> JobCanceledAtUser, CompletedWithWarnings -> JobCompletedWarnings, etc.). Were these intentional? bt -----Original Message----- From: owner-sm@pwg.org [mailto:owner-sm@pwg.org] On Behalf Of Zehler, Peter Sent: Monday, November 10, 2003 11:25 AM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> JobStateReasons issue All, The values in the Semantic Model document do not line up with those in the Schema or in the referenced specifications. In order to keep the mapping clean and to maintain alignment with JDF I propose the following changes in the JobStateReasons keywords entry on page 44 of the Semantic Model spec (JobStateReasons entry in Job Element Table). Below are the corrected values. I also need to update the reference column to include JobX and Prod-Print. Current SM value -> Corrected SM Value __________________________________ CanceledAtDevice -> JobCanceledAtDevice CanceledByOperator -> JobCanceledByOperator CanceledByUser -> JobCanceledAtUser CompletedSuccessfully -> JobCompletedSuccessfully CompletedWithErrors -> JobCompletedWithErrors CompletedWithWarnings -> JobCompletedWarnings Incoming -> JobIncoming Interpreting -> JobInterpreting Outgoing -> JobOutgoing Printing -> JobPrinting Queued -> JobQueued QueuedForMarker -> JobQueuedForMarker Transforming -> JobTransforming Comments? Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031112/8ad4c04d/attachment-0001.html From imcdonald at sharplabs.com Mon Nov 17 11:26:20 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:41 2009 Subject: SM> FW: [printing-jobticket] Updated JTAPI UML diagram Message-ID: <116DB56CD7DED511BC7800508B2CA537B00244@mailsrvnt02.enet.sharplabs.com> Hi, FYI - the FSG Job Ticket API UML diagrams have been updated for recent design tweaks and new content from PWG IPP JobX and JDF/1.2 work. The FSG JTAPI working group has begun development of the Alpha version of the JTAPI/1.0 C language header files. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Claudia Alimpich [mailto:alimpich@us.ibm.com] Sent: Thursday, November 13, 2003 7:42 PM To: printing-jobticket@freestandards.org Subject: [printing-jobticket] Updated JTAPI UML diagram The JTAPI UML diagrams have been updated to include some changes that I have had marked up on my copy for some time now. The png files are located in the following directory on the PWG site: ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JTAPI_Diagrams/13Nov2003/ The following changes were made to the UML diagrams: 1. Modified JobTicketInfo object - Remove the jt-id attribute and id data member - Renamed the jt-length-units attribute to jt-length-unit and lengthUnits data member to lengthUnit - Removed the jt-syntax-version attribute and jtSyntaxVersion data member - Renamed the jt-type attribute to jt-type-and-version and the type data member to typeAndVersion - Added a "*" jt-version indicating that it will not be implemented in 1.0 2. Modified Job object - Added the job-print-content-optimize attribute and printContentOptimize data member. It will not be implemented 1.0. 3. Modified Destination object - Added missing constructor, destructor, get, getAttributeNames, and set methods 4. Modified CollateEnum - Renamed SHEET_AND_JOB value to SHEET_AND_DOC 5. Modified ContactTypeEnum - Added SENDER value 6. Modified HoldEnum - Renamed HOLD_DEFINITELY value to DEFINITE 7. Modified JobTicketTypeEnum - Renamed to JobTicketTypeVersionEnum - Renamed JDF value to JDF_1.2 - Renamed PWG value to PWG_1.2 8. Modified LengthUnitsEnum - Renamed to LengthUnitEnum 9. Added PrintContentOptimizeEnum 10. Modified PresentationDirectionEnum - Renamed all values from xyz format to format used by IPP (for example renamed the value "xyz" the much more readable "TO_RIGHT_TO_BOTTOM") 11. Modified PrintQualityEnum - Removed ECONOMY, FINE, and PHOTO values since we now have a separate attribute and the values in PrintContentOptimizeEnum. 12. Modified SidesEnum - Renamed values to use SHORT_EDGE and LONG_EDGE instead of FLIP_X and FLIP_Y terminology Claudia _______________________________________________ printing-jobticket mailing list printing-jobticket@freestandards.org http://freestandards.org/mailman/listinfo/printing-jobticket From PZehler at crt.xerox.com Tue Nov 18 08:09:49 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Proposed time change for Teleconference Message-ID: All, I would like to have a teleconference to prep for the face to face I have an unavoidable conflict at our usual time. Unless there is any objection I would like to have a two hour teleconference on Friday November 21 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 21st will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/21/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031118/1be21c8d/attachment-0001.html From imcdonald at sharplabs.com Tue Nov 18 21:18:42 2003 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:41 2009 Subject: SM> Proposed time change for Teleconference Message-ID: <116DB56CD7DED511BC7800508B2CA537B00257@mailsrvnt02.enet.sharplabs.com> Hi Pete, I'll probably be somewhere on the highway at that time Friday (and ALSO at that time Thursday). I have a musical gig in Wausau, WI (300 miles west of Grand Marais) from 9pm Thur until 2am Friday. Have a good teleconference. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Tuesday, November 18, 2003 8:10 AM To: PWG Semantic Model WG (sm@pwg.org) Subject: SM> Proposed time change for Teleconference All, I would like to have a teleconference to prep for the face to face I have an unavoidable conflict at our usual time. Unless there is any objection I would like to have a two hour teleconference on Friday November 21 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 21st will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/21/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 From PZehler at crt.xerox.com Wed Nov 19 08:25:45 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Another proposed time change for Teleconference Message-ID: All, Since Bob and Ira had conflicts on Friday I would like to change the SM teleconference date again. Unless there is any objection I would like to have a two hour teleconference on Tuesday November 25 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 25th will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/25/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031119/847227ec/attachment-0001.html From harryl at us.ibm.com Wed Nov 19 10:48:27 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:41 2009 Subject: SM> Another proposed time change for Teleconference In-Reply-To: Message-ID: I'm on vacation (and off radar) that week... but go ahead... we need all the focus on this we can get leading up to Provo. ---------------------------------------------- Harry Lewis Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- "Zehler, Peter" Sent by: owner-sm@pwg.org 11/19/2003 06:25 AM To "PWG Semantic Model WG (sm@pwg.org)" cc Subject SM> Another proposed time change for Teleconference All, Since Bob and Ira had conflicts on Friday I would like to change the SM teleconference date again. Unless there is any objection I would like to have a two hour teleconference on Tuesday November 25 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 25th will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/25/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031119/7500e4b6/attachment-0001.html From PZehler at crt.xerox.com Tue Nov 25 09:39:18 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Today's Teleconference reminder Message-ID: All, Just a reminder for today's teleconference Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -----Original Message----- From: Zehler, Peter Sent: Wednesday, November 19, 2003 8:26 AM To: PWG Semantic Model WG (sm@pwg.org) Subject : Another proposed time change for Teleconference All, Since Bob and Ira had conflicts on Friday I would like to change the SM teleconference date again. Unless there is any objection I would like to have a two hour teleconference on Tuesday November 25 at 1pm EST (UTC-5). Any objections and counter proposals? The proposed agenda for the 25th will be as follows. 1) Quick Status on the current state of Semantic Model and Schema 2) Plan face to face & how to get Semantic Model and Schema to final vote 3) Issues 4) Next steps The Latest (i.e. October 31, 2003) Semantic Model specification is available on the PWG ftp server at the durable URL < ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model-Latest.pdf >. (This is identical to ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-sm10-20031031.pdf There are also .doc and -rev.doc versions available in the same directory.) The Latest (i.e. v0.97) PWG Schema is available on the PWG at the durable URL < http://www.pwg.org/schemas/sm/latest/PwgSchemaLatest.zip > (This includes the entire Latest Version schema directly linked from the SM web page at < http://www.pwg.org/sm > The list of changes from the previous version is available at < http://www.pwg.org/schemas/sm/latest/Schema-Changes.pdf > The teleconference is scheduled to be 2 hours long and we will use only what we need. It will be run using phone and Webex. I will be hosting the Webex and you should follow the instructions for New Users below. Information for the phone and Webex are included below. . Pete _____________________________________________________________ Meeting Date: 11/25/2003 Meeting Time: 1:00 PM EST (-5:00 UTC) (10:00 AM Pacific) Instant Net Conference Details: ------------------------------- Meeting Number: 747275324 Meeting Passcode: PwgSm Meeting Host: Pete Zehler Join Instructions for Instant Net Conference: REPEAT USERS 1. Join the meeting now: http://www.mymeetings.com/nc/join.php?i=747275324&p=PwgSm&t=c 2. Enter your name 3. Agree to the Terms & Conditions and click Proceed. NEW USERS 1. Go to http://www.mymeetings.com/nc/ 2. Type in the Meeting Number 3. Type in the Meeting Passcode (if one was provided) 4. Choose "Conference" and click Proceed 5. If you are a new user, click on "New Users" to check your system and download the software and go back to Join Net Conference page 6. Enter your name 7. Agree to the Terms & Conditions and click Proceed. _____________________________________________________________ Dial in Info: Phone Number:(877) 707-6056 (Phone Number for Xerox Employees: 8*594-0077) PARTICIPANT PASSCODE: 437874# _____________________________________________________________ Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031125/6be9ce13/attachment-0001.html From PZehler at crt.xerox.com Wed Dec 3 08:22:36 2003 From: PZehler at crt.xerox.com (Zehler, Peter) Date: Wed May 6 14:04:41 2009 Subject: SM> Today's SM meeting Documents Message-ID: All, I have uploaded the documents I plan to use at today's meetin to the PWG ftp site. ftp://ftp.pwg.org/pub/pwg/Semantic-Model/ProvoSmMtg.zip Pete Peter Zehler XEROX Xerox Innovation Group Email: PZehler@crt.xerox.com Voice: (585) 265-8755 FAX: (585) 422-7961 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/sm/attachments/20031203/d3da8b6c/attachment-0001.html