Typos:
Section 5.5 Linked MULTI-ROW Values, 3rd and 4th lines both have "shape".
Delete one of them.
>X-Sender: hastings at garfield>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
>Date: Thu, 25 Jun 1998 13:56:44 -0700
>To: rbergma at dpc.com, Harry Lewis <harryl at us.ibm.com>
>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: Comments on the FIN MIB - will be forwarded when PWG server up
>Cc: imcdonal at 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
>>>>>>>>