At 09:12 07/10/97 PDT, Harry Lewis wrote:
>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.
You are right! I blew it when making the two lists.
I was trying to split the list between objects and attributes that are
ONLY supplied by the server/device and those that are supplied by the
job submitter. However, when I made the list, I realized that some of
the strings supplied by the submitter might naturally get code converted
to the set of the server/device, if they were different, in order for the
server/device to match with something that the server/device offerred,
such as media or output bin.
But since some implementations may code convert and some may not and
the code conversion may depend on which attribute and vary from
implementation to implementation, I should only include objects and
attributes that relate to jmGeneralCodedCharacterSet object that come
ONLY from the server/device. Anything that comes from the submitter
should remain in the coded character set of the submitter when returned
by the SNMP agent (whether the implementation code converts internally
or not).
So the (short) list of objects and attributes that the
jmGeneralCodedCharacterSet describe are:
jmGeneralJobSetName object
processingMessage attribute
physicalDevice (name value) attribute
all the other objects and attributes are specified by the requester
(or as we recently agreed, could be defaulted by the server/device).
See next issue (112) for the long list.
We would have to clarify that if the server/device default strings,
then the server/device MUST use the coded character set of the
submitter. Otherwise, we would need a tag on each string that says
what coded character set it is in.
>><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.
I'm not sure I understand your concern here.
I think that jmGeneralCodedCharacterSet is the same as the
prtLocalizationCharacterSet for the current localization. But since
we don't want to require that the Printer MIB be implemented, the
value of jmGeneralCodedCharacterSet would be a copy of the enum that
is in the prtLocalizationCharacterSet for the current row specified
by the prtGeneralCurrentLocalization. And it only controls the
three objects/attribtes:
jmGeneralJobSetName object
processingMessage attribute
physicalDevice (name value) attribute
In IPP, the Printer's "printer-locale" attribute supplies the coded
character set enum for the jmGeneralCodedCharacterSet object.
Ok?
>>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.
I quite agree that we need to accomodate those protocols that do not
support localization.
But we also need to support IPP. IPP has the "user-locale" attribute
that is submitted with the job. The coded character set part of that
value would supply the value for the IETF Job Monitoring MIB
jobCodedCharacterSet attribute.
So the list of objects and attributes that the jobCodedCharacterSet attribute
would describe include:
IETF Job object/attributes Equivalent IPP attributes
-------------------------- -------------------------
jmJobOwner object "job-originating-user"
other, -
unknown, -
serverAssignedJobName, -
jobName, "job-name"
jobAccountName, -
submittingServerName, -
submittingApplicationName, -
jobOriginatingHost, "job-originating-host"
deviceNameRequested, "printer-uri"
queueNameRequested, -
fileName, "document-uri"
documentName, "document-name"
jobComment, -
outputBin (name), -
mediumRequested (name), "media"
mediumConsumed (name), -
colorantRequested (name), -
colorantConsumed (name) -
[If we add jobCodedCharacterSet and jmGeneralCodedCharacerSet, they
will be constrained to be ASCII]
Ok?
>><hrl> Until it is made absolutely clear how this default would operate, I
>voice in opposition to issues 111 and 112.
I agree. I'll make a new complete proposal, including the default
and see what you (and JMP) think.
The gist would be:
1. agents that know what the (current or fixed) coded character set
of the server/device (for the 3 objects/attribute affected) is
SHALL put that value in the jmGeneralCodedCharacterSet object.
Otherwise, the agent SHALL put the unknwon(2) value for the
jmGeneralCodedChararacterSet object.
2. agents that know what the coded character set of the submitter is
because the submitter submitted it as an attribute as in DPA and IPP
in the job submission protocol SHALL implement and set that value in the
jobCodedCharacterSet attribute for the job.
3. agents that assume that the coded character set of the submitter is
the same as that of the server/device, MAY, but NEED NOT, implement the
jobCodedCharacterSet attribute.
So if an application first checks jmGeneralCodedCharacterSet,
the application knows what the code set is for:
jmGeneralJobSetName object
processingMessage attribute
physicalDevice (name value) attribute
Then the application checks for jobCodedCharacterSet attribute.
If the attribute is found, then the application knows the character
set of the submitted objects and attributes. If the jobCodedCharacterSet
attribute is NOT found, then the application assumes that it is the
same as jmGeneralCodedCharacterSet.
If the PJL server/device is ASCII and assumes that the submitter is
submitting in ASCII, then the agent would set the ASCII enum as the
value of the jmGeneralCodedCharacterSet and would NOT need to implement the
jobCodedCharacterSet attribute.
Comments?
Tom
>>Harry
>>