There will be an MFD conference call at 3:00 PM EST (12:00 PM PST) Thursday September 9.  Below is the proposed agenda

The meeting is held in accord with the PWG Intellectual Property Policy.

teleconference:

Call-in toll-free number (US/Canada): 1-866-469-3239

Call-in toll number (US/Canada): 1-650-429-3300

Call-in toll number (US/Canada): 1-408-856-9570

Attendee access code: (by request only, please contact me if you do not have it)

Live Meeting:

<https://www.livemeeting.com/cc/xerox/join?id=PWG-MFD&role=attend&pw=LetMeIn>

Agenda:

1. Identify Minute Taker

2. Approval of minutes from last meeting

        <ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-mfd-minutes-20100902.pdf>  

3. Agenda bashing

4. Discuss Power elements in schema  (See below)

5. Discuss JobOriginatingUserAuthenticationInfo element in schema  

            <http://www.pwg.org/mfd/navigate/PwgSmRev1-107_ImagingJobStatusType.html#LinkC20>

6. Next steps

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler <at> Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

The power abstract group collects together all the power related elements.  This is a convenience class that is never instantiated but is useful for looking at all the power elements.  It can be browsed at

<http://www.pwg.org/mfd/navigate/PwgSmRev1-107_Power.html#Link514>

The power extensions to the System object can be viewed at:

System Capabilities:

<http://www.pwg.org/mfd/navigate/PwgSmRev1-107_SystemCapabilities.html#Link3>

System Description:

<http://www.pwg.org/mfd/navigate/PwgSmRev1-107_SystemDescription.html#Link1B6>

System Status:

<http://www.pwg.org/mfd/navigate/PwgSmRev1-107_SystemStatus.html#Link1BE>

The power extensions to the Subunits objects have been made to the base classes for description and status.  They are inherited by all subunits.  Included below is a link to the Marker Subunit so you can see how the inherited classes are used in an actual subunit.

Subunits Description:

<http://www.pwg.org/mfd/navigate/PwgSmRev1-107_SubunitDescription.html#Link25F>

Subunit Status:

<http://www.pwg.org/mfd/navigate/PwgSmRev1-107_SubunitStatus.html#Link265>

Marker Subunit:

<http://www.pwg.org/mfd/navigate/PwgSmRev1-107_Marker.html#Link2B7>

All,

I have posted a whitepaper covering the syntax and semantics for Geolocation and Global Identifiers for Jobs and Printers.   I have also made changes to a couple of Wiki pages.  Please let me know if there are any objections.

Posted whitepaper covering Global Identifiers and GeoLocation:

   <ftp://ftp.pwg.org/pub/pwg/mfd/white/GlobalIdentifiersAndGeoLocationAttributes.pdf>  (and .docx)

Updated GeoLocation Wiki page:

    <http://pwg-wiki.wikispaces.com/Geolocation>

Added link to whitepaper covering Global Identifiers and GeoLocation to IPP Everywhere page:

   <http://pwg-wiki.wikispaces.com/IPP+Everywhere>

Pete

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler <at> Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

All,

Below is the original note regarding a request for parent/child job identifiers and the meeting minutes from the MFD working group discussion.  It was felt that the place for this discussion should not be in the MFD working group but rather in the IPP working group along with the discussion of IPP, IPP Everywhere and Cloud Printing.  I request that this issue be added to your IPP teleconference agenda.

Thanks,

Pete

Original note:

Hi,

Would it also be possible to add some sort of parent job UUID list/hierarchy? So it will be possible to track source/parent jobs after splitting a job into several jobs.

For example (maybe not the best, but..):

Imagine I have a company internal print cloud, to which I submit the jobs. This cloud could forward jobs to other external clouds, based on location (one provider for US, another for EU,…), cost or other parameters.

So if I need to print a marketing document in both US and EU, I could submit the job to a special queue in the company cloud, which again would submit 1 copy to my local DeskJet printer, submit a new job with 10000 copies to the external EU print/cloud partner and another 10000 to the US partner.

In this example, the jobs at the two external clouds, better not have the same UUID if I need to track them. But I would still need the “root job” UUID for doing accounting.

Hope this makes sense,

Christoph Lindemann

MFD Meeting minutes on the subject:

1.      Discuss Parent Job UUID

·         Christoph briefly described the use case for cloud print he sent previously in IPP Working Group list. The use case requires the parent job identification besides Job UUID for tracking a job sent from a originating cloud to two other cloud print services because of job size, cost, print service location,… etc.

·         It was clarified that although the given use case only involved one parent job, a parent job in the cloud could be fanned-in from other multiple parent jobs and could be further fanned out to multiple other clouds as multiple child jobs.

·         Pete pointed out that although UUID is globally unique, its encoding is meaningless and not very useful for job tracking purpose. Thus a list of pairs of parent-child URIs was preferred for representing a sequence of job’s fan-in/fan-out performed in the cloud.

·         Since a job to be fanned in or fanned out could be completed, or in stopped or pending state depending on how the cloud print service job processing is implemented, an additional job state reason “fan-in/fan-out” is required for these states. The client should also be notified when the very last page of his job is finally printed.

·         Since job fan-in/fan-out is a service property, there is a need for an attribute in Service Capabilities to indicate whether and how this can be supported by a service, e.g. based on job size, cost, …, etc., which could affect chaining of jobs and services.

·         Today in IPP there exist partially stopped/partially successful state reasons. IPP is also completely extensible. Hence near-term use of such can be added without problem.

·         In cloud print service, it is recommended that fan-out is always assumed for failed job recovery purpose. However, this is out of scope in MFD model. But there is nothing in the current model that prevents implementation of this feature.

·         Agreed that the discussion of this subject today should be forwarded to the IPP working group for future IPP Everywhere and Cloud Print discussions.

o   AI: Pete to forward today’s discussion to the IPP working group.

Dear all,

I am Mac Matsuda who works for Brother International Corporation, USA.

As Kiyotaka O’Hara san sent his introduction email recently, We are happy to join the WG.

I am looking forward to seeing you soon.

Best regards,

Mac

------------------------------------------
 Mac Matsuda
 Brother International Corp. USA

 mailto:mac.matsuda <at> brother.com
 Tel:1-908-575-3734/ Cell:1-908-906-1312