Subject: JMP> Addition of natural language attributes to JMP to align with IPP

From: Tom Hastings <[email-masked]>
Date: Thu, 13 Nov 1997 16:23:37 PST

I've posted my action item to propose to the DL the addition of charset and
natural language attributes to the Job Monitoring MIB to align with IPP
that is now in WG Final Call.  The files are in:

ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds.doc
ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds.txt
ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds-black.pdf
ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-i18n-adds-red.pdf

The .doc is MS-WORD with revision marks
The .txt is plain text
The two .pdf files are with red and black revision marks from the 0.86
version,
dated 9/19/97.

Please send comments by Wed, Nov 19, so I can republish the MIB.
Silence will be assumed to be agreement.

Thanks,
Tom                         

I've attached the .txt version here:

Subj:  Addition of natural language attributes to JMP to align with IPP
From: Tom Hastings
Date: 11/13/97
File: jmp-i18n-adds.doc

Here is my action item to propose to the DL the addition of charset and
natural language attributes to the Job Monitoring MIB to align with IPP
that is now in WG Final Call.

SUMMARY

I've abandoned the idea to add the charset name as an alternative to the
charset enum from the Printer MIB (see reasons below).  So the only
additions are two attributes to identify the natural language, one for the
processingMessage(6) (that often comes from the interpreter) and the other
for the text attributes that came from the job submitter (JmJobStringTC).

Here are the detailed proposals:

1. At the JMP meeting I had proposed also allowing the IANA registered
charset name to be allowed as an alternative representation for the
jobCodedCharSet(7) attribute.  But I'm withdrawing that proposal for the
following reasons:

a) Unlike all other attributes, the management application has to recognize
and support the value of the jobCodedCharSet(7) attribute.  Otherwise, the
management application cannot process or display the text string attributes
that it gets from the MIB that were submitted with the job.  As David
points out, management applications would have to recognize and support
both the charset enum and the charset name identifications in order to
determine the charset that the agent was using for a particular job.

b) Implementations of the Job Monitoring MIB are very likely to also be
doing the Printer MIB which uses the charset enums registered with IANA,
not the charset names.  IPP implementations that don't do the Printer MIB,
are likely to be servers so it is easier for them to identify charset with
both the charset names (as in IPP) and the charset enum representations.

c) The Service Location Protocol (SLP), RFC 2165, June 1997, uses the
charset enums, instead of the charset names.

d) Each charset registered by IANA has only one enum value, but many
charset names.  IPP solved this ambiguity in the charset names, by
requiring the names that are labeled "(MIME preferred name)".  However,
using enum values is more likely to be unique and unambiguous.

2.  Add to the end of section 3.5.1, "Text generated by the server or
device" as a new paragraph:

The text message for the processingMessage(6) attribute is generated by the
server/device.  The natural language for the processingMessage(6) attribute
is identified by the processingMessageNaturalLanguageTag(7) attribute.  The
processingMessageNaturalLanguageTag(7) attribute value SHALL conform to the
language tag mechanism specified in RFC 1766 [RFC-1766].  Each attribute
value is the same as the IPP [IPP-MOD] naturalLanguage attribute syntax.
RFC 1766 specifies that a US-ASCII string consisting of the natural
language followed by an optional country field. Both fields use the same
two-character codes from ISO 639 [ISO-639] and ISO 3166 [ISO-3166],
respectively, that are used in the Printer MIB for identifying language and
country.  Though RFC 1766 requires that the values be case-insensitive
US-ASCII, this MIB specification requires all lower case to simplify
comparing by management applications.
Examples of the values of the processingMessageNaturalLanguageTag(7)
attribute include:

'en'		for English
'en-us'	for US English
'fr'		for French
'de'		for German

3. Add to the end of section 3.5.2, "Text supplied by the job submitter" as
a new paragraph:

The natural language for all attributes represented by the
textual-convention JmJobStringTC SHALL be identified by the
jobNaturalLanguageTag(8) attribute.  The jobNaturalLanguageTag(8) attribute
value SHALL have the same syntax and semantics as the
processingMessageNaturalLanguageTag(7) attribute, except that the
jobNaturalLanguageTag(8) attribute identifies the natural language of
attributes supplied by the job submitter instead of the natural language of
the processingMessage(6) attribute.  See Section 3.5.1.

4. Add the following textual convention:

JmNaturalLanguageTagTC  ::= TEXTUAL-CONVENTION
STATUS      current
DESCRIPTION
"An IETF RFC 1766-compliant 'language tag', with zero or more sub-tags that
identify a natural language.  While RFC 1766 specifies that the US-ASCII
values are case-insensitive, this MIB specification requires that all
characters SHALL be lower case in order to simplify comparing by management
applications."
REFERENCE
"See section 3.5.1, entitled: 'Text generated by the server or device' and
section 3.5.2, entitled: 'Text supplied by the job submitter'."
SYNTAX      OCTET STRING (SIZE (0..63))

5. Make the following modifications to the processingMessage attribute:
processingMessage(6),	JmUTF8StringTC(SIZE(0..63))
OCTETS:  MULTI-ROW:  A coded character set message that is generated by the
server or device during the processing of the job as a simple form of
processing log to show progress and any problems.  The natural language of
each value is specified by the corresponding
processingMessageNaturalLanguageTag(7) value.

There is no restriction for the same message occurring in multiple rows.

6. Add the following attribute:
processingMessageNaturalLanguageTag(7), 	OCTET STRING(SIZE(2..63))
OCTETS:  MULTI-ROW:  The natural language of the corresponding
processingMessage(6) attribute.  See section 3.5.1, entitled 'Text
generated by the server or device'.

If the agent does not know the natural language of the job processing
message, the agent SHALL either (1) return a zero length string value for
the processingMessageNaturalLanguageTag(7) attribute or (2) not return the
processingMessageNaturalLanguageTag(7) attribute for the job.  

There is no restriction for the same tag occurring in multiple rows.

7. Make the following changes to the jobCodedCharSet attribute:
jobCodedCharSet(8),	CodedCharSet
INTEGER:  The MIBenum identifier of the coded character set that the agent
is using to represent coded character set objects and attributes of type
'JmJobStringTC'.  These coded character set objects and attributes are
either: (1) supplied by the job submitting client or (2) defaulted by the
server or device when omitted by the job submitting client.  The agent
SHALL represent these objects and attributes in the MIB either (1) in the
coded character set as they were submitted or (2) MAY convert the coded
character set to another coded character set or encoding scheme as
identified by the jobCodedCharSet attribute.  See section 3.5.2, entitled:
'Text supplied by the job submitter'.

These MIBenum values are assigned by IANA [IANA-charsets] when the coded
character sets are registered.  The coded character set SHALL be one of the
ones registered with IANA [IANA] and the enum value uses the CodedCharSet
textual-convention from the Printer MIB.  See the JmJobStringTC
textual-convention.

If the agent does not know what coded character set was used by the job
submitting client, the agent SHALL either (1) return the 'unknown(2)' value
for the jobCodedCharSet attribute or (2) not return the jobCodedCharSet
attribute for the job.  

8. Add the following attribute:
jobNaturalLanguageTag(9), 	OCTET STRING(SIZE(2..63))
OCTETS: The natural language of the job attributes supplied by the job
submitter or defaulted by the server or device for the job, i.e., all
objects and attributes represented by the 'JmJobStringTC'
textual-convention, such as jobName, mediumRequested, etc.  See Section
3.5.2, entitled 'Text supplied by the job submitter'.

If the agent does not know what natural language was used by the job
submitting client, the agent SHALL either (1) return a zero length string
value for the jobNaturalLanguageTag(9) attribute or (2) not return the
jobNaturalLanguageTag(9) attribute for the job.

9. Add to References section:

[RFC-1766] Avelstrand H., "Tags for the Identification of Languages", RFC
1766, March 1995.

[ISO-639] ISO 639:1988 (E/F) - Code for Representation of names of
languages - The International Organization for Standardization, 1st
edition, 1988.

[ISO-3166] ISO 3166:1988 (E/F) - Codes for representation of names of
countries - The International Organization for Standardization, 3rd
edition, 1988-08-15."

---

From: Ron Bergman <[email-masked]>
Date: Mon, 24 Nov 1997 08:23:40 -0800 (Pacific Standard Time)

Tom,

I known this is late, but better late than never?

Your proposal is very good, with some minor changes.  See my comments
preceded by RB>>.  Although this change probably falls into the "just in
case someone needs it", we might as well incorporate this since the work
is complete.

Since there have been no other comments posted regarding this change, I
believe that it has been accepted by the group.

	Ron Bergman
	Dataproducts Corp.

> that is now in WG Final Call.  The files are in:

**** snip...snip
 
> Here are the detailed proposals:
**** snip...snip
 
> server/device.

RB>> I found the above sentence to be somewhat confusing primarily due to 
RB>> the multiple occurrences of "message". I suggest rewording to:

RB>> "The text contained in the processingMessage(6) attribute is
RB>> generated by the server/device."

                The natural language for the processingMessage(6) attribute
> country.

RB>>  The follow test is repeated, see item 4.

            Though RFC 1766 requires that the values be case-insensitive
> Examples of the values of the processingMessageNaturalLanguageTag(7)
**** snip...snip 
> identify a natural language.

RB>> The following line is repeated from the text that is proposed for
RB>> section 3.5.1.  

                                While RFC 1766 specifies that the US-ASCII
> SYNTAX      OCTET STRING (SIZE (0..63))
**** snip...snip