PWG> RE: TFM Svc as strict subset of PSI/1.0

PWG> RE: TFM Svc as strict subset of PSI/1.0

PWG> RE: TFM Svc as strict subset of PSI/1.0

McDonald, Ira imcdonald at
Thu Jun 3 13:57:54 EDT 2004

Hi Harry,
Thanks for your feedback.  Comments on your CONS below:
(1) 'target' versus 'targetDevice'
- I suggest that TFM _remove_ the parameter from CreateJob
  (and any other redundant parameters in PSI operations that we 
- the 'target' is the TFM service, period
(2) New Transform attributes
- Define their names and semantics in the new TFM Service spec
- For OCR, perhaps define an OCR Subunit?? (too specific??)
- Unfortunately, all the current Service default/ready/supported
  attributes are only in the Printer object in the SM schema
- TFM _really_ needs to define 'Transform' and/or 'Service' objects
  that then (oddly) include many attributes where the term 'Printer'
  is meant to be read as 'Service'
- Or we could redefine all those attributes with better names, but
  that is a BIG job
- Definitely, we should not define new IPP/1.1 attributes for
  non-print services
(3) Distinguishing between TFM versus PSI interface
- A TFM Service interface must NOT run on PSI's port 3800, but
  rather (just like IPPFAX) on a brand new IANA-registered port.
- Just like IPPFAX, there is no ambiguity.  You are talking to a 
  TFM port or you are talking to a PSI port.  No mixing, ever.
- 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 at 

-----Original Message-----
From: Harry Lewis [mailto:harryl at]
Sent: Wednesday, June 02, 2004 11:53 PM
To: McDonald, Ira
Cc: 'pwg at'
Subject: Re: TFM Svc as strict subset of PSI/1.0

Ira, first, thanks for sketching the proposal. 

I see pro's and con's to leveraging this much of the existing semantic

1. The document object is directly applicable 
2. The CreateJob, ValidateJob etc. operations are general enough that it
seems appropriate to leverage them rather than define new (similar) ops

1. I REALLY wish PSI had used "target" in place of "targetDevice"
2. Where do we describe the transform specific attributes such as HoldUntil,
  - Are you suggesting we extend IPP Job Template Attributes? 
  - But what if we run into some very transform specific attributes (ex. OCR
3. How does an application discover and/or distinguish between a Transform
Service and a Print Service? 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
IBM Printing Systems

"McDonald, Ira" <imcdonald at> 

05/31/2004 02:48 PM 

"'pwg at'" <pwg at> 

Harry Lewis/Boulder/IBM at IBMUS 

TFM Svc as strict subset of PSI/1.0


Hi folks,                                           Monday (31 May 2004)

PSI/1.0 _already_ supports very precise document transforms, via the
'requestedTargetDeviceDataType :  DocumentFormatDetails' parameter
of the CreateJob method.  This is the _same_ functionality incorporated
into the latest JDF/1.2 spec.  A PSI client uses FetchDocumentDataByPull
or FetchDocumentDataByValue later to retrieve the transformed output.

Thus, here's a proposal to define a PWG Transform Service (TFM) as a
strict _subset_ of PSI/1.0 without Target Devices (and without _any_ new
features or Job/Document elements).  The proposal is summarized by the
commented table of contents from the latest PSI/1.0 draft.

Rationale for proposal, from section 5.5.2 CreateJob of PSI/1.0 spec:

"targetDeviceIdentifier : URI

A URI that defines the Target Device that is to be associated with a
Job.  See definition in section 7.2.


If the client specifies the Print Service's Service Root URL as the
targetDeviceIdentifier, then the Print Service is considered the final
destination, and the Print Service can perform all job processing.  For
example, document transformation."

and later in section 5.5.2:

"requestedTargetDeviceDataType : DocumentFormatDetails

If this parameter is specified, then the Print Service shall transform
the source Document into the data type requested.  If the specified
Target Device does not support the requestedTargetDeviceDataType, the
Print Service shall throw a ProcessingRequestUnsupported exception."


- 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 at

[Transform Service (TFM) subset of PSI/1.0 - per TOC of PSI/1.0]

5 Interface Definition

5.1 PSI Service Root URL
5.2 Negotiating a secure PSI connection

5.3 QueryEndPointsInterface
5.3.1 Interface Usage Examples
5.3.2 QuerySupportedInterfaces
5.3.3 QueryInterfaceDefinition

5.4 ServiceCapabilitiesInterface
5.4.1 Interface Usage Examples
5.4.2 GetTargetDeviceElements -- needed to query TFM Service elements
** delete ** 5.4.3 GetKnownTargetDevices -- TFM Service is only endpoint
5.4.4 ValidateReference

5.5 JobControlInterface
5.5.1 Interface Usage Examples
5.5.2 CreateJob
5.5.3 CloseJob
5.5.4 AddDocumentByReference
5.5.5 AddDocumentByPush
5.5.6 PushDocumentDataDelivered
5.5.7 AddDocumentByValue
5.5.8 GetJobs
5.5.9 GetJobElements
** delete ** 5.5.10 SetJobElements -- passive Jobs only
5.5.11 CancelJob
5.5.12 GetDocuments
5.5.13 GetDocumentElements
** delete ** 5.5.14 SetDocumentElements -- passive Documents only
5.5.15 CancelDocument
5.5.16 FetchDocumentDataByPull -- needed for client to retrieve output
5.5.17 PullDocumentDataFetched -- needed for client to retrieve output
5.5.18 FetchDocumentDataByValue -- needed for client to retrieve output
** delete ** 5.5.19 FetchJobs -- no Target Device support


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Pwg mailing list