PWG MFD Working Group Face-To-Face Meeting Minutes

PWG MFD Working Group Face-to-Face Meeting Minutes

At Xerox, Webster, NY

June 24-25, 2009

June 24 Wednesday Meeting –

1. Attendees:

Nancy Chen, Okidata

Lee Farrell, Canon

Ira McDonald*, High North Inc.

Joe MurdockSharp

Ole SkovMPI

Jerry Thrasher, Lexmark

Bill Wagner, TIC

Dave Whitehead*, Lexmark

Peter Zehler, Xerox

*Phone-in attendee

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

1. Minutes Taker Assigned: Nancy Chen

1. Agenda:

There was no objection to the agenda below:

2:00-2:15 : Introductions, Assign Minute Taker(s)

2:15-2:30 : Resource Service Vote status, Namespace & Next steps

2:30-5:00 : MFD Overall Semantics Discussion

1. Resource Service Vote Results, Namespace & Next steps

(1) Vote Results:

• 23 eligible members for vote
• 4 Yes votes
• 1 Abstain
• Ira to get Samsung’s vote.

Note: 1 Yes vote with comments (Fig. 13 must be updated with ResourceDescription) was received after this meeting on June 25.

• Formal Approval requires
• At least 25% of eligible members vote (6) – has been met on June 25.
• YES votes by at least 66% of votes (excluding abstentions) with no Strong Opposition (5) –has been met on June 25.
• YES votes by at least 80% of votes (excluding abstentions) with Strong Opposition – does not apply
• At least 50% of votes (including abstentions) are YES (5) - has been met on June 25.

• The spec has passed approval vote.

(2) Namespace: XML Schema and Resource Service candidate standard links will be published once vote complete. There will be no problem with discovery of earlier version of services since the two versions of Schema are in two different namespaces which can serves simultaneously.

1. Review the Draft of MFD Overall Semantic Model

(document file: ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20090420.pdf )

(1) Issues on June 5 Version of Overall MFD Spec, and resolved points.

1) References will be added later.

2) Table of Contents format will be made to agree with Resource document when content is stable.

3) Unsure what to do about Datatype normative references (IDS Attributes discussion), but have added a paragraph on datatypes.

• Ira will generate a new section on Datatypes; suggested to start out with data types coherent with XML Schema, CIM Schema, and WKV naming already exists.
• Pete: WKVs are extensible, just need some description of unions of WKVs.

4) Terminology: any more terms?

• More terms are expected.

5) FaxModem Elements: do we agree? What about ItuStatistics? References?

• Added some keywords for some elements.

6) Table 31 and elsewhere,. DestinationUriSchemes is not listed as an element, no keyword reference. DestinationUriSchemes Type is list of strings, not keyword.

• Some URI Schemes are not valid keywords, therefore they are of type String.

7) Table 34 and elsewhere. Keyword group listed as NMTOKEN, none or <Simple Type Union>. Where are the keywords identified?

Keyword reference questions. Some elements of the Keyword or list of Keywords type do not appear to reference a specific set of keywords. What are the appropriate keyword sets?

• The values of XXXElementsSupported are the names of the elements supported, therefore they are of type NMTOKEN.
• The possible values for the list of keywords can be found in IANA registry, similar to all IPP attributes are registered in IANA.
• The list of keywords for JobMandatoryElements, for example, can be found in the Job Ticket elements of the specific service XML Schema.
• The list of keywords for RepertoiresSupported is defined by user. Hence, no way to list. The naming convention is <keyword<namespace of the keyword>
• Instead of NMTOKEN, “JobCreationElementsSupported” should be described as “see specific service spec for the appropriate values for JobCreationElement.”
• AI: the editors will correct these offline.
• AI: Pete to take a look at the user defined value supported that should be defined in terms of <string<namespace> extension pattern.
• RepertoiresSupported is currently defined the same as CharsetSupported in Schema. There are only 800 charset registered by IANA.

8) Table 39:

1. CompressionFactor not listed as element; eliminated
2. Are JobPriority and JobSaveDisposition elements in the Job Ticket Document Processing set or JobProcessing set? They are no longer in the Schema.
3. JobSaveDisposition is an attribute of production printing set2.
4. Bill will work with Pete to correct these.
5. Is Rotation an int or a keyword?

• Rotation is a set of keywords, identified as a list of int for valid values in XML Schema.

(2) Review of the text of the Draft

• Page15- System object need to be modified to include Processor subunit which does not belong in Services. The MFD components defined here should not invent the synonyms of WIMS objects.

AI: Bill to check with WIMS.

• Page21 – ContentCoordinateSystem.
• We now have a service coordinate system used for Scan subunit by Scan Service, and Marker subunit by Print Service. We decided to eliminate the reference to service coordinate relative to service using marker subunit. Wouldn’t fax need marker? Marker only places restriction on the area that an image can be impressed. The margins don’t go quite to the edge of the media sheet, the service itself will represent the size of the image that it supports. Content region is bounded by the margins in print. Hardware may constrain the bleed edge printing.
• Page26 – Data Types
• Counter data type needs to be defined, e.g. FinisherSupplyMaxCapacity on page 37. This should be a gauge of type ‘int’, not a counter.FinisherCurrentCapacity should also be an ‘int’. FinisherSupplyCurrentLevel is also an ‘int’. All ‘int’ are signed 32-integer.
• Pointer type, e.g. InputTrayNextInputTrayID on page 40. This should be ID type which is type ‘int’. MarkerSupplyColorantID should also be an ID, of type ‘int’. This is an index of an instance of the associated object.
• AI: Bill to globally change all counters to ‘int’, xxxID to ‘int’ and send change log to Pete.
• AI: Native XML Boolean type should be a lowercase ‘boolean’. The same change needs to be made in IDS.
• In all MFD work, we should use XML data types wherever possible, so that the mapping to XML Schema or from XML to MOF Schema is unambiguous.
• Keywords mostly are a union of NMTOKEN and an extension pattern.
• URIScheme is a string. In any place a URIScheme is any URI or a list of URI.
• XML does not have octetString. This should be XML ‘hexbinary’ type.
• AI: global change octetString to ‘hexbinary’. Ira to send the definition of ‘hexbinary’ to Bill with reference to XML Schema part 2. There should be note that says that this maps to PWG data type ‘octetString’.
• Subunits
• This section has been re-written. Let Bill know if there is any objection to the text highlighted in this section.
• Pete had made significant changes to Subunits so that subunit status and descriptions are switched in diagrams, and general subunit elements are inherited by each subunit. In XMLSpy the inheritance is shown in the first sequence of elements (as the base type), in the second sequence of elements are service specific (derived) elements.
• Page 63, the LiquidXML schema diagram of VendorSubunit clearly shows boxed group of inherited elements from Subunits, followed by un-boxed sequence of vendor-specific subunit elements. LiquidXML has a better way to show the inheritance relationship. No objection to use LiquidXML diagram in MFD Overall document.
• Page 30, a table display the complex data type of common subunit elements.
• Reference RFC2760 in Table 4 should be RFC2960.
• Page33, Table 6, CoverState of the CoverStatus only has cover-specific states, not the common Subunits states.
• AI: Pete to change the schema for CoverState to inherit from SubunitStates which should include Cover-specific states.
• Page34, FaxModem
• FaxModemDescription : a lot of WKV are newly defined from MIB, modem documentation, …, etc. Don’t know whether they are appropriate.
• One ticket attribute is dial type: pulse or tone (desire to be configured by HW : a subunit feature, not by jobs by user), no need to switch these by job type. This should be a HW configuration, can’t go from tone to pulse by user job setting, don’t need these IT statistics, or fax-configurations,… Ira will take a look again.
• Need expert’s advise: What should be eliminated? What should be needed in managing fax? What’s dialing prefix, addressing suffix? Location? Time? Fax modem MIB does not cover all these.
• Need to add vendor extension.
• Page55 Processor
• The Processor Subunit Elements table got changed mainly to inherit from Subunit Description, and added ProcessorFirmwareID and ProcessorLoad.
• Page62 Vendor Subunit
• Has VendorSubunitDescription, VendorSubunitStatus.
• On Table 40, Confirmed that CompressionFactor of Document Processing is eliminated.
• CompressionQualityFactor is Fax service specific.
• JobPriority should be a Job Processing element in the base class, and is optional. Great for scheduling jobs within a service competing for the same resources, also for competing among services. Since it’s optional, can be annotated as “not applicable” for the none-job related services.
• AI: Pete to move JobPriority into JobProcessing base class.
• JobSaveDisposition is a member of production printing set2 for Job Processing.
• AI: Ira collaborates with Tom Hasting and Harry Lewis to indentify and add those production printing set2 properties in Job Processing.
• Page 109, The System
• Will take descriptions from WIMS.
• AI: Pete should move Subunits from Server into System. System description should reflect the change in adding subunits. System represents everything in the MFD that is manageable, including the roll-up counters. It should be described right after MFD Model Concept.
• AI: The System should have SystemConfiguration (Subunits), SystemDescription, SystemStatus, and Other elements.
• Agreed with the descriptions in SystemStatus Element Table.
• Agreed with the system state positive roll-up definition.
• Vendors are free to define operations to retrieve the state of all services in MFD.
• Added some SystemDescription elements, resulting in a new Schema structure.
• AI: ResourceSupported should be AvailableResources – a list of available resources. Pete to correct the Schema.
• ServiceDocumentFormatSupported should only be useful for individual services. AI: delete this element.
• ServiceSupported WKV have an extension pattern in Schema. AI: add extention pattern to the description in the table
• Confirmed that in DeviceSupported and ServiceSupported, the ID and URI both should be eliminated. Because now we have the ability to enumerate the services and devices at the subunit level.
• Table 49, System Operations
• Should we keep RestartAllServices ?? Yes.
• Page 117 – Is Tabulation of Keyword Group Identifiers useful? Yes.
• Bill will update the MFD Overall Semantic draft according what are agreed in today’s meeting and make it available to the group as soon as possible.

June 25, Thursday –

1. Attendees:

Nancy Chen, Okidata

Lee Farrell, Canon

Ira McDonald*, High North Inc.

Joe Murdock,Sharp

Ole Skov,MPI

Jerry Thrasher, Lexmark

Bill Wagner, TIC

Dave Whitehead*, Lexmark

Peter Zehler, Xerox

*Phone-in attendee

1. Introduction & PWG IP Policy :

Peter Zehler, the MFD Working Group Chairman reminded attendees the meeting is being conducted in accord with the PWG IP policy. No objection.

1. Minutes Taker Assigned: Nancy Chen

1. Agenda :

• Introductions, Assign Minute Taker(s)
• FaxOut Service Discussion
• Copy Service Discussion
• Wrap up

No objection to the proposed agenda.

1. FaxOut Service Discussion

• Issues To be resolved and deleted before publication

1) Is CoverSheet a per destination item or per Job?

We agreed to keep the semantics right now : CoverSheet is a per job item. In most implementation the same coversheet is used for multiple destinations. Nobody is aware of a different implementation. If a user wants a separate coversheet for each destination, he/she can send separate jobs for destinations.

2) Fax completion logging and removal of Jobs from JobHistory

- Currently the service has a mandatory JobHistory for completed jobs, in other services this is an option. But the service does not specify requirement for removal of JobHistory; before the removal the JobHistory has to enter the fax job log in order to meet fax legal requirement.

- JobHistory retention period is completely implementation dependent in Print and Scan. Although IPP has a recommendation that if this is implemented at all, must be keep for a minimal of 5min (?).

- Job log has to be transferred in a persistent store. In fax implementation today, logs are kept in some cheap memory that can retain fax log for at least one week, and may periodically send the log via email to administrator because of the security requirement for extended retention period.

- If jobs are logged timely as soon as completion, then we do not need to worry about removal of JobHistory to enter into job log. Also, fax job may need to be logged as soon as it’s initiated at the other end. Typically job log is created independently and differently from JobHistory. Log is created by the service, and need both FaxOut and FaxIn logs. Whether these are separate logs seems to be implementation dependent.

- Fax job log must be entered as soon as a fax job starts processing, i.e. when the job is scheduled, prior to dialing.

- PSTN fax or NetFax (IETF fax) are unified now in one FaxIn and FaxOut service because of the URI scheme used, and the legal requirements of the two are the same in ITU. We need reference links in this doc to IETF & ITU specifications.

– AI: Ira to send the links to Pete.

-Conclusion: the removal of History is not tied to logging. If a job is scheduled, must be entered into log. JobHistory remains optional; if implemented, must has some minimal retention duration (300 seconds), so polling can keep track of all the jobs.

3) Remote access to JobHistory/Log

- Currently remote access to JobHistory is already provided, the question is how to provide remote access to the log

- There is no std format for fax log, only data field requirements such as time stamps, etc. There are some IETF requirements for data fields of the log, the model either must provide some data stream or if emailed to admin, presumable some sort of human readable text.

- It seems that how job log is accessed should be left to implementation as vendor’s differentiation. Does this mean we shouldn’t have operations for accessing logs at certain URI, allowing administrator to offload the logs? ITU requires to get fax log URI, so that fax log can be obtained whenever necessary. Also in P2600, the log has to be protected. Depending on what information is logged, the log could be confidential or protected data (from disclosure and alteration). The model must be able to accommodate P2600 requirements. We should reference P2600 as the best practice by using ftps, https, or some other secure transport; recommended but not required. There should be log URI attribute provided by the model at least. Traditionally no separate logs for faxin and faxout.

-AI: Pete to add a new attribute for fax log URI in ServiceDescription property.

- How long jobs remain on the JobHistory list is implementation specific.

4) How much of Modem MIB needs to be included in FaxModem Subunit

- This was deferred to fax modem subunit discussion

• Issue: When shared by a workgroup that uses different functions of the MFD, the model supports interruption of a large FaxOut Job to perform other MFD functions including a different FaxOut Job?

• We can’t Pause a fax job when it’s processing, can’t interrupt a fax job by the underlying protocol (e.g. PSTN). Currently FaxOut service has hold/release job service operations, not pause/resume job (stop output). At service level, hold means stop scheduling, pause means stop output as soon as possible.
• Hold fax job make sense if the job is pending, but not if the job is processing. Even in processing state it’s possible to hold the fax job if phone has not been dialed yet. However, in IPP or DPA it’s possible to hold a job in processing, which behave as a synonym to pause job. Except in some service such as fax, it may not be possible to hold a job in processing. In 2911, A ‘Hold’ job is defined as holding a job in queue preventing the job from being scheduled. However in Print or Scan we do want pause job service operation for interrupting a job allowing a higher priority job in another service to be processed.
• WS-Scan has hold/release, cancel, but no pause/resume job.
• Print Service has hold/release, no pause/resume, but RFC 3998 has suspend/resume job. Suspense here seems the same as pause. If IPP has pause job, we should add pause/resume into Print Service (administrative). Pause/Resume job also make sense in Copy Service, Scan Service, but not in Fax.

AI: Pete to fix Print WSDL to add suspend/resume job. Revisit Scan service when all services are completed and bring all service to a consistent set of interfaces.

• Terminology

- Terms that are general to all MFD services should be deleted. No term listed in the table is FaxOut specific. Should mention all the terms are imported from MFD Overall Model semantics.

• Out Of Scope

- PSTN connected fax (not network connected) is out of scope

• Issue on How long job remain in JobHistory

- This is now implementation dependent. Ira recommended to use IPP verbiages.

• Is current Modeling approach appropriate?

- The model has ServiceDescriptions and diagrams, one line text on the first sequence being the inherited service base class elements and the second sequence being FaxOut-specific. Need text on referring to the MFD Overall Semantics spec for details.

• AI: Pete to add reference to MFD Overall Semantics spec for details, and put table caption above table.

- All service states in IPP make sense for FaxOut service. Will be more problematic in FaxIn (no queued job for completion, has create job – a transient state of pending.)