Below are agreed additions to Terminology which were not available in the previous concall:
Add introductory text: “ prefix in the terminology table represents any MFD services”.
Add “Device”; its definition from the WIMS document, is defined as “an abstract object representing a hardware component of a network host system that supports the indicated service. A device exposes every subunit on the associated network host system involved in performing the function of the indicated service.
Add “Document”: an object created and managed by the specified service that contains the description, processing, and status information, of a data object submitted by a user. A document object is bound to a job.
Bill to add a “Conformance Terminology” section to introduce the standard conformance terminology. The rest of terminology belongs to “MFD Service Terminology”
Section 2 – Agreed are the followings:
Figure 1 – MFD top level Schema diagram : SystemDescription & SystemConfiguration are mandatory elements. Pete to update the Schema. Bill to update the diagram.
Figure 2 – Primary Interfaces with Services will be updated: Copy Service to Repository path is eliminated (no digital document output available from the Copy Service). Both input fax and output fax are changed from 3 categories: Digital Fax, ITU Fax sys, and IETF fax sys to 2 categories: PSTN Fax and Network Fax (include store and forward, and real-time network fax).
AI: Peter Zehler to send updated Figure 3 diagram and text of section 2.1.2 to Bill again.
Line 490: remove “the originator and the destination” – a holdover from Scan Service specification. Replace with “descriptive information of the job and associated metadata.”
Line 499: Add job processing to document processing. Change “descriptive properties of a job or document” to “descriptive properties of a job and optionally one or more documents”.
Add Document Receipt concept description after Job Receipt: “The Document Receipt is produced by a Service as a Document within a Job that is processed. It contains the values of processing elements used by the Service for processing the Document, usually including some information from the Document Ticket.”
Figure 4 should be revised to non-Scan specific. Pete to provide the updated, more generic diagram.
Lines 539-540, change “that can accept multidocument jobs (Scan and Transform) can
provide their Digital Document output (e.g. Print and Scan)”.
Line 563, change “support” to “generate”.
Bill will redraw Figure 8. To enhance the color scheme.
Line 647: Strike “using Scan Service as an example”.
Line 673 “A Job Template…”: This paragraph should be combined with the previous paragraphs that discuss Job Template. (for continuity).
AI: Ira to re-do Section 2.6 Data Types.
Table 3: three happy faces need to be corrected to ‘:)’.
Section 3 – We agreed to the following changes:
Add an additional paragraph at the beginning of Section 3 : “The SystemConfiguration represents device semantics in the MFD Model. The included elements are semantically aligned with the printer MIB (REF). The included elements are also aligned with the DMTF CIM printer class (REF).”
Line 743 Figure 11 Subunit Status and Subunit Description Schema diagram needs to be regenerated.
Section 3.3 – CoverState should be SubunitState. Ira and Pete will work together to get schema aligned with MIB and CIM and send the result to Bill. The Schema shows there is a mapping issue between rfc2790 & rfc2805.
Section 3.4 – FaxModem, needs a lot of references in Table 7. Need experts to provide inputs on this section.
AI: Bill to search globally and replace all elements ‘other’ with ‘any’.
Line 855 – Change 3.9.1 to 3.10. All the following section numbers need to be updated.
Line 856, change “the media is marked” to “the marks are impressed on the media”.
OutputTray – Table 25, add description text in addition to references for OutputTrayStackingOrder element that tells first-last or last-first, and OutputTrayPageDeliveryOrientation element that tells face-down or face-up.
MediaPath needs to consider media weight. (Duplex media path should not allow heavy media types.) Add MediaTypesSupported (a sequence of AllowedValues) in MediaPathDescription to allow media weighs expressed as different media types. This is currently not in Printer MIB or CIM printer.
Bill to make a reference to Printer MIB system controller object in hrDevice table from which MFD Processors are abstracted. Ira to send this reference text to Bill.
ScanMediaPath: Need to clarify that this is different from the print media path in the MediaPath section.
Scanners: Table 28
The reference for ScannerMarginBasis should be prtMarker North/South/East/WestMarginMargin out of band values.
The reference for ScannerNorthMargin, ScannerSouthMargin, ScannerEastMargin, ScannerWestMargin should be prtMarkerNorthMargin, prtMarkerSouthMargin, prtMarkerEastMargin, prtMarkerWestMargin.
Table 20 needs to make the same changes. It’s true everywhere there is a ‘Basis’ object.
The reference for MarkerAddressabilityBasis should be prtMarkerFeed/XFeedAddressibility out of band values.
AI: The group needs to discuss all the Basis elements that abstract out of band values from Printer MIB properties and from where they are derived.
Storages: Table 29
Add to description of StorageFree: “is hrStorageSize – hrStorageUsed”
Add the reference to StorageSize: hrStorageSize.
Add the reference to StorageType: hrStorageType.
StorageIsRemovable in not in the MIB. However it’s important for P2600 security requirement which should be the reference, not rfc2790. Need the correct reference if it comes from DMTF CIM. (What is the correct reference?)
SubunitDescription, StorageDataEncryption, StorageMake, StorageModel, StorageName, StorageURI are derived from general ServiceStatus definition of IPPv1.1. They are not in Printer MIB.
StorageMake and StorageModel should be combined into StorageMakeAndModel which exists in Printer MIB. AI: Pete to change the Schema for Storage, Bill to change the elements in the Table. Sorry, has this been done?
AI: Pete and Ira to investigate and arrive a better mapping between the Schema and the Model information. Ira to look into IETF Entity MIB which is an extension to the host MIB on describing component and subcomponent.
MFD Subunits can be distributed across the network. However, currently in the model there is no way to correlate a particular Cover instance with the subunit that utilizes the Cover. The only way to resolve this is to add a vendor subunit that knows how to construct a device using a particular Cover instance. Are we to do something about this?
Section 4 –
Move the note for DefaultServiceTicket* to before Figure 41.
Fix the mixed text with Figure 42, and a lost table for JobTable. (???)
Section 4.4, Line 1034 – change “without necessitating reconfiguration or adjustment of the MFD” to “without operator’s intervention.”
Section 4.4 –
Table 31 –
CopyRegion is actually a Scan Region on the input side.
AI: Bill will follow what’s in the Copy Service Schema now. (CopyRegion now eliminated)
Other: should be ‘any’. There is no inherited ‘Other’. Remove it. In Schema, the base class is a fixed sequence of elements. No extension may be added – non-deterministic schema if added. Extension point is always added outside the base class in Service specific area.
Figure 45 needs to be updated.
Section 4.5 –
Table 35 –
JobCreationElementsSupported is not a list of all possible keywords. The set of keywords that NMTOKEN represents is any standard or valid Job Creation element defined in the model or by vendor extension.
AI: MediaColDatabase is supported values of MediaCols which is a sequence of MediaCols; should be deleted from ServiceDescription in Schema and Table 35. MediaCol in DocumentProcessingCapabilities should be replaced with MediaColSupported which replaces MediaColDatabase in Schema and Table 31.
Media is not a ServiceDescription element; it’s a DocumentProcessingCapabilites element.
AI: MediaSupportedType is a data type for a supported media; i.e. the allowed values for media type, not a property. Remove from ServiceDescription.
I am confused. These notes do not agree with what I had noted in the text (perhaps because the decision was changing. What I Get is:
DocumentProcessionCapabilitiues should have MediaColSupported rather than MediaCol.
MediaColDatabase is removed from ServiceDescription elements.
Line 1100 (1144) “The values of the elements can be administratively set and/or can be modified directly or indirectly through an operation.” But currently there is no such administrative operation defined. This will be defined later. So what should the text say?
Remove “Other (inherited)” from the base type in Table 36 & ServiceStatus Schema diagram (Figure 48).
Pete to remove “Other” from any base class in XML Schema.
Line 1135: “the job processing instructions on a document by document basis by supplying a DocumentTicket” should be “the document processing instructions at job level on document basis by supplying document processing elements in a DocumentTicket”.
ServiceJobCounters should be JobCounters.
ImagesCompleted should be “Number of images processed by a service.” Scratch “using the Scan subunit.”, and delete everything else. Leave the two notes. Note 1: “The service MUST promptly update this counter.” Bill will provide reference for the 2nd note. The reference for ImageCompleted should be the Counter spec, not WS-Scan.
JobMandatoryElements is not of a list of all possible keywords. This is a list of JobTicket elements that must be honored.
Remove JobPriority and JobSaveDisposition: Do not make sense for DocumentProcessing, make sense for JobProcessing. Both should be moved to JobProcessing.
Rotation: the keywords are the actual digits 90, 180, 270. Vendors are free to add more.
Section 7 –
Change the title to “Service Operations and States”.
Figure 58 Job Transition Diagram:
Take all color background off – hard to read if printed black and white.
Should make a note: A saved job is a completed job with certain processing instructions, if resubmitted, a new job is created and submitted as an implicit job request.
Change “StartJobRequest” to “JobCreationRequest”
Change (a), (b), (c), (d) to
Directly through a local client…, or
Directly through a remote client… Which is direct and which is indirect…or is it even applicable ?
Table 48 – Common MFD Interface Requests and Responses
Add PromoteJob with two parameters: optional JobID – the job to be promoted, Predecessor-JobID – optional. This operation schedules the specified JobID after the Predecessor JobID which must be in pending, processing, or processing-stopped state (rfc3998)). This is an Administrative operation. If no JobID is provided, the operation does the same as PromoteJob in IPP (schedule the job as soon as the current job is finished). If predecessor is not specified, or is not in one of the pending, processing, processing-stopped state, or is not found, the service returns a fault.
Add administrative operation Set ServiceElement (may not set ServiceStatus elements), user operations: SetJobElement and SetDocumentElement operations (rfc3380)
Add CancelJobs: This operation has two parameters: MyJobs – boolean and optional JobIDs. If MyJobs is ‘true’, it cancels all jobs of a user’s. An administrator can cancel other users’ jobs specified in JobIDs, but the operation does not delete the canceled jobs from History. Later in IPP WG meeting, this operation is split into two operations: (1) CancelMyJobs for users to cancel his/her own jobs. If any job is not owned by the user, a client-error-not-authorized is returned. (2) CancelJobs for administrator to cancel all jobs. If any job is not cancelable, client-error-not-possible is returned. Client-error-not-authorized takes precedence over client-error-not-possible.
Do we adopt IPP operations as general? Is it CancelMyJobs or CancelMyJobs? Do we get into returned messages , error messages.
Add PurgeJobs: Remove all jobs no matter what state the jobs are in (rfc2911) (including jobs in JobHistory).
Need a Conformance Section which needs to state that “All other Service document must conform to the Overall document – must use common properties defined here, and must not define them.”
Need a Requirement Section which must have Rationale, Use Cases, and Design Requirements.
Rationale: There is a lot of commonality among Services.
Use Cases: Should have use cases for all different MFD services.
Design Requirements: These are derived from the rationales and use cases.