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@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@hp.com]
Sent: Monday, March 17, 2003 1:55 PM
To: 'Hastings, Tom N'
Cc: sm@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@cp10.es.xerox.com]
Sent: Friday, March 14, 2003 6:00 PM
To: CIP4 Capabilities WG [capabilities@cip4.org]
Cc: sm@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
This archive was generated by hypermail 2b29 : Tue Mar 18 2003 - 10:30:54 EST