Peter Zehler reported that the MediaSizeNameExtensionPattern was not correct in MFD XML Schema. Pete added Norbert’s correction, but the old pattern was not deleted which caused problem for Norbert Schade’s driver. Pete asked for deletion of the two old incorrect extension patterns if there is no backward compatibility issue. There was no objection for the deletion.
Pete noted that these patterns are not the same as the patterns in WS-Print. Pete and Mike will investigate. If the two are not the same, Pete will add the pattern in WS-Print into MFD Schema.
MFD Schema Changes Review & Discussion
Pete presented the recent changes to the MFD XML Schema for discussion.
The root of the Schema has been changed from ‘Server’ to an active entity “System” which represents the MFD as a whole.
SystemConfiguration contains all Subunits defined in the model, represents any subunit that can be utilized in any service.
Each service now has a service-specific view of only the subunits applicable to the service, instead of all possible subunits.
Pete will make sure the posted Schema is up-to-date from the changes agreed in the previous teleconferences. The latest version today is version 81.
Other changes are to SystemStatus, and SystemDescription. Previously these are inherited from the Imaging class.
No change to Managers, Agents, and Devices.
That the current model of Services does not quite match with the definition in the specification was discussed. Nancy recommended to model the Services element as a sequence of Service elements, each is a choice of one of the Print, Scan, Copy, Fax, … type of services. Pete explained that although this is more correct in terms of object oriented modeling, but this incurs adding of an empty wrapper “Service” for each instance of individual service type. Mike pointed out that the current model in Schema implies a fixed order of service instances in service type; whereas a sequence of service instances, each of a selected service type can be added without an implied order. Pete noted that however the current structure (ordered sequence) allows an extension point to be added for vendor’s extension. Adding an extension point to a choice of service types would result in a non-deterministic schema error in XML. An alternative is to add an extension point outside the unordered set, but it is simpler to add the extension point to an ordered sequence. No further explanation to the complexity of the alternative structure. But the decision was not to change the current model.
Pete would like to define the common terminologies, concepts, elements, descriptions that would otherwise need to be repeated in each individual service without the Overall spec. Another purpose is to describe how the individual service fit within the framework of MFD.
Bill’s question: “Should the purpose and scope be describing the System element that represents the MFD instead” was discussed.
Ira: We need both specifications of the System object and common core elements and operations for services. There may be need for two separate documents.
Pete would like to be able to retrieve counters and access alert tables of the overall MFD system from MFD management perspectives, keeping system wide operations to the System object for monitoring purpose.
MFD Overall Specification and System Specification
We discussed which sections of the current Overall document should belong to the new MFD overall document, which sections should belong to the new System document. The following conclusions were reached:
Overall specification :
Include the following sections from the current Overall document:
Terminology – add references to general terminologies.
The nomenclature of should be explained at the beginning of the table.
MFD Model Concepts (all subsections)
Functional Overview of MFD
Need Pete’s update to Figure 1.
Jobs, documents, Tickets, and Templates
Template description should merge with Job and Job Lifecycle descriptions
Contents Regions, and Images
Content regions are also described in two different sections. Need update.
Both SystemDescription and SystemStatus should only be a short paragraph describing what this group element does in general. SystemDescriptions are elements that can only be set by administrators according to System policy. SystemStatus are elements maintained by automata related to the System. Individual elements should be described in “System” document.
AvailableResource and ResourcesSupported
System Operations should be moved to “System” object description.
Provide a brief top level definition
Sub-elements should be moved to System object description.
Insert a “System State Roll-up Rules” title for the paragraph describing the rules.
Managers, Agents, Devices
Contents from WIMS spec with references.
Service Model Components
Split each of the tables into two sections: Base class elements, service-specific elements.
Imaging Job Model
Service Theory of Operation
System object specification:
Include the following sections from the current Overall document:
Covers the operations that affect the model
SystemDescription : description of sub-elements
SystemStatus : description of sub-elements
Managers, Agents, and Devices – should provide references to WIMS.
System Operations for managing the services (e.g. start up, shutdown services)
Bill volunteered to create the first draft of both the MFD Overall Document and the MFD System Object Document.
August 20 Thursday Meeting –
Nancy Chen, Okidata
Lee Farrell, Canon
Mike Fenelon, Microsoft
Harry Lewis, InfoPrint
Jane Maliouta, Microsoft
Ira McDonald*, High North Inc.
Joe Murdock, Sharp
Jerry Thrasher, Lexmark
Bill Wagner, TIC
Craig Whittle, Sharp
Peter Zehler, Xerox
Introduction & PWG IP Policy :
The MFD Working Group Chairman Peter Zehler reminded attendees the meeting is being conducted in accord with the PWG IP policy. No objection.
Minutes Taker Assigned: Nancy Chen
A Brief Note on FaxOut Service Implementation at Xerox
Pete said Xerox’s implementation of the PWG FaxOut Service supports jobs that may have multiple destinations. Even when faxing out to one of the destinations failed, the job still goes to completion; but there are job state reasons allowing the specification of completion with error or successfully. Each FaxOut job has log records allowing users to find out which one of the FaxOut job destinations has failed with what reason.
Pete is still looking for members’ inputs on the set of right attributes for the fax modem element.
Proposed Copy Service Model XML Schema Review
Pete provided a walk-through of the XML Schema of the proposed straw-man Copy Service model.
The following Copy Service operations are available:
CancelCopyJob – cancel a copy job
CreateCopyJob – create a copy job
GetActiveCopyJobs – get a list of active copy jobs
GetCopyJobElements – get the attributes of a copy job
GetCopyServiceElements – get the attributes of copy service
ValidateCopyJob – validate the ticket for a copy job
DisableCopyService – disable input for copy service
EnableCopyService – enable input for copy service
PauseCopyService – stop output for copy service
ResumeCopyService – resume output for copy service
There is no ‘Add Multiple Document’ operation – same as Scan Service
For creating a copy job, there are two sets of document processing instructions: one set for controlling the input (scanning) of hardcopy document, the other for controlling the output of hardcopy document. This is to resolve the conflict in specifying “sides” and resolution when one needs to input two-sided document with one kind of resolution, and output (print) single-sided document with different resolution or vice versa. Therefore in the Schema of copy job ticket, CopyDocumentProcessing has “Input” and “Output” elements of document processing instructions. “input” elements are the same as for scan documents processing, “output” elements are the same as for print document processing.
AI: change “Input” to “InputDocumentProcessing” and “Output” to “OutputDocumentProcessing” for clarity.
CopyJobDescription and CopyJobProcessing are the same as those in other services. CopyJobProcessing also has input and output side of processing instructions. Like Scan Service, CopyJobProcessing allows multiple set of originals that allow the use of local UI to construct the full set of input-output document cardinality types: SDSF, SDMF, MDSF, MDMF. Xerox’s devices perform some internal scan-to-print imaging path optimization, these are not adjustable by external users.
All the services have a DeviceId in ServiceDescription that allow a user to get the P1284 identification of the MFD device when communicating with the service. It is not the Id for the service.
The current schema has ServiceUriSupported and XriSupported. Each Xri Supported element has three elements: Uri, Authentication, Security. Pete would like to deprecate ServiceUriSupported. No objection.
AI: Remove ServiceUriSupported, rename XriSupported as ServiceXriSupported, and rename XriUri element in ServiceXriSupported as Uri in all services.
CopyServiceStatus is the same as other service status, has an Id that identifies the service instance and is the key. Copy counters are included in the status.
Ira reported that in the MIB the copy counter must include both imaging and impression counts, these two counts may not be the same when multiple copies are made. The definition of copy counts in the PWG Counter spec does not include imaging counts. Xerox devices only count impressions. Consensus: only impressions will be counted. Make a note that input images are not required to be counted.
The InputKOctets is defined as the raw size of scanned image. Ira said this was defined in printer MIB and Counter spec as the raw traffic counter of the protocol packet over the job input channels, not the data size of the document submitted as the job data. In counter spec it is defined as the data amount received by the service in integral increment of 1024 octets, not channel specific – sounds like the size of the raw scan image; it could also be the size of the job ticket received on a logical input channel. Therefore it could be interpreted as in ‘Push Print’ it counts the job ticket and document data received; in ‘Pull Print’ it counts the referenced document data received. However, Ira who is the original editor of the MIB spec clarified that the definition of the counter is the job input data size over the job input channel; therefore for ‘Pull Print’ it should count the job ticket size over the job input channel, not the referenced document data size received over the job data channel. It was also recognized that no matter how the counter was defined in the previous specifications, the value of counting the traffic data size and job document data size should be determined in finalizing the definition of this counter. Ira maintained that the author of the Counter spec erroneously redefined this counter from the MIB spec, if the definition in the Counter spec is desired, it should be rename as a different counter. The behavior of the same counter name should be consistent with what’s defined in MIB spec. Since the change of this counter definition will break the existing software that is implemented according to the MIB spec, such as what has implemented in the existing Samsung products, and also impact future implementations of the counter in all services, we agreed to raise the definition of this counter as an issue to be resolved further.
Ira also maintained that both InputKOctets and OutputKOctets are for counting the size of job input and output protocol messages. OutputKOctets is for the case if the chaining of servers exists, the service is sending the output data to other servers. If no chaining of servers, OutputKOctets never applies. If other counters are desired, Ira is happy to add another counter name and definition, but he maintained that the definition of the existing counters must not be changed. However some of us value the counter for input and output job document data sizes for the purpose of charging, not for measuring the protocol message sizes.
AI: Since a copy service is an integrated scan and print service, so according to the MIB spec, OutputKOctets would not apply. Pete will remove OutputKOctets from the Copy Service.
AI: Address the issue of clarifying the definitions of InputKOctets in the WIMS working group meetings.
WorkTotals counter right now captures the impressions produced for the Copy Service.
We discussed the value of including images in addition to the impression counts in the counters. Count of images allow you to measure the wear of scanning unit for maintenance purpose in fleet management; although that is captured in the scanner subunit counter, image count should be considered if there are customers desire to use it for charging purpose. Xerox currently covers this charge in the different pricing of copy counts vs. the print page counts. Scanner subunit counter can not distinguish the scan counts for Copy vs. Scan or Fax, .if a customer desire to adjust the cost for Copy vs. Scan, then there is a value to know the image count for Copy. In that case, an implementation can always add the desired counter in CopyServiceCounters, or in the Scanner Subunit counter.
Enable/DisableAllMFDServices - enable and disable all services at once
Enable/DisableMFDService – enable and disable a particular service
Pause/ResumeAllMFDServices - pause and resume all MFD services at once
Pause/ResumeMFDService – pause and resume a particular MFD service
GetMFDServiceElements – get system status, system description elements
The naming of MFD Services as opposed to System Services was discussed. In XML Schema, we named ‘System’ as the root of the MFD, however using the name ‘System Service’ is confusing because ‘Services’ is a sub-element under ‘System’, hence ‘System’ is not a service. The name ‘MFD Services’ is as confusing, since the communication is addressing to the System object. In the previous MFD conference calls, we agreed to make System distinct from ‘Services’, hence ‘System Service’ should not be used.
AI: We agreed to the operations rename as the followings:
Enable/DisableService – for a specific service
Pause/ResumeService – for a specific service
Remove PauseServiceAfterCurrentJob operation
Shutdown/Restart/StartupService( ServiceTypeName and optional ServiceId) – for a specific service. If ServiceId is included, it operates on a specific service instance. If ServiceId is not included, then it operates on the entire class of the service type.
GetSystemElements (renamed from GetMFDServiceElements)
Add SetSystemElements operation – this operation can not set SystemStatus elements
No Hold/ReleaseJob operations – System does not process jobs.
Add Startup/Shutdown/RestartAllServices( a list of ServiceTypeName and optional ServiceId) –
If ServiceId is included, it operates on specific service instances. If ServiceId is not included, then it operates on the entire class of the service type.
These operations operate on every service the System is configured to run. Currently the model does not allow configuration of which services and how many instances of each type are configured to run at startup. An element could be added to the System, and SetSystemElements operation could be used to configure the elements for the services to be started up by System. However, this will allow a system administrator to configure the services to be started up, which is not a normal operation for MFD. These services to be started up normally is built in MFD by manufacturer’s default. “Startup Services” means create service instances in DPA and all previous PWG semantics. These services to be started up should be built-in by manufacturer’s factory defaults, which default attributes can be changed after started up by the System.
AI: We need a ConfiguredServices element in SystemStatus, each sub-element has a ServiceType and a ServiceId, which can be used for the parameter of a Restartup operation after initial startup time. At the System initial start-up, the System automatically starts up all these configured/built-in manufacturer’s services/queues with the factory default attributes and records these services in ConfiguredServices. Once the ConfiguredServices is recorded, it stays persistent throughout the life of MFD System. An administrator is allowed to disable/enable or change the default of the individual queues after start-up through individual service operations.
AI: Delete StartupAllServices operation, since the initial startup is an internal manufacturer’s built-in function, and after that all startup should be a Restart operation.
Nancy raised the issues with the IDS required attributes and operations in System for SoH reporting that need to be considered. We agreed these need to be discussed in the near future whenever the time comes.
Pete to rework the XML Schema according to the conclusions from the meeting and publish it.
Pete to or find another editor to update and publish the FaxOut Service spec.
MFD WG Teleconference in 2 weeks from today on September 3, 2009, 3pm EDT.
As a side note for other PWG conference calls:
SC call is scheduled on next Thursday August 27, 2009, 2pm EDT.
WIMS WG conference call is schedule on next Tuesday (Sept 1).