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