Here is the definition of the "document-format-device-id" proposed in the
Document object spec:
This OPTIONAL Document Description attribute identifies the type of device
for which the document was formatted, including manufacturer and model.
This attribute is intended to identify document formats that are not
portable, e.g., PDLs that are device dependent. The value of this variable
MUST exactly match the IEEE 1284-2000 Device ID string (see [IEEE1284]
clause 6), except the length field MUST not be specified. See the Microsoft
Universal Plug and Play [upnp] section 2.2.6 DeviceId parameter for details
and examples. Here is an example showing only the required fields for a
PostScript document:
MANUFACTURER:ACME Co.;COMMAND SET:PS;MODEL:LaserBeam 9;
And here is the definition of the UPnP DeviceId attribute from the UPnP v1
Printer Template. Note: in UPnP this is a Printer attribute, not an
attribute that the submitter includes with his job submission:
2.6.6 DeviceId
The value of this variable MUST exactly match the IEEE 1284-2000 Device ID
string, except the length field MUST not be specified.. The value is
assigned by the Printer vendor and MUST NOT be localized by the Print
Service.
The IEEE 1284-2000 Device ID is a length field followed by a case-sensitive
string of ASCII characters defining peripheral characteristics and/or
capabilities. For the purposes of this specification, the length bytes MUST
NOT be included. The Device ID sequence is composed of a series of keys and
values of the form:
key: value {,value} repeated for each key
As indicated, each key will have one value, and MAY have more than one
value. The minimum necessary keys (case-sensitive) are MANUFACTURER,
COMMAND SET, and MODEL. (These keys MAY be abbreviated as MFG, CMD, and MDL
respectively.) Each implementation MUST supply these three keys and possibly
additional ones as well. Each key (and each value) is a string of
characters. Any characters except colon (:), comma (,), and semi-colon (;)
MAY be included as part of the key (or value) string. Any leading or
trailing white space (SPACE[x'20'], TAB[x'09'], VTAB[x'0B'], CR[x'0D'],
NL[x'0A'], or FF[x'0C']) in the string is ignored by the parsing program
(but is still counted as part of the overall length of the sequence).
An example ID String, showing optional comment and active command set keys
and their associated values (the text is actually all on one line):
MANUFACTURER:ACME Manufacturing;
COMMAND SET:PCL,PJL,PS,XHTML-Print+xml;
MODEL:LaserBeam 9;
COMMENT:Anything you like;
ACTIVE COMMAND SET:PCL;
(See IEEE 1284-2000 clause 7.6)
Note: One of the purposes of the DeviceId variable is to select a printer
driver for those UCPs that need a printer driver. The values of the COMMAND
SET key are interpreted by the printer driver provided by the vendor and so
are vendor-defined, rather than being standardized.
TH Observations:
1. The Note is part of the definition of the UPnP DeviceId Printer attribute
showing the intent to relate to the driver needed.
2. Because the keyword fields also have shorter forms, the string:
MFG:ACME Manufacturing;CMD:PCL,PJL,PS,XHTML-Print+xml;MDL:LaserBeam 9;
is also conforming for the UPnP DeviceId Printer Attribute.
3. This alternate form for the keyword fields means that the Printer will
either have to include both forms in its
"document-format-device-id-supported" Printer attribute (if we decide to
have one) or have a more sophisticated matching algorithm.
4. The UPnP DeviceId attribute is a Printer Attribute that describes the
Printer's capabilities. Unlike the IPP "document-format-device-id", the
UPnP DeviceId attribute is not submitted by the clent to tell the printer
what the document format is that the client is submitting.
5. For our use as an attribute that the client submits as a value of
"document-format-device-id", presumably there would only be one value of the
COMMAND SET, e.g.,: MFG:ACME Manufacturing;CMD:PS;MDL:LaserBeam 9;
Right?
Tom
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Tuesday, March 18, 2003 07:53
To: 'Zehler, Peter'; 'HALL,DAVID (HP-Vancouver,ex1)'; 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
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@crt.xerox.com]
Sent: Tuesday, March 18, 2003 9:31 AM
To: 'HALL,DAVID (HP-Vancouver,ex1)'; 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
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 - 14:58:35 EST