The attached e-mail from Randy went to the IPP mailing list by
mistake. I wanted to make sure that everyone on the PMP
mailing list saw it.
Lloyd
---------
To: ipp%pwg.org at interlock.lexmark.com
cc: (bcc: Lloyd Young)
From: rturner%sharplabs.com at interlock.lexmark.com @ LEXMTA
Date: 06/06/97 03:21:20 PM MST
Subject: IPP> Re: PMP> prtAlertTime issue
The problem with using "0" is that it would be impossible to tell
whether an alert was
created at startup time, or that the alert time was unknown. This is why
there are no
"alternate" values for the TimeTicks type of object. Using "0" would be
a loose
agreement between members of the WG, but would not be kosher for the
purist'
view (IETF) of how the TimeTicks type is to be used.
Randy
Harry Lewis wrote:
> Guess I'd like to *strongly* recommend that every device with the
> printer MIB
> supports sysUpTime.
> I recall, rather vividly, the reason we chose sysUp was to acknowledge
> that
> many (most?) printers would not have a "real time" clock. But, the
> premise has
> always been that all printers could count ticks.
>> I can see where there could be problems associated with sysUpTime, one
> that
> comes to mind is printers might not be real consistent (among vendors)
> as to
> how they treat sysUpTime on power cycles, remote resets, local resets
> etc. But,
> I thought the notion of synching with the printers sysUpTime on the
> PowerUp
> trap was a rather fundamental notion.
>> Now, what if there *is no* sysUpTime (the original question)? Well, if
> there is
> no meaningful value, I guess 0 is about as good as any.
>> >>> Harry Lewis <<<
>> ------- Forwarded by Harry Lewis/Boulder/IBM on 06/06/97 03:14 PM
> --------
>>pmp-owner at pwg.org> 06/06/97 01:54 PM
> Please respond to rturner at sharplabs.com @ internet
>> To: pmp at pwg.org @ internet
> cc:
> Subject: PMP> prtAlertTime issue
>> Lloyd referenced an earlier mail message by Bob Pentecost reflecting a
>> request by Bob as to
> what value should be returned by a GET for prtAlertTime if the printer
>> didn't know the time.
> Values for INTEGER types have (other) and (unknown) as possible
> values.
> The 'TimeTicks'
> object has no such equivalents. prtAlertTime is now mandatory, and is
> based on sysUpTime
> from MIB-II. If someone performs a GET on prtAlertTime (according the
> curent definition),
> then it MUST return a valid value. There are no alternative 'other' or
>> 'unknown' scenarios
> for an object like prtAlertTime, with type 'TimeTicks' that is based
> on
> MIB-II sysUpTime.
>> Randy