Subject: JMP> DateAndTime is a binary string of octets!

From: Tom Hastings <[email-masked]>
Date: Thu, 13 Mar 1997 17:07:59 PST

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

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.

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))

---

From: Patrick Powell <[email-masked]>
Date: Fri, 14 Mar 1997 07:21:58 -0800 (PST)

I would suggest that you might also want to add 'textencoding' as well.
For example,  you might have UNICODE text or simple ASCII text.

	Comments?

	Tom

	WARNING:

I believe that there is a general fiat that the Network Standard Order
for multiple octect values is Big Endian.

	    STATUS       current
	    DESCRIPTION

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?

Patrick

---

From: Tom Hastings <[email-masked]>
Date: Mon, 17 Mar 1997 15:06:43 PST

Patrick,

What did the "This" refer to at the end?

Thanks,
Tom

>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?

>	            field  octets  contents                  range

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