Subject: PMP> Latest Printer MIB draft

From: [email-masked]
Date: Thu, 19 Mar 1998 14:33:17 -0500

I have made the NMSReset change to the Printer MIB that was
discussed in Austin. The latest revisions are:

ftp://ftp.pwg.org/pub/pwg/pmp/drafts/pmib_0311698.txt
ftp://ftp.pwg.org/pub/pwg/pmp/drafts/pmib_0311698.pdf
ftp://ftp.pwg.org/pub/pwg/pmp/drafts/pmib_0311698_changes.pdf

The TXT file is for those who cannot read PDF files. The
CHANGES.PDF file has revision marks by the changes that I made.

I am not sure that I have ever done a formal two week last call
for changes to the Printer MIB document. Let this e-mail serve
as the last call. The Host Resources MIB has been published as
an Internet Draft and I want to be ready at a moments notice
to start pushing the Printer MIB forward as soon as something
happens to the HR MIB.

Regards,
Lloyd

------------------------------------------------------------
Lloyd Young                       Lexmark International, Inc.
Senior Program Manager            Dept. C14L/Bldg. 035-3
Strategic Alliances               740 New Circle Road NW
internet: [email-masked]     Lexington, KY 40550
Phone: (606) 232-5150             Fax: (606) 232-6740

---

From: Ron Bergman <[email-masked]>
Date: Thu, 19 Mar 1998 11:53:52 -0800 (Pacific Standard Time)

Lloyd,

Glad to see some effort on the Printer MIB again:-)  Thanks for getting
this back in the spotlight.

I found two minor problems in the document last week.

  1. Page 42, the line: 
              "Syntax:  Name" 
     was omitted from the chLPDServer entry.

  2. on page 174, the first line of Appendix F reads:
     "...meeting of the Printer Working Group meeting;..."
     The second "meeting" should be removed.

Also, the HR MIB draft has now added the new bits for
hrPrinterDetectedErrorState.  These should also be added to the Printer
MIB.  

The only other issue is the decoupling of hrDeviceStatus from
hrPrinterDetectedErrorState.  I believe that this was agreed in the
meeting in Austin.  (changes both MIBs)

	Ron Bergman
	Dataproducts Corp.

---

From: Tom Hastings <[email-masked]>
Date: Tue, 31 Mar 1998 13:56:53 PST

At 11:33 03/19/1998 PST, [email-masked] wrote:

snip..

>to start pushing the Printer MIB forward as soon as something

Hi folks,                                         Tuesday (31 March 1998)

Our response to the working group 'last call' on the current Printer MIB
draft, announced by Lloyd Young (co-chair) on Thursday (19 March).

This note proposes a SIMPLE update for text and name string localization
in the latest Printer MIB draft, WITHOUT adding any new objects or new
textual conventions.

Comments are of course very welcome.

Cheers,
- Tom Hastings (Xerox)
- Ira McDonald (High North)

>----------------------------------------------------------------------<

Background
==========

1)  Many vendors' implementations of RFC 1759 localize strings besides
    'xxxDescription' via 'prtGeneralCurrentLocalization' (although the
    list of localized strings differs between vendors).

2)  From April through June of 1997, Ira McDonald (High North) and Tom
    Hastings (Xerox) proposed complex solutions to the localization of
    the text and name strings in the Printer MIB (8 string objects are
    now localized, while 24 string objects have indeterminate charsets
    and languages), eventually abandoned by the working group co-chairs.

3)  Later in 1997, the IETF/PWG Internet Printing Protocol (IPP) Working
    Group added complete charset and language support to their working
    documents for ALL text and name string attributes, and clarified the
    role of 'keywords' within string attributes (invariant US English
    tokens, encoded in US-ASCII).

4)  January 1998, the IESG adopted Harald Alvestrand's excellent work
    "IETF Policy on Character Sets and Languages", BCP 18 / RFC 2277,
    which applies as a MANDATORY policy to all protocols on the IETF
    'standards track', which transfer text or name strings.

5)  In the seven SNMPv3 MIBs (RFC 2271-2275), the System Application MIB
    (RFC 2287), the Lightweight Directory Access Protocol (LDAP, RFC
    2251), the Service Location Protocol (SLP, RFC 2165), and in almost
    ALL other new IETF RFCs with support for accessing text or names,
    strings are ALWAYS specified in the UTF-8 transform of ISO 10646, in
    compliance with the IESG policy (RFC 2277).

6)  The original Printer MIB (RFC 1759) and the current Printer MIB
    draft are NOT compliant with the IESG policy (RFC 2277).

>----------------------------------------------------------------------<

Our Proposal
============

1)  In section 2.2.1.1 'International Considerations', on pages 13-14

    [REPLACE entire section with...]

This Printer MIB complies with all requirements and recommendations of
the IETF Policy on Character Sets and Languages [CHAR-POL].  The IANA
Charset Registration Procedures [CHAR-REG] introduces the term 'charset'
for a coded character set (CCS, eg, ISO 10646) bound to an associated
character encoding scheme (CES, eg, UTF-8).

The localization portion of the general printer sub-unit is
responsible for identifying the natural language, country, and
charset in which all text and name strings are expressed.
The available localizations are represented by the Localization Table.
All implementations of this Printer MIB SHALL support at least one
localization per printer with the UTF-8 charset.

All implementations of this Printer MIB SHALL support the [UTF-8]
charset and MAY support other charsets, with the following restrictions:
1)  All supported charsets SHALL be strict supersets of [US-ASCII], ie,
charsets in which code positions decimal (0-127) are identical to
[US-ASCII].
2)  Control characters (code positions decimal 0-31 and 127) SHALL NOT
be used unless explicitly allowed by the DESCRIPTION clause of a given
TEXTUAL-CONVENTION or OBJECT-TYPE defined in this Printer MIB.

Note:  Charsets which are strict supersets of [US-ASCII] include
ISO 8859-x, Shift-JIS, JIS X0208-1983, and UTF-8.
Charsets which are NOT strict supersets of [US-ASCII] include
IBM EBCDIC, ISO 10646 in UCS-2 (two-octet) form, 
ISO 10646 in UCS-4 (four-octet) form, and all of the 7-bit
national charsets which conform to ISO 646 EXCEPT [US-ASCII] and the
IRV.

Certain string objects MAY contain 'keywords'.  These 'keywords' SHALL
be restricted to be defined in visible [US-ASCII].  These 'keywords'
SHALL be written (by SNMP managers and SNMP agents) and SHALL be
returned (by SNMP agents) in visible [US-ASCII].  These 'keywords' SHALL
NOT be localized by SNMP agents.

NOTE: Since all charsets in the MIB SHALL be a superset of [US-ASCII],
keywords values SHALL be the same representation for any charset 
specified by prtGeneralCurrentLocalization, thereby simplying parsing
by management applications.

Certain string objects MAY contain 'names'.  These 'names' SHALL NOT be
be restricted to be defined in visible [US-ASCII].  These 'names'
SHALL be written (by SNMP managers and SNMP agents) and SHALL be
returned (by SNMP agents) in the charset specified by
prtGeneralCurrentLocalization.  These 'names' MAY be
localized by SNMP agents to the language (and country) specified by
prtGeneralCurrentLocalization.

Some objects may contain keywords and/or names, depending on
implementation and usage as shown below.  When retrieving such an object
from the MIB, management applications SHOULD assume that the value is a
keyword and localize the language for its user.  However, if the
management application does not recognize the keyword, it SHOULD treat
the value as a name and display the name as it is to its user:

Object                         Requirements
------                         ------------
PrtLocalizationLanguage        SHALL be keywords defined in ISO 639
PrtLocalizationCountry         SHALL be keywords defined in ISO 3166

prtGeneralCurrentOperator      MAY contain keywords defined in this MIB
prtGeneralServicePerson        MAY contain keywords defined in this MIB
prtChannelInformation          MAY contain keywords defined in this MIB

                               localized by prtGeneralCurrentLocalization
                               charset     language (and country)
                               -------     --------
prtGeneralPrinterName          SHALL       MAY
prtGeneralSerialNumber         SHALL       MAY
prtCoverDescription            SHALL       SHALL
prtInputMediaName              SHALL       MAY         (keywords and names)
prtInputName                   SHALL       MAY         (keywords and names)
prtInputVendorName             SHALL       MAY
prtInputModel                  SHALL       MAY
prtInputVersion                SHALL       MAY
prtInputSerialNumber           SHALL       MAY
prtInputDescription            SHALL       SHALL
prtInputMediaType              SHALL       MAY         (keywords and names)
prtInputMediaColor             SHALL       MAY         (keywords and names)
prtOutputName                  SHALL       MAY         (keywords and names)
prtOutputVendorName            SHALL       MAY
prtOutputModel                 SHALL       MAY
prtOutputVersion               SHALL       MAY
prtOutputSerialNumber          SHALL       MAY
prtOutputDescription           SHALL       MAY
prtMarkerSuppliesDescription   SHALL       MAY
prtMarkerColorantValue         SHALL       MAY         (keywords and names)
prtMediaPathDescription        SHALL       SHALL
prtChannelProtocolVersion      SHALL       MAY
prtInterpreterLangLevel        SHALL       MAY
prtInterpreterLangVersion      SHALL       MAY
prtInterpreterDescription      SHALL       SHALL
prtInterpreterVersion          SHALL       MAY
prtAlertDescription            SHALL       SHALL

                               localized by prtConsoleLocalization
                               charset     language (and country)
                               -------     --------
prtConsoleDisplayBufferText    SHALL       SHALL
prtConsoleDescription          SHALL       SHALL

2)  In all other sections

    [REMOVE all (9) references to 'NVT-ASCII', which are now unnecessary
    given the above revised section 2.2.1.1]

3)  In all other sections

    [REMOVE all (12) references to ASCII charset restrictions, except
    for those occurring in 'keyword' descriptions]

4)  In 'prtGeneralCurrentLocalization' object

    [REVISE description to align with this proposal]

5)  In 'prtLocalizationTable' and subordinate objects

    [REVISE description to align with this proposal]

6)  In section 'References', on page 176

    [ADD the following references...]

[CHAR-POL]      IETF Character Set and Languages Policy, BCP 18,
                RFC 2277, January 1998.

[CHAR-REG]      IANA Charset Registration Procedures, BCP 19,
                RFC 2278, January 1998

[UTF-8]         UTF-8, a transformation format of ISO 10646, RFC 2279,
                January 1998.

[ISO-639]       ISO/IEC 639, Code for the representation of names of
                languages, 1988.

[ISO-3166]      ISO/IEC 3166, Code for the representation of names of
                countries, 1993.

[ISO-10175]     ISO/IEC 10175, Document Printing Application
                (DPA), 1996.

[ISO-10180]     ISO/IEC 10180, Standard Page Description Language
                (SPDL), 1995.

    [REMOVE the following reference...]

[NVT-ASCII]     ...

>----------------------------------------------------------------------

---

From: Matt Young <[email-masked]>
Date: Wed, 01 Apr 1998 18:53:13 -0700

Tom Hastings wrote:
<Simple localization change proposal from Tom Hastings>

Being new to PWG activities, I'm not sure what to think about a change
like this that comes just days before the Printer MIB was to step into
the next level of standards Nirvana -- is this normal? :-)

Also being new, I'm not sure if this sort of thing is standard around
April 1st.  After looking at RFC 2277, I tend to think I must be falling
for a pretty good April Fools joke because it has lots of stuff in there
about using character sets other than UTF-8.

Just in case it really isn't an April Fools joke, here's my input: 
let's change the MIB instead to say that UTF-8 SHOULD be used for all
localization.

-- 
Matt Young
([email-masked]) Hewlett-Packard Department LaserJet Division

---

From: Tom Hastings <[email-masked]>
Date: Thu, 2 Apr 1998 09:58:15 PST

>the next level of standards Nirvana -- is this normal? :-)

Apparently, proposes for change do happen during "last call".  Witness
the attempt to change to XML for IPP during IPP's last call.

Also, because the Printer MIB has been waiting for the HR MIB for
almost a year, other IETF requirements, such as the Charset and Language
Policy have caught up with us.  And the policy says thay the IESG can take 
the Printer MIB off the standards track, if we don't comply.

>let's change the MIB instead to say that UTF-8 SHOULD be used for all

The policy says SHALL, so SHOULD isn't good enough.