Subject: FIN> New Finisher MIB Internet-Draft

From: Ron Bergman <[email-masked]>
Date: Mon, 29 Jun 1998 17:40:13 -0700 (Pacific Daylight Time)

I have submitted the latest Finisher MIB document to the IETF to be posted
as an internet-draft.  The announcement should appear in the next day or
so.

The document also can be found at:

ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing-03.txt

I have also loaded a WORD file that contains revision marks for all the
changes since the last internet-draft. (I could not create a PDF file today.) 
The WORD file is in the same directory as:

draft-ietf-printmib-finishing-rev-03.doc

And there is a MIB file that matches at:

ftp://ftp.pwg.org/pub/pwg/fin/mibs/fin-mib-980629.mib

These documents contain all the changes from the prevous posting plus,
with the following exceptions, the changes suggested by Tom Hastings and
Ira Mcdonald.

  1. I added "(mandatory)" to the Finisher Device Attribute Group but I
     question whether it should really be "Conditionally Mandatory".  As
     suggested by Tom, is it valid to have a table entry without any
     attributes?  Or, if there are no attributes there should be no table?

  2. I did not change the arc to { mib-2 9999 } as in Ira's differences.
     I believe that the problem observed by Ira could also be solved by 
     appending the Finisher MIB to the Printer MIB and compiling both
     together.

     Ira: Did your complied result contain the correct OIDs with the
     Printer MIB arc?

  3. Ira suggested that the syntax of the objects:

       finSupplyMediaInputName
       finSupplyMediaInputDescription
       finSupplyMediaInputMediaType

    be change from "DisplayString" to "OCTET STRING" to be consistent
    with the Printer MIB. Since it was previously discussed and agreed
    that these objects should be "DisplayString", I did not change.

Unless we can resolve the above three issues via email, I would like to
place these issues for discussion on the agenda for next week.

	Ron Bergman
	Dataproducts Corp.

---

From: Tom Hastings <[email-masked]>
Date: Tue, 30 Jun 1998 13:11:47 PDT

>     attributes?  Or, if there are no attributes there should be no table?

Good question.

>    that these objects should be "DisplayString", I did not change.

I forget the discussion about keeping it as DisplayString.  The problem
with DisplayString, is that it MUST be US-ASCII.  With OCTET STRING,
it could be some other character set (and language).  See the suggested
clarifications that Ira and I proposed to reflect current implementations.

By keeping it as DisplayString, then if we ever did agree to allowing other
charsets for the Printer MIB, we couldn't for the Finisher MIB.

---

From: Tom Hastings <[email-masked]>
Date: Tue, 30 Jun 1998 15:35:18 PDT

I've posted the .pdf files with line numbers:

ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing-
rev-03.pdf
ftp://ftp.pwg.org/pub/pwg/fin/internet-drafts/draft-ietf-printmib-finishing-
rev-03-rev.pdf

The latter has revision marks turned on (they start over each page).

-rw-r--r--   1 pwg pwg   94049 Jun 30 00:06
draft-ietf-printmib-finishing-03.txt
-rw-r--r--   1 pwg pwg  160768 Jun 30 00:08
draft-ietf-printmib-finishing-rev-03.doc
-rw-r--r--   1 pwg pwg   86160 Jun 30 22:31
draft-ietf-printmib-finishing-rev-03.pdf
-rw-r--r--   1 pwg pwg  115794 Jun 30 22:31
draft-ietf-printmib-finishing-rev-03-rev.pdf

Tom

---

From: Tom Hastings <[email-masked]>
Date: Tue, 30 Jun 1998 15:59:52 PDT

At 13:11 6/30/98 PDT, Tom Hastings wrote:

snip...

>charsets for the Printer MIB, we couldn't for the Finisher MIB.

Further arguments for changing these three back to OCTET STRING to

agree with the Printer MIB:

We must change at least finSupplyMediaInputDescription back to

OCTET STRING in order to agree with the semantics that we have written

which require the data to be whatever the current localizaion is:

The finSupplyMediaInputDescription is intended to be localized

(as in the Printer MIB):

finSupplyMediaInputDescription OBJECT-TYPE

    SYNTAX      DisplayString (SIZE(0..255))

    MAX-ACCESS  read-only

    STATUS      current

    DESCRIPTION

      "A free form text description of this input subunit in the 

       localization specified by prtGeneralCurrentLocalization."

    ::= { finSupplyMediaInputEntry 11 }

RFC 1902 says:

11.1.1.  Mapping to the SYNTAX clause

   When mapping to the SYNTAX clause of the OBJECT-TYPE macro:

snip...

(6)  An object with a character string syntax becomes either an OCTET

     STRING, or a DisplayString [3], depending on the repertoire of the

     character string.

[3] is RFC 1903.  Therefore, it cannot be DisplayString, which RFC 1903

restricts to US-ASCII:

<bigger>DisplayString ::= TEXTUAL-CONVENTION

    DISPLAY-HINT "255a"

    STATUS       current

    DESCRIPTION

            "Represents textual information taken from the NVT ASCII

            character set, as defined in pages 4, 10-11 of RFC 854.

            To summarize RFC 854, the NVT ASCII repertoire specifies:

              - the use of character codes 0-127 (decimal)

              - the graphics characters (32-126) are interpreted as

                US ASCII

              - NUL, LF, CR, BEL, BS, HT, VT and FF have the special

                meanings specified in RFC 854

              - the other 25 codes have no standard interpretation

              - the sequence 'CR LF' means newline

              - the sequence 'CR NUL' means carriage-return

              - an 'LF' not preceded by a 'CR' means moving to the

                same column on the next line.

              - the sequence 'CR x' for any x other than LF or NUL is

                illegal.  (Note that this also means that a string may

                end with either 'CR LF' or 'CR NUL', but not with CR.)

            Any object defined using this syntax may not exceed 255

            characters in length."

    SYNTAX       OCTET STRING (SIZE (0..255))

</bigger>

I claim that we should change all three back to OCTET STRING 

to be consistent with the Printer MIB and to allow implementations to 

use other charsets for these three objects.  We should only use 

DisplayString when the data is restricted to US-ASCII for some reason, 

such as the data is really keywords for programs, not arbitrary text for 

humans.

Tom