And a 10th issue for the Document Object spec:
10. At today's IPPFAX telecon, we discussed the following IPPFAX Printer
Description attribute:
digital-signatures-supported (1setOf type2 keyword)
This attribute identifies which digital signatures technologies are
supported by the Receiver. A Receiver MUST support this Printer Description
attribute.
TODO: Get list of keywords; can be found in "IPP driver install" spec
We agreed that it should go in the IPP Document object spec, and that it
should have a "digital-signature" (type2 keyword) operation/Document
Description attribute that the client submits in a Document Creation
operation as well. And therefore, the spelling of the corresponding
"digital-signature-supported" (1setOf type2 keyword) Printer Description
attribute should be without the "s".
The description from the "IPP Driver Install" (IPP Printer Installation
Extension) spec is:
"digital-signature"
One REQUIRED LOWER-CASE 'keyword' string identifying the mechanism used to
ensure the integrity and authenticity of this set of Client Print Support
Files. Standard values are: 'smime', 'pgp', 'dss', and 'xmldsig' which are
defined in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively. In
addition, the special keyword value: 'none' is valid.
The 'none' value MUST be supported if this attribute is supported.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, April 01, 2003 18:46
To: sm@pwg.org
Cc: ps@pwg.org
Subject: SM> Summary of 9 recent ISSUES/fixes for the IPP Document
object tele con, Thur, 4/3/03, 12-3 EST (9-12 PST)
The 2nd and 3rd hours will be reviewing the IPP Document Object spec (sent
out March 25:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.pdf.zip
(1,225 KB)
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324.doc.zip
(294 KB)
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.pdf.zip
(649 KB)
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030324-rev.doc.zip
(309 KB)
This note summarizes the suggestions that have been and issues raised since
the document was sent out, including discussions in CIP4 about the
JDF/FileSpec resource and the SM telecon March 27.
The first part of this mail note is a summary of the issues and point to
earlier mail messages that are appended for more detail and rationale.
1. Close-Job operation needs the same timeout Printer requirements as RFC
2911 has for Send-Document.
2. Remove "document-id-uri" Document Description attribute. PSI agreed last
week that they can use the IPP "document-number" (integer(1:MAX)) Document
Description attribute to identify documents within a job.
3. Add a "document-format-version" (text(127)) operation/Document
Description attribute with self-identifing values, such as 'PS/3.0',
'PCL/5e', 'PDF/1.4', 'PDF/X-1a:2001' (See ISSUES 01 and 02 below for more
details). The prefix is from the Printer MIB langTC values used in the
prtInterpretedLangFamily object and the version after the "/" can be used in
the Printer MIB prtInterpreterLangLevel object.
4. Add a "document-format-version-default" (text(127)) and
"document-format-version-supported" (1setOf text(127)) Printer Description
attributes to describe the default and supported values. (See ISSUES 03
below for more details).
So "document-format-version" and "document-format" would have parallel
semantics, including also being member attributes of
"document-format-details" (1setOf collection).
5. ISSUE 04 (repeat of below): Is "document-format-version" a Best Effort
(hint) unless "ipp-attribute-fidelity" = 'true" or
"job-mandatory-attributes" = 'document-format-version' or do we make
"document-format-version" be like "document-format" in that the Printer MUST
reject the job if the Printer doesn't support the version?
6. Put the version strings into a flat text file that implementers and
implementations can access on the PWG FTP site. Adding new values is simply
done whenever they are registered or standardized with some recognized body,
such as IANA, CIP4, ISO, etc.
ISSUE 05: We need to convince CIP4 to use the same flat file for their
FileSpec/@MimeOrFileTypeVersion attribute and/or have each of them shadow
the other.
7. Add a "document-natural-language" (naturalLanguage) operation/Document
Description attribute and a "document-natural-language-supported" (1setOf
naturalLanguage) Printer Description attribute. The
"document-natural-language" operation attribute is already defined in RFC
2911 for use with Print-Job, Send-Document, and Send-URI, so we are just
continuing this RFC 2911 attribute for the Create-Document operation and
making it a Document Description attribute as well, so that it can be
queried. Also keep "document-natural-language" (naturalLanguage) as a
member attribute of "document-format-details" for describing packages.
The "document-natural-language" is needed in order to know how to display
characters that depend on language.
ISSUE 06: What about multiple languages in a single document for the top
level attribute?
ISSUE 06a: What about for the member attribute of "document-format-details"?
8. Add a "document-charset" (charset) operation/Document Description
attribute and a "docuemnt-charset-supported" (1setOf charset) Printer
Descrition attribute. This attribute is needed for the many plain text and
markup languages in which the charset is not embedded in the data. For
example, PCL often doesn't have the charset escape sequence in the data.
Also many files use the various 8-bit ISO 8859 charsets in which the lower
half is US-ASCII and the upper half is various Latin sets (about 8 or 9),
Greek, Cyrllic, Hebrew, and Arabic. Shift JIS is another example where the
left half is US-ASCII, but the right half can be one of a number of things.
But if the data doesn't contain the charset escape sequences, this attribute
can help the Printer know what the charset is in the Document.
9. There is one issue embedded in the Document Object spec:
6.1.2.2 document-creator-application-version (text(127))
This OPTIONAL member Operation attribute identifies the version number of
the application that created the document. The intent of this attribute is
for display to a human being, rather than being parsed by the Printer for
purpose of affecting the interpreting by the Printer and so may also include
the name of the application, as well as build or service pack numbers.
Examples:
"WinzipÒ 8.1 (4331)", "Acrobat 5.0.5 10/26/2001", "MicrosoftÒ Word 2000
(9.0.4119 SR-1)"
ISSUE: OK that the purpose is human consumption, instead of program
consumption and that it be the same as the application shows in its help
message?
The two other version attribute: "document-format-version" and
"document-format-os-version" are intended for program consumption, not human
consumption. Its possible that CIP4 will want to have both types of
versions for: applications, operating systems, and documet-formats.
Tom
Here is last week's thread with more details:
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Wednesday, March 26, 2003 15:05
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> More improvements to the IPP "document-format-version" and
JDF Mi meOrFileTypeVersion attributes [4 ISSUES]
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 Apr 02 2003 - 21:23:46 EST