Harry,
Thanks for your comments. I've listed the ones that should be issues
to be covered at the meeting next week.
Thanks,
Tom
At 16:50 06/19/97 PDT, Harry Lewis wrote:
>Tom, thanks for getting the v0.82 draft out. Here are my comments on the PDF
>version.
>>1. deviceAlertCode (6) needs pointer to SNMP alert table - See pg. 36.
>>When the device is a printer, the alert code SHALL be the printer alert code.
>This is the current definition. But, this is not very effective when
>genericAlertCodes are used. An index into the
>alert table would provide more information (rather than just JAM, you'd know
>jam in Input 3, for
>example). Maybe this is too much info for job monitoring? But it's just as
>easy for the agent.
I agree we should add an attribute which is an index into the Printer MIB
alert table. Leaving the deviceAlertCode(6) provides for a server
(configuration
2) to put something about the printer, ok?
ISSUE 104: Add deviceAlertIndex attribute which is index into alert table?
Proposed new attribute:
deviceAlertIndex(8) -- Integer32(0..2147483647)
-- INTEGER: MULTI-ROW: The device alert table index for the device that
-- the job is using. When the device is a printer, this index SHALL be the
-- index into the prtAlertTable defined by the Printer MIB[1]. Whether
-- this attribute is instantiated for this job when another job is
-- using the device depends on implementation.
>>2. deviceAlertCode (6) is may be multivalued - See pg. 36.
>>More than one alert may be in effect. Do we need to clarify that this attribute
>can be multi row?
Yes, for both deviceAlertCode(6) and deviceAlertIndex(8). Done.
>>3. What happened to serverAssignedJobNumber (2x) - See pg. 37
>>We used to have serverAssignedJobNumber, with syntax integer. I think we
>combined
>this with serverAssignedJobName (22) and dropped it, but in so doing, it is not
>listed as
>Octets (only). What about the original concern that (OS/2 and perhaps other)
>some os's
>use an integer not a text string. Are we saying the integer must be converted
>to text?
I think you are referring to the jmJobIdNumber attribute that Ron proposed
along with jmJobIdName. We deleted both when switching over to your
jmJobSubmissionID table scheme. Ron is in agreement I believe with not
needing either jmJobIdName or jmJobIdNumber.
So for servers that assign numbers to jobs before submitting them to
devices (configuration 3), rather than names,
I would suggest that having the agent converting a number that it received
in the job submission protocol to a text string would mean that
we could use the same attribute and that an application would not need to
deal with two attributes when querying.
However, we should add a sentence clarifying that the text string
may be a name or a number.
ISSUE 105: Ok to clarify that serverAssignedJobName(22) can be all digits?
>>4. Persistence of serverAssignedJobName - See pgs. 36, 37
>>Two other attributes (jobOwner and jobName) mandate "long" persistence. If you
>read the
>note under serverAssignedJobName, it leads in with the same reasoning, but
>stops short of
>requiring "long" persistence. Which persistence value is serverAssignedJobName
>intended
>to follow?
ISSUE 106: Should serverAssignedJobName persist longer too?
>>(Aside... this leads to another whole question about persistence of tables vs.
>persistence
>of specific attributes or objects and whether or not the 3 objects above should
>just be added
>to the job state table. Separate topic but probably needs further discussion).
Agreed. See ISSUE 93 in what I submitted as comments from Xerox developers.
>>5. jobProcessAfterDateAndTime (51) - Octets vs Integer - See pg. 40-41
>>Shouldn't this be Octets, not Integer?
Yes. Done.
>>6. Eliminate "timeSince" Attributes - See pg. 47
>>This is too much work for the agent and is contrary to SNMP in that sysUpTime
>should do
>the trick. I don't mind using a JmTimeStampTC rather than sysUpTime so much,
>but the
>NMS, not the agent, should calculate the times since.
Good issue. The three timeSinceJobWasSubmitted(192),
timeSinceStartedProcessing(195), and timeSinceCompleted(197)
were added becaue this is the way IPP does these time attributes.
On the other hand, is easier as you point out for the agent to use the
JmTimeStampTC jobSubmissionToDeviceTime(191), jobStartedProcessingTime(194),
and jobCompletedTime(196) and the NMS can do the work. Also having fewer
time attributes to choose from does make the NMS's job easier. I'm in
favor of removing the three timeSinceXXX attributes. An agent instrumenting
an IPP system will have to do a little more computation.
ISSUE 107: Ok to remove the three IPP timeSinceXxx attributes?
An agent instrumenting an IPP implemenation will either have access to
the time that the job's state change happened and can convert to JmTimeStampTC
or only has the time-since-xxx value and will have to substract that from
the time of day and substract sysUpTime from the result to return the
jmTimeStampTC value.
> I believe time can be
>synchronized
>by allowing jobSubmissionToDeviceTime to be multivalued - one DateAndTime
>passed
>in on submission and one jmTimeStampTC stamped by the printer.
Rather than making jobSubmissionToDeviceTime MULTI-ROW, in which an NMS
wouldn't know whether the first value was a submission time to a server
or a submission time to a device, see ISSUE 93a in the Xerox comments
to keep two attributes, but call one jobSubmissionTime and the other
jobSubmissionToServerTime for use in configuration 3 only when both times
are needed.
>>7. IMPLIED/IMPLICIT - See pg. 61
>>The note reads "an IMPLICIT statement is NOT provided in the following INDEX
>clause, since it
>was not an SMIv2 feature. Therefore, the extra ASN.1 tag SHALL be included in
>the varbind
>in the SNMP request and the response."
>>First, we think the terminology is IMPLIED, not IMPLICIT.
Agreed. SNMP uses IMPLIED, ASN.1 uses IMPLICIT. So I'll change the note
if it stays. Done.
Also, we think the
>IMPLIED statement
>SHOULD (SHALL?;-) be included because it saves a byte on each varbind. If you
>left this
>out because it is not part of v1 (as stated) I think there are other examples
>(like DateAndTime)
>where you are using v2 constructs.
ISSUE 108: Add IMPLIED to jmJobIDEntry INDEX statement on page 61?
>>8. "Requested Attribute" defaults
>>For requested attributes like copies, toner, quality etc. what if the requested
>value is not passed
>in? Should the agent use the device default?
Interesting question? In any case that would be implementation dependent.
This is a difference between ISO DPA and IPP. In DPA, the server does
populate the job object with the defaults. In IPP, the server doesn't,
so that the defaults are only applied if neiter the requester nor the
document PDL supplies the attribute.
ISSUE 109: Ok for agent to supply defaults for the job attributes depending
on implmentation?
>>9. Misc editorial
>>We noticed, in the text version, jobHoldUnitl is in the TOC twice.
>In the text and PDF versions jobHold is missing.
Oops! Looks like I didn't update the TOC after adding jobHold attribute.
It will be in the TOC next version.
>>>>>> Harry Lewis <<<
>>