Regarding the two new Job MIB localization issues, my comments begin with <hrl>:
ISSUE 111: Add jmGeneralCodedCharacterSet object that specifies the coded
character set of the server or device that the agent is instrumenting as
suggested by David Perkins? Then a management application could discover
the coded character set for the jmGeneralJobSetName object and the following
job attributes: processingMessage, deviceNameRequested, queueNameRequested,
physicalDevice (name), outputBin (name), mediumRequested (name),
mediumConsumed (name), colorantRequested (name), colorantConsumed (name).
<hrl> First, what distinction are you trying to achieve with TWO objects?
The intuitive difference would seem to be that jmGeneralCodedCharacterSet
applies to strings generated by the agent and jobCodedCharacterSet applies
to strings passed in on submission. But I don't think your set splits out
that way.
<hrl> My problem with trying to address localization in the Job MIB, in
general, is that many job attributes are passed to the agent during job
submission. If the submission protocol (PJL, for example) does not
support localization, the agent will be unable to reflect any intelligent
information with respect to jmGeneralCodedCharacterSet.
ISSUE 112: Add jobCodedCharacterSet attribute, so that a client can
determine the coded character set that each submitter used as suggested by
David Perkins? Aligns with IPP "user-locale" attribute. Then a management
application could discover the coded character set of the jobOwner job
object and the following job attributes that are submitted with the job in a
character set specified by the submitter (and it is unlikely that the
agent/device would code convert them to the coded character set of the
agent/device): other, unknown, jobAccountName, serverAssignedName, jobName,
submittingServerName, submittingApplicationName, jobOriginatingHost,
fileName, documentName, and jobComment.
<hrl> If some submission protocols (IPP) support localization, and we
want an object for these cases, it may be appropriate, but ONLY if
we accommodate submission protocols which lack localization support as
a default.
<hrl> Until it is made absolutely clear how this default would operate, I
voice in opposition to issues 111 and 112.
Harry