Patrick,
What did the "This" refer to at the end?
Thanks,
Tom
At 07:21 03/14/97 PST, you wrote:
> DateAndTime which we are using for date and time in our Job Monitoring MIB
> is not printable characters; its binary (don't be fooled by the display
> hint, which is just how to convert the binary to text).
>> We decided to have two values in our Resource Table (which I'm renaming
> to Attribute Table due to some confusion about resources in the e-mail and
> since we have agreed to put more than just resources into it):
>> jmAttributeValueAsInteger
> jmAttributeValueAsText
>>I would suggest that you might also want to add 'textencoding' as well.
>For example, you might have UNICODE text or simple ASCII text.
I'm not sure what you are suggesting here?
I was suggesting that we change the name to jmAtributeValueAsOctets
so that the object contains whatever the enum says it contains.
If the enum says it contains coded characters, then the object contains
coded characters which may be ASCII or UNICODE or whatever. The monitoring
application is assumed to know what coded character submitter use.
See page 30, under OCTET STRING. It the object contains binary octets,
such as DateAndTime, then that is what it contains.
Ok?
>> Since Text is represented as OCTET STRING in SNMP, there is no problem
> with sending the binary using the same object. However, we might want
> to rename the second object to jmAttributeValueAsOctets, so that it
> covers the DateAndTime.
>> Comments?
>> Tom
>> WARNING:
>> By the way, SNMPV2-TC isn't very clear whether the two octet year is
> Big Endian or Little Endian, but I suspect that it must be Big Endian,
> since SNMP uses ASN.1 which is Big Endian (most significant octet first).
>> So the year 256 would be represented as 1 in the first octet and 0 in the
> second octet, not the other way around.
>> Be careful, since PCs are Little Endian, so they have to swap the octets.
>>I believe that there is a general fiat that the Network Standard Order
>for multiple octect values is Big Endian.
>> RFC 1903 SNMPv2-TC is copied as follows:
>> DateAndTime ::= TEXTUAL-CONVENTION
> DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
>> STATUS current
> DESCRIPTION
> "A date-time specification.
>> field octets contents range
> ----- ------ -------- -----
> 1 1-2 year 0..65536
> 2 3 month 1..12
> 3 4 day 1..31
> 4 5 hour 0..23
> 5 6 minutes 0..59
> 6 7 seconds 0..60
> (use 60 for leap-second)
> 7 8 deci-seconds 0..9
> 8 9 direction from UTC '+' / '-'
> 9 10 hours from UTC 0..11
> 10 11 minutes from UTC 0..59
>> For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
> displayed as:
>> 1992-5-26,13:30:15.0,-4:0
>> Note that if only local time is known, then timezone
> information (fields 8-10) is not present."
> SYNTAX OCTET STRING (SIZE (8 | 11))
>>>This is also the standard for representing time in some other ISO standards.
>Why not make this the cannonical way to represent time/date values?
What does "This" refer to? The ASCII display: 1992-5-26,13:30:15.0,-4:0
or the binary format?
We have agreed that including a date is not possible for some implementations,
so we are also providing the TimeStamp textual convention from SNMPv2-TC
which is 100ths of a second offset from the time the system was started.
We've doubled the number of time enums to provide both formats.
Tom
>>Patrick
>>