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

Hastings, Tom N hastings at
Tue Mar 18 14:58:14 EST 2003

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: 

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
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):

MODEL:LaserBeam 9;
COMMENT:Anything you like;
(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;



-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at]
Sent: Tuesday, March 18, 2003 07:53
To: 'Zehler, Peter'; 'HALL,DAVID (HP-Vancouver,ex1)'; Hastings, Tom N
Cc: sm at
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.

- Ira McDonald

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


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.


				Peter Zehler
				Xerox Architecture Center
				Email: PZehler at
				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]
Sent: Monday, March 17, 2003 1:55 PM
To: 'Hastings, Tom N'
Cc: sm at
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:


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


-----Original Message-----
From: Hastings, Tom N [mailto:hastings at]
Sent: Friday, March 14, 2003 6:00 PM
To: CIP4 Capabilities WG [capabilities at]
Cc: sm at
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


More information about the Sm mailing list