SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions

SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions

SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions

HALL,DAVID (HP-Vancouver,ex1) dhall at hp.com
Mon Mar 17 13:55:23 EST 2003


Having just implemented an initial PSI TargetDeviceSupportInterface, another
IPP attribute appears to be very important:

PrinterMakeAndModel

While the DeviceID can be utilized to indirectly determine the appropriate
device data format, it is much more convient to utilize the printer make and
model, if it corresponds to the Printer Driver Name.

I would like to recommend that we consider this attribute for inclusion in
the below list..

Dave

-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Friday, March 14, 2003 6:00 PM
To: CIP4 Capabilities WG [capabilities at cip4.org]
Cc: sm at pwg.org
Subject: SM> Summary of additions to JDF/FileSpec and IPP Document
object for document format versions


We've had a long thread of discussion about the need to indicate the version
of a document format in a job submission along with its MIME type in JDF and
IPP.   In JDF this infomation is represented as attributes in the FileSpec
resource.  In IPP, the PWG Semantic Model (SM) and the Print Service
Interface (PSI), the document format and versions are represented as
Document Description attributes.  In IPP the client submits these as
operation attributes which the Printer copies to the corresponding Document
Description attributes.

Here is a quick summary to see if we are in agreement:

1. Don't add stuff to the IPP Document object that hasn't been asked for,
even though its being added to JDF FileSpec resource.  So IPP will remain a
subset of JDF.  So while adding TransferEncoding (per Israel Viente's
request), DocumentClass (to help distinguish fonts from other files), and
some attribute for use with fonts to designate which organization they are
coming from (which need work) so we don't need MIME types for fonts.

2. The following list show the relationship between IPP Document object and
the JDF FileSpec.  In JDF, only ContainerSummary, IEEE1284DeviceID and
FileFormatVersion are new.  All of the IPP Document attributes are new
except for document-format and document-natural-language:


document-container-summary (collection)           ContainerSummary
  which can contain:
  document-creator-application-name (name(MAX))
  document-creator-application-version (name(MAX))
  document-creator-os-name (name(MAX))
  document-creator-os-version (name(MAX))
  document-format (mimeMediaType)
  document-format-device-id (text(127))
  document-format-version (text(127)
  document-natural-language (naturalLanguage)
document-creator-application-name (name(MAX))     Application
document-creator-application-version (name(MAX))  AppVersion 
document-creator-os-name (name(40))               AppOS
document-creator-os-version (name(40))            OSVersion
document-format (mimeMediaType)                   MimeType 
document-format-detected (mimeMediaType)          N/A
document-format-device-id (text(127))             IEEE1284DeviceId
document-format-version (text(127)                FileFormatVersion
document-natural-language (naturalLanguage)

I'll have an updated spec for IPP Document object out by Monday AM and a
corresponding FileSpec on Monday.

I won't be addressing additional MIME types in these documents.  That is
separate.

Tom



More information about the Sm mailing list