Section 5.5 Linked MULTI-ROW Values, 3rd and 4th lines both have "shape".
Delete one of them.
>X-Sender: hastings@garfield
>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
>Date: Thu, 25 Jun 1998 13:56:44 -0700
>To: rbergma@dpc.com, Harry Lewis <harryl@us.ibm.com>
>From: Tom Hastings <hastings@cp10.es.xerox.com>
>Subject: Comments on the FIN MIB - will be forwarded when PWG server up
>Cc: imcdonal@eso.mc.xerox.com (Ira Mcdonald), hastings
>
>Ron and Harry,
>
>We just completed a company-wide review of the Finisher MIB. It stood up
>well.
>
>Here are the comments:
>
>1. Fix the compile errors that Ira will send.
>
>
>2. Add two attributes to allow the agent to indicate the fixed sequential
>order of finishing, when there is an ordering. Then replace the
>following sentence on page 11, just before 4.1:
>
> The Finisher MIB does not provide information regarding the order
> that operations can be performed.
>
>with:
>
> The Finisher MIB permits an agent to describe the order that operations
> can be performed.
>
>Add the two generic attributes:
>
> finPreviousFinishingOperation(19), Integer32 (0..65535)
> INTEGER: Defines the finDeviceIndex of the previous finishing operation
> for implementations in which the finishing operations are performed in
> a prescribed order. Each finishing operation in the fixed seqence is
> either performed or not performed according to the finishing
instructions
> submitted with the job. A value of 0 indicates that this finishing
> operation is the first in a sequence. Finishing operations which are
> not part of a fixed sequence SHALL not have this attribute.
>
> finNextFinishingOperation(20), Integer32 (0..65535)
> INTEGER: Defines the finDeviceIndex of the next finishing operation
> for implementations in which the finishing operations are performed in
> a prescribed order. Each finishing operation in the fixed seqence is
> either performed or not performed according to the finishing
instructions
> submitted with the job. A value of 0 indicates that this finishing
> operation is the first in a sequence. Finishing operations which are
> not part of a fixed sequence SHALL not have this attribute.
>
>
>3. Figure 1 and 2: some people are having trouble distinguishing the edge
>of the medium from all the other lines. How about using a distinguishing
>character, such as # for all four edges of the medium? Still keep + for
>the corners.
>
>
>4. Need to clarify that the 'X' axis is always along the short
>edge of the medium and the 'Y' axis is always along the long edge of the
>medium, regardless of the orientation of the printer image or the direction
>of feed. You might want to add an i.e. to the end of the second sentence of
>Media Orienation on page 5, so that it would read:
>
>The 'X' and 'Y' axis, therefore, will always reference the medium as shown
>in figure 1 and 2, i.e., with the 'X' axis always along the short edge and
>the 'Y' axis always along the long edge.
>
>
>5. Page 30, line 23, finSupplyEntry: there is a bug in the INDEX clause:
>
>Change finDeviceIndex to finSupplyIndex to go with the in-accessible
>object.
>
>
>6. Page 32, finSupplyColorantValue: the name is confusing, since the
>Finisher isn't applying color. How about using the first words in the
>defintion from the Printer MIB: "color name"?
>
>So change the name from finSupplyColorantValue to finSupplyColorName.
>
>
>7. Change 40, delete finSuppplyMediaInputGroup from the MANDATORY-GROUPS
>clause, since page 33 says its Conditionally Mandatory in the header.
>
>
>8. ISSSU: The Finisher Device Attribute Group is listed in the
>MANDATORY-GROUPS on page 40, which is fine. But need to say MANDATORY
>on page 37 as well.
>
>I assume that making it MANDATORY is not much of a burden, since the table
>doesn't need to contain any attributes, correct?
>
>Alternatively, we could make it CONDITIONALLY MANDATORY, but then we need
>to write a condition on page 37 that makes the table MANDATORY, as is done
>for the finSupplyMediaInput group/table.
>
>Thanks,
>Tom
>
>
>
>
>
>
>
>