draft-ietf-ipp-finishings-fold-trim-bale-00.txt [plain text]
INTERNET-DRAFT
<draft-ietf-ipp-finishings-fold-trim-bale-00.txt>
T. Hastings
Xerox Corporation
D. Fullman
Xerox Corporation
October 20, 1999
Internet Printing Protocol/1.1: "finishings" 'fold', 'trim', and 'bale'
attribute values extension
Copyright (C) The Internet Society (1999). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html.
Abstract
This document specifies the additional enum values 'fold', 'trim', and
'bale' for the IPP/1.1 "finishings" Job Template attribute for use with
the Internet Printing Protocol/1.1 (IPP) [ipp-mod, ipp-pro]. This
attribute permits the client to specify additional finishing options,
including values that include a specification of a coordinate system for
the placement of finishings operation with respect to the corners and
edges of portrait and landscape documents.
T. Hastings, D. Fullman [page 1]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [ipp-mod]
Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that are
satisfied in IPP/1.0. A few OPTIONAL operator operations have been
added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" document describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP
specification documents, and gives background and rationale for the IETF
working group's major decisions.
The "Internet Printing Protocol/1.1: Encoding and Transport" document is
a formal mapping of the abstract operations and attributes defined in
the model document onto HTTP/1.1 [RFC2616]. It defines the encoding
rules for a new Internet MIME media type called "application/ipp". This
document also defines the rules for transporting over HTTP a message
body whose Content-Type is "application/ipp". This document defines a
new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
insight and advice to implementers of IPP clients and IPP objects. It
is intended to help them understand IPP/1.1 and some of the
considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the
specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
T. Hastings, D. Fullman [page 2]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
TABLE OF CONTENTS
1 Additional values for the "finishings" Job Template attribute......4
1.1 Problem.........................................................4
1.2 Suggested solution..............................................4
1.3 Proposed Text...................................................5
1.3.1Coordinate system for enum values............................6
2 IANA Considerations................................................7
3 Security Considerations............................................7
4 References.........................................................7
5 Author's Addresses.................................................8
6 Full Copyright Statement...........................................9
T. Hastings, D. Fullman [page 3]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
1 Additional values for the "finishings" Job Template attribute
1.1 Problem
Need additional enum values for finishing to specify which of four
corners to put a single staple, which of four edges to put two staples,
and generic values for the following: fold, trim, bale, saddle stitch
and edge stitch.
1.2 Suggested solution
This solution has been proposed at two previous meetings with comments
returned and incorporated. The suggestion is to add additional enum
values to the "finishings" Job Template attributes (also applies to
"finishings-default" and "finishings-supported" attributes).
Coordination with the Finisher MIB has been done. There appears to be
no direct way to use the same enum values, since the Finisher MIB
divides up finishing into separate enum values by type. So all the
stapling is done as a separate enum. Also all the punching is done as a
separate enum.
The coordinate system scheme has been selected to agree with the
Finisher MIB which in turn follows the ISO DPA approach of using a
coordinate system as if the document were portrait. The approach for
coordinate system being relative to the intended reading direction
depends on the device being able to understand the orientation embedded
in the PDL, which is too problematic for many PDLs. The approach for
the coordinate system of being relative to the media feed direction is
to dependent on the way the device is currently set up, i.e., pulling
short edge first vs. long edge first, and can vary between different
output-bins in the same device.
Additional (new) keyword symbolic names of these enum values are:
fold
trim
bale
Although not a part of this specification, more specific values for
saddle-stitch and fold could be considered once adequate definitions
have been developed. Some examples are:
saddle-stitch-single-long
saddle-stitch-single-short
saddle-stitch-dual-long
saddle-stitch-dual-short
fold-in-half-long
fold-in-half-short
fold-in-thirds-long
fold-in-thirds-short
T. Hastings, D. Fullman [page 4]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
fold-z-long
fold-z-short
1.3 Proposed Text
Add the following paragraphs indicated with revision marks to the
description of the "finishings" Job Template attribute, section 4.2.6,
so that the entire section would be:
4.2.6 finishings (1setOf type2 enum)
This attribute identifies the finishing operations that the Printer uses
for each copy of each printed document in the Job. For Jobs with
multiple documents, the "multiple-document-handling" attribute
determines what constitutes a "copy" for purposes of finishing.
Standard enum values are:
Value Symbolic Name and Description
'3' 'none': Perform no finishing
'4' 'staple': Bind the document(s) with one or more staples. The
exact number and placement of the staples is site-
defined.
'5' 'punch': This value indicates that holes are required in the
finished document. The exact number and placement of the
holes is site-defined The punch specification MAY be
satisfied (in a site- and implementation-specific manner)
either by drilling/punching, or by substituting pre-
drilled media.
'6' 'cover': This value is specified when it is desired to select
a non-printed (or pre-printed) cover for the document.
This does not supplant the specification of a printed
cover (on cover stock medium) by the document itself.
'7' 'bind': This value indicates that a binding is to be applied
to the document; the type and placement of the binding is
site-defined.
'8' 'saddle-stitch': Bind the document(s) with one or more
staples (wire stitches) along the middle fold. The exact
number and placement of the staples and the middle fold
is implementation and/or site-defined.
'9' 'edge-stitch': Bind the document(s) with one or more staples
(wire stitches) along one edge. The exact number and
placement of the staples is implementation and/or site-
defined.
'10' 'fold': Fold the document(s) with one or more folds. The
exact number and orientations of the folds is
implementation and/or site-defined.
'11' 'trim': Trim the document(s) on one or more edges. The exact
number of edges and the amount to be trimmed is
implementation and/or site-defined.
T. Hastings, D. Fullman [page 5]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
'12' 'bale': Bale the document(s). The type of baling is
implementation and/or site-defined.
'13'-'19' reserved for future generic finishing enum values.
The following values are more specific stapling and stitching values;
they indicate a corner or an edge as if the document were a portrait
document (see section 1.3.1):
'20' 'staple-top-left': Bind the document(s) with one or more
staples in the top left corner.
'21' 'staple-bottom-left': Bind the document(s) with one or more
staples in the bottom left corner.
'22' 'staple-top-right': Bind the document(s) with one or more
staples in the top right corner.
'23' 'staple-bottom-right': Bind the document(s) with one or more
staples in the bottom right corner.
'24' 'edge-stitch-left': Bind the document(s) with one or more
staples (wire stitches) along the left edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'25' 'edge-stitch-top': Bind the document(s) with one or more
staples (wire stitches) along the top edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'26' 'edge-stitch-right': Bind the document(s) with one or more
staples (wire stitches) along the right edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'27' 'edge-stitch-bottom': Bind the document(s) with one or more
staples (wire stitches) along the bottom edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'28' 'staple-dual-left': Bind the document(s) with two staples
(wire stitches) along the left edge.
'29' 'staple-dual-top': Bind the document(s) with two staples
(wire stitches) along the top edge.
'30' 'staple-dual-right': Bind the document(s) with two staples
(wire stitches) along the right edge.
'31' 'staple-dual-bottom': Bind the document(s) with two staples
(wire stitches) along the bottom edge.
'32'-'79' reserved for future specific stapling, stitching and
folding enum values.
1.1.11.3.1Coordinate system for enum values
The values, for which the symbolic name contains "top", "bottom", "left"
and "right", are specified with respect to the document as if the
document were a portrait document. If the document is actually a
landscape or a reverse-landscape document, the client supplies the
appropriate transformed value. This applies to values such as 'staple-
xxx' and 'edge-stitch-xxx'. For example, to position a staple in the
upper left hand corner of a landscape document when held for reading,
the client supplies the 'staple-bottom-left' value (since landscape is
defined as a +90 degree rotation from portrait, i.e., anti-clockwise).
On the other hand, to position a staple in the upper left hand corner of
T. Hastings, D. Fullman [page 6]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
a reverse-landscape document when held for reading, the client supplies
the 'staple-top-right' value (since reverse-landscape is defined as a -
90 degree rotation from portrait, i.e., clockwise).
The angle (vertical, horizontal, angled) of each staple with respect to
the document depends on the implementation which may in turn depend on
the value of the attribute.
Note: The effect of this attribute on jobs with multiple documents is
controlled by the "multiple-document-handling" job attribute (section
4.2.4) and the relationship of this attribute and the other attributes
that control document processing is described in section 16.3.
If the client supplies a value of 'none' along with any other
combination of values, it is the same as if only that other combination
of values had been supplied (that is the 'none' value has no effect).
2 IANA Considerations
These "finishings" type2 enum attribute values will be published by IANA
according to the procedures in RFC 2566 [rfc2566] section 6.1 with the
following URL:
ftp.isi.edu/iana/assignments/ipp/attribute-values/finishings/fold-
trim-bale.txt
3 Internationalization Considerations
Normally a client will provide localization of the enum values of this
attribute to the language of the user.
4 Security Considerations
This extension poses no additional security threats or burdens than
those in IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [ipp-mod, ipp-pro].
However, implementations MAY support different access control to various
finishing features, depending on the identity of the job submitting
user.
5 References
[ipp-iig]
Hastings, T., Manros, C., "Internet Printing Protocol/1.1: <draft-
ietf-ipp-implementers-guide-v11-00.txt>, work in progress,
September 27, 1999.
T. Hastings, D. Fullman [page 7]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
[ipp-mod]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.1: Model and Semantics", <draft-ietf-
ipp-model-v11-03.txt>, work in progress, June 1999.
[ipp-pro]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.1: Encoding and Transport", <draft-ietf-ipp-protocol-
v11-03.txt>, work in progress, June 1999.
[RFC2565]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2566]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999.
[RFC2567]
Wright, D., "Design Goals for an Internet Printing Protocol", RFC
2567, April 1999.
[RFC2568]
Zilles, S., "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2569]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2639]
Hastings, T., Manros, C., "Internet Printing Protocol/1.0:
Implementer's Guide", RFC 2639, July 1999.
6 Author's Addresses
Tom Hastings
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com
Don Fullman
Xerox Corporation
737 Hawaii St. ESAE 231
T. Hastings, D. Fullman [page 8]
Expires April 20, 2000
INTERNET-DRAFT IPP/1.0: "finishings" extension October 20, 1999
El Segundo, CA 90245
Phone: 310-333-8342
Fax: 310-333-5514
e-mail: dfullman@cp10.es.xerox.com
7 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
T. Hastings, D. Fullman [page 9]
Expires April 20, 2000