Ira and I had even further thoughts about the IPP "document-format-version"
(wihch don't affect the corresponding JDF MimeOrFileTypeVersion attributes
since it is a top level attribute in the FileSpec resource):
The proposal from yesterday is to make the values of IPP
"docuent-format-version" and JDF MimeOrFileTypeVersion attributes be
self-identifying, because they start with a prefix that identifies the
format: "PDF/", "PS/", "PCL/", "TIFF/IT-", "DCS/", "MSWORD/", etc.
ISSUE 01: OK to add the prefix values as proposed yesterday to the IPP
"docuent-format-version" and JDF MimeOrFileTypeVersion attributes to make
the values self identifying indendent of the correspoding IPP
"document-format" and JDF MimeType attributes?
Today's further thought is that we can now promote the IPP
"document-format-version" member Operation attribute back to being a top
level Document object attribute to accompany the existing "document-format"
Operation attribute. This is because "document-format-version-supported"
attribute now makes sense as a Printer Descrition attribute on its own,
since the values would be things like:
"PDF/1.3", "PDF/X-1:2001", "PS/3", "PCL/5e", "TIFF/IT-FP/P1:1998",
"DCS/2.0", "MSWORD/2000" and don't need to be paired up with the
correspoding "document-format-supported" Printer attribute values:
"applicaition/pdf", "application/postscript", "application/vnd.hp-PCL", and
"application/msword" MIME type values.
ISSUE 02: OK to add a "document-format-version" operation and Document
Description attribute to the IPP Document object spec?
Just like the "document-format" Operation attribute which is also a member
attribute of the "document-format-details" (1setOf collection)
Operation/Document Description attribute, we'd keep
"document-format-version" as a member attribute as well with the same
prefixed values.
This now means that "document-format" and "document-format-version" have all
parallel construction:
a. They are both operation attributes.
b. They both have correspoding Document Description attributes that the
Printer copies to.
c. They both have "xxx-supported" Printer attributes.
d. There is a "document-format-default" which now can have a corresponding
"document-format-version-default" Printer attribute.
ISSUE 03: OK to add "document-format-default" printer attribute?
e. The Printer MUST reject the request if the "document-format" isn't
supported.
ISSUE 04: Do we want to make the same rule for the
"document-format-version" or keep it as a Best Effort, unless the client
supplies "ipp-attribute-fidelity"='true' or
"job-mandatory-attributes"='document-format-version'?
Comments?
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, March 25, 2003 14:32
To: sm@pwg.org; ps@pwg.org
Cc: CIP4 System Behaviour and Interoperability WG
[system_behaviour@cip4.org]; CIP4 Capabilities WG
[capabilities@cip4.org]
Subject: SM> Improvements of the IPP "document-format-version" and JDF
MimeOfF ileTypeVersion attributes
Today on the FSG Job Ticket API, Ira, Claudia, Till, and I were discussion
the current IPP "document-format-version" attribute in the IPP Document
Object spec Working Draft, dated March 24, 2003 and the JDF
MimeOfFileTypeVersion attribute in the JDF FIleSpec proposal, dated March
21, 2003.
This mail note has two specific proposals:
1. Put the version strings into a flat file that can be updated and used by
implementers. The respective specs can have an initial sets of strings for
the flat file.
2. Make the verson strings self-identifying.
Both of these specs are to be discussed on Thursday, March 27, (PWG Semantic
Model WG and CIP4 System Behaviour and Interoperability WG).
The current text for the IPP "document-format-version" attribute is:
6.1.2.7 document-format-version (text(127))
This REQUIRED member Operation attribute contains the level or version of
the document format identified by the "document-format" member attribute.
The client MAY supply and the Printer MUST support this member attribute.
Possible values are the same as the Printer MIB [rfc1759]
prtInterpreterLangLevel (not prtInterpreterLangVersion), such as:
'3': For Postscript level 3 [rfc1759].
'5e': For PCL 5e [rfc1759].
Other example values are for those document formats that have well-defined
version identification, either in the specification or as an actual field in
the document content, such as::
'PDF/X-1:2001': For PDF/X-1 [iso15930]. "?
'PDF/X-1.2001': For PDF/X-1a [iso15930]
'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page -
baseline.
'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone
picture data - baseline
'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page -
profile 1
'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone
picture data - profile 1
The current text for the JDF MimeOfFileTypeVersion attribute is:
The level or version of the file format identified by MimeType or, FileType.
Some example values are the same as the Printer MIB [rfc1759]
prtInterpreterLangLevel, such as:
"1", "2", "3" for MimeType = "application/postscript"
"3", "4", "5", "5e" for MimeType = "application/vnd.hp-PCL"
Other example values are for those document formats that have well-defined
version identification, either in the specification or as an actual field in
the document content, such as:
"5.0", "6.0", "2000", "XP" for MimeType = "application/msword"
"1.3", "1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType =
"application/pdf"
"2.0" for FileType = "DCS"
"???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC
Profiles?
"TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType =
"TIFF/IT"
See Appendix A.1 "FileSpec Resource examples for MimeType, FileType,
MimeOrFileTypeVersion attributes" for additional examples in common use by
JDF applications.
The two suggestions for improvement is:
1. Put the version strings into a flat file so that implementers can get
them, so that new values can be added to easily, after appropriate review,
without having to republish either the IPP Document Object spec or the CIP4
JDF spec.
ISSUE: Whether both the PWG and CIP4 would have their own flat files that
they would co-ordinate is an issue to be discussed.
2. The version string should be self identifying, e.g., PDF/1.3, not just
1.3, PS/3, not just 3, PCL/5e, not just 5e. And to build more on the
Printer MIB, RFC 1759 (and soon to be published Printer MIBv2) use both the
Language Family and the Language Level attributes for the version. The
Language Families for PostScript is PS, for PCL is PCL, for PDF is PDF.
In the Printer MIB there are two attributes (MIBs call them "objects"):
prtInterpreterLangFamily OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtInterpreterLangFamilyTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The family name of a Page Description Language (PDL) or
control language which this interpreter in the printer can
interpret or emulate.
NOTE: The above description has been modified from RFC 1759
for clarification."
prtInterpreterLangLevel OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..31))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The level of the language which this interpreter is
interpreting or emulating. This might contain a value like
'5e'for an interpreter which is emulating level 5e of the PCL
language. It might contain '2' for an interpreter which is
emulating level 2 of the PostScript language. Similarly it
might contain '2' for an interpreter which is emulating level 2
of the HPGL language."
The prtInterpreterLangFamily has a Textual Convention for the assignment of
about 62 printer languages. The symbolic names are of the form: langXxxx
For example there are the following:
langPCL(3), -- PCL. Starting with PCL version 5,
-- HP-GL/2 is included as part of the
-- PCL language.
-- PCL and HP-GL/2 are registered
-- trademarks of Hewlett-Packard
-- Company.
langHPGL(4), -- Hewlett-Packard Graphics Language.
-- HP-GL is a registered trademark of
-- Hewlett-Packard Company.
langPJL(5), -- Peripheral Job Language. Appears in
-- the data stream between data intended
-- for a page description language.
-- Hewlett-Packard Co.
langPS(6), -- PostScript (tm) Language
-- Postscript - a trademark of Adobe
-- Systems Incorporated which may be
-- registered in certain jurisdictions
langIPDS(7), -- Intelligent Printer Data Stream
-- Bi-directional print data stream for
-- documents consisting of data objects
-- (text, image, graphics, bar codes),
-- resources (fonts, overlays) and page,
-- form and finishing instructions.
-- Facilitates system level device
-- control, document tracking and error
-- recovery throughout the print
-- process.
-- IBM Corporation.
...<middle section deleted>
langPDF(54), -- Not in RFC 1759
-- Adobe Portable Document Format
-- Adobe Systems, Inc.
langRPDL(55), -- Not in RFC 1759
-- Ricoh Page Description Language for
-- printers.
-- Technical manual "RPDL command
-- reference" No.307029
-- RICOH, Co. LTD
langIntermecIPL(56), -- Not in RFC 1759
-- Intermec Printer Language for label
-- printers.
-- Technical Manual: "IPL Programmers
-- Reference Manual"
-- Intermec Corporation
langUBIFingerprint(57), -- Not in RFC 1759
-- An intelligent basic-like programming
-- language for label printers.
-- Reference Manual: "UBI Fingerprint
-- 7.1", No. 1-960434-00
-- United Barcode Industries
langUBIDirectProtocol(58), -- Not in RFC 1759
-- An intelligent control language for
-- label printers.
-- Programmers guide: " UBI Direct
-- Protocol", No. 1-960419-00
-- United Barcode Industries
langFujitsu(59), -- Not in RFC 1759
-- Fujitsu Printer Language
-- Reference Manual:
-- "FM Printer Sequence" No. 80HP-0770
-- FUJITSU LIMITED
langCGM(60), -- Not in RFC 1759
-- Computer Graphics Metafile
-- MIME type 'image/cgm'
langJPEG(61), -- Not in RFC 1759
-- Joint Photographic Experts Group
-- MIME type 'image/jpeg'
langCALS1(62), -- Not in RFC 1759
-- US DOD CALS1 (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
langCALS2(63), -- Not in RFC 1759
-- US DOD CALS2 (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
langNIRS(64), -- Not in RFC 1759
-- US DOD NIRS (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
langC4(65) -- Not in RFC 1759
-- US DOD C4 (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
So take the prtInterpreterLangFamily textual convention after the "lang",
follow it with a "/" and then have the prtInterpreterLangLevel.
So the updated IPP "document-format-version" member attribute would become:
6.1.2.7 document-format-version (text(127))
This REQUIRED member Operation attribute contains the level or version of
the document format identified by the "document-format" member attribute.
The client MAY supply and the Printer MUST support this member attribute.
Possible values are the same as the Printer MIB [rfc1759]
prtInterpreterLangFamily textual convention (minus the "lang" prefix) and
prtInterpreterLangLevel (not prtInterpreterLangVersion) separated by a "/",
such as:
'PS/3': For Postscript level 3 [rfc1759].
'PCL/5e': For PCL 5e [rfc1759].
Other example values are for those document formats that have well-defined
version identification, either in the specification or as an actual field in
the document content, such a:
'PDF/X-1:2001': For PDF/X-1 [iso15930]. "?
'PDF/X-1.2001': For PDF/X-1a [iso15930]
'TIFF/IT-FP:1998': TIFF/IT [iso12639] - Full Page -
baseline.
'TIFF/IT-CT:1998': TIFF/IT [iso12639] - Continuous Tone
picture data - baseline
'TIFF/IT-FP/P1:1998': TIFF/IT [iso12639] - Full Page -
profile 1
'TIFF/IT-CT/P1:1998': TIFF/IT [iso12639] - Continuous Tone
picture data - profile 1
See PWG www.pwg.org [need URL] for a flat file list of the version strings
currently recognized for use in the PWG Semantic Model and derivative
protocols, such as IPP and PSI.
and the updated JDF MimeOrFileTypeVersion attribute would become:
The level or version of the file format identified by MimeType or, FileType.
Some example values are the same as the Printer MIB [rfc1759]
prtInterpreterLangFamily textual convention (minus the "lang" prefix) and
prtInterpreterLangLevel, such as:
"PS/1", "PS/2", "PS/3" for MimeType = "application/postscript"
"PCL/3", "PDL/4", "PCL/5", "PCL/5e" for MimeType = "application/vnd.hp-PCL"
Other example values are for those document formats that have well-defined
version identification, either in the specification or as an actual field in
the document content, such as:
"MSWORD/5.0", "MSWORD/6.0", "MSWORD/2000", "MSWORD/XP" for MimeType =
"application/msword"
"PDF/1.3", "PDF/1.4", "PDF/X-1:2001", "PDF/X-1a:2001" for MimeType =
"application/pdf"
"DCS/2.0" for FileType = "DCS"
"???" for FileType = "ICC Profile" ISSUE (Ann): What versions for ICC
Profiles?
"TIFF-IT/FP:1998", "TIFF-IT/CT:1998", "TIFF-IT/LW:1998" for FileType =
"TIFF/IT"
See CIP4 www.cip4.org [need URL] for the flat text file that contains the
version strings currently recognized for the "FileSpec Resource attributes:
MimeType, FileType, MimeOrFileTypeVersion in common use by JDF applications.
Comments?
Tom
This archive was generated by hypermail 2b29 : Wed Mar 26 2003 - 18:05:25 EST