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

McDonald, Ira imcdonald at sharplabs.com
Tue Mar 18 10:52:54 EST 2003


Hi Pete,

Agreed - specifically, Bob Taylor (HP strong voice for document details)
has urged the use of DeviceID as the unambiguous identifier.

Admittedly that's no help to actually find the driver install for human
beings, but that's a separate problem, I think.

Cheers,
- Ira McDonald


-----Original Message-----
From: Zehler, Peter [mailto:PZehler at crt.xerox.com]
Sent: Tuesday, March 18, 2003 9:31 AM
To: 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N
Cc: sm at pwg.org
Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document
obj ect for document format versions


Dave,

I was under the impression that the reason for defining DeviceId was to
establish an unambiguous mapping of a Printer and its associated driver.
IPP v1.0 and 1.1 used PrinterMakeAndModel.  UPnP felt that that mapping was
not sufficiently defined and ambiguous.  The IEEE P1284 device registry was
utilized with the definition of DeviceId.

I believe that the DeviceId provides a more direct and convenient mapping to
printer's device driver.  It also includes the make and model in a well
defined format.  I recommend that we do not include PrinterMakeAndModel in
the list below.

Pete

				Peter Zehler
				XEROX
				Xerox Architecture Center
				Email: PZehler at crt.xerox.com
				Voice:    (585) 265-8755
				FAX:      (585) 265-8871 
				US Mail: Peter Zehler
					        Xerox Corp.
					        800 Phillips Rd.
					        M/S 128-30E
					        Webster NY, 14580-9701



-----Original Message-----
From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall at hp.com]
Sent: Monday, March 17, 2003 1:55 PM
To: 'Hastings, Tom N'
Cc: sm at pwg.org
Subject: RE: SM> Summary of additions to JDF/FileSpec and IPP Document
obj ect for document format versions


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