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

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

Ron Bergman rbergma at dpc.com
Mon Nov 24 11:23:40 EST 1997


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.




On Thu, 13 Nov 1997, Tom Hastings wrote:


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


**** snip...snip
 
> Here are the detailed proposals:
> 
**** snip...snip
 
> 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.


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


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


            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
> 
> 
**** snip...snip 
> 
> 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.


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



More information about the Jmp mailing list