PMP Mail Archive: Re: PMP> URGENT: SYNTHESIS proposal on definition of OCTET

PMP Mail Archive: Re: PMP> URGENT: SYNTHESIS proposal on definition of OCTET

Re: PMP> URGENT: SYNTHESIS proposal on definition of OCTET

Tom Hastings (
Wed, 23 Jul 1997 11:56:03 PDT

At 10:09 07/23/97 PDT, JK Martin wrote:
>Well, this new proposal is certainly an improvement. However, as Ron
>Bergman has stated so well, it's not clear at all that this kind of
>substantial--yet last-minute--kind of change to the MIB is in the PWG's
>best interest.
>My personal preference remains the same, that we forego this kind of
>change and let the MIB go to Draft as is. Then, the PMP immediately
>engages in the next version, with the primary focus being localization,
>taking into account what the IETF has planned for generic kinds of
>solutions to this universal problem.

See my mail response to Ron on the process question on what we can do to
a Draft standard after it reaches draft status? Or do we just do another
standard that has high overlap with the Printer MIB?

>I can, however, go along with the group consensus of accepting your
>proposal (with modest changes), if that's what the group really wants
>to do. However, my *primary* concern is to CLOSE this effort as quickly
>as possible.
>Standards do not exist for their own sake. Standards, at least within
>the PWG domain, are designed to effect the development of products.
>The longer it takes to develop a standard, the longer it will take
>for the related products to get to market. Please keep this basic
>premise in mind when you come up your many last-minute changes!
>I would like to make a couple of comments on your proposal:
>> 1. Page 14, change the paragraph about OCTET STRING objects from:
>> Localization is only performed on those strings in the MIB that
>> are explicitly marked as being localized. All other character
>> strings are returned in ASCII.
>> to:
>> Localization is only performed on those strings in the MIB
>> represented by objects with syntax 'OCTET STRING' that
>> are explicitly marked as being localized.
>For the sake of sanity, let's define a TC (say, StaticCodeSet, or
>something like that) and use that as the SYNTAX for those OCTET STRING
>values pertaining to this proposal. That is, do NOT simply define such
>objects as OCTET STRING and expect the reader sees the attendant verbage
>on localization. A specific TC for this purpose is much cleaner all
>the way around.

You are right that it would be better to have a TC, but there was concern
that making such edits might include some mistakes and it would take
a more time to do, delaying the forwarding of the document.

>> I have left out any attempts to fix the DESCRIPTION of
>> prtChannelInformation in this proposal, since previous attempts to
>> fix its descriptive contradictions has upset some members. I have
>> also not proposed that its SYNTAX be changed from DisplayString
>> to OCTET STRING for the same reason.
>I do not think prtChannelInformation should be localized in any way
>shape or form. It should have a fixed charset. Since it appears
>the printing system having the most impact here is NDPS (and related
>Novell systems), perhaps Scott can offer up a proposal for the charset.

I agree with you. David's improved prtChannelInformation DESCRIPTION
makes it clear that the code set of the value depends on the enum.

>I'm probably showing my ignorance of localization mechanisms, but is
>UTF-8 acceptable for prtChannelInformation? If so, then I strongly
>suggest we use it, assuming it is accetable to Scott et al.

David's improved spec only requires UTF8 coding scheme when the
coded character set is ISO 10646 (Unicode).

> ...jay