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

From: Tom Hastings <[email-masked]>
Date: Wed, 9 Jul 1997 18:32:48 PDT

At 01:18 06/27/97 PDT, David T. Perkins wrote:

snip...

>The module has a problem with all the objects that have type of OCTET
>STRING.
>You really need to enforce a code-point mapping. Consider a management
>application. What are they to do with the values? Do they try to figure
>out the encoding, or ask the user of the application for a hint, or what?

snip...

I replied to him as follows and have not received a response:

>2. We have a question about your OCTET STRING comment:
>
>>The module has a problem with all the objects that have type of OCTET
>>STRING.
>>You really need to enforce a code-point mapping. Consider a management
>>application. What are they to do with the values? Do they try to figure
>>out the encoding, or ask the user of the application for a hint, or what?
>
>Our current MIB specification section 6 considers this problem with the
>following analysis and justification (for why we provided no means for
>an application to determine the code-point mapping):
>
>6. Internationalization Considerations
>
>There are a number of objects in this MIB that are represented as coded
character sets.  The data type for such objects is OCTET STRING.  Such
objects could be in different coded character sets and could be localized in
the language and country, i.e., could be localized.  However, for the Job
Monitoring MIB, most of the objects are supplied as job attributes by the
client that submits the job to the server or device and so are represented
in the coded character set specified by that client.  Therefore, the agent
is not able to provide for different representations depending on the locale
of the server, device, or user of the job monitoring application.  The only
exception is job submission protocols that pass job or document attributes
as OBJECT IDENTIFIERS or enums.  For those job and document attributes, the
agent SHALL represent the corresponding objects in the Job Monitoring MIB as
coded character sets in the current (default) locale of the server or
printer as established by the system administrator or the implementation.
>
>For simplicity, this specification assumes that the clients, job monitoring
applications, servers, and devices are all running in the same locale.
However, this specification allows them to run in any locale, including
locales that use two-octet coded character sets, such as ISO 10646
(Unicode).  Job monitors applications are expected to understand the coded
character set of the client (and job), server, or device.  No special means
is provided for the monitor to discover the coded character set used by jobs
or by the server or device.  This specification does not contain an object
that indicates what locale the server or device is running in, let alone
contain an object to control what locale the agent is to use to represent
coded character set objects.
>This MIB also contains objects that are represented using the DateAndTime
textual convention from SNMPv2-TC (RFC 1903).  The job management
application SHALL display such objects in the locale of the user running the
monitoring application.
>
>
>Do you think that the above explanation is suggicient or do we need to
>provide means for an application to determine the country, language, and
>coded character set of the OCTET STRINGS that are coded character sets?
>
>Would just the coded character set be sufficient?  Since all our jobs
>come from clients, there is no opportunity for the agent to translate
>to another language or country.  We have an enum in our
>Printer MIB (RFC 1759) that specifies the coded character set and which
>has been added to the IANA registered coded character sets.
>
>We could add an object to the jmGeneralTable which is the coded character
>set default for the device.  Would this object be sufficient?
>
>If the job is submitted with a different coded character set (unlikely, but 
>possible), we could also add an attribute which is the coded character set of 
>the OCTET STRINGs for this job when the job is different from the
server/device 
>default.  Then the application could display such a job correctly (or determine
>that it cannot).  Should we add this attribute too?
>
>Thanks,
>Tom Hastings
>

So I have added the following issues to the issues.doc list:

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

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.

However, some implementations may code convert some of the attributes
that the client submits to the set of the server, so the separation
of attributes that I have made above may depend on implementation.

Tom