Tom,
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.
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.
> 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'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.
...jay