Subject: JMP> ISSUES 111 and 112: How does APP determine coded charac

From: Harry Lewis <[email-masked]>
Date: Thu, 10 Jul 1997 12:12:02 -0400

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

---

From: Tom Hastings <[email-masked]>
Date: Thu, 10 Jul 1997 19:31:04 PDT

>to strings passed in on submission. But I don't think your set splits out

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.

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

>we accommodate submission protocols which lack localization support as

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?

>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