IPP> MOD - NLO 4 of 4: Vote to always use the Natural Language Override mechanism

IPP> MOD - NLO 4 of 4: Vote to always use the Natural Language Override mechanism

IPP> MOD - NLO 4 of 4: Vote to always use the Natural Language Override mechanism

Hugo Parra HPARRA at novell.com
Mon Oct 26 13:07:19 EST 1998


This proposal has my vote.
-Hugo

>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 10/21/98 09:53AM >>>
Summary:  This mail messages proposes to remove the 'textWithoutLanguage'
and 'nameWithoutLanguage' attribute syntaxes and require all 'text' and
'name' attributes to always explicitly include the natural language using
the 'textWithLanguage' and 'nameWithLanguage' syntaxes.

*************************************************************
* The proposal to vote on is to require all attributes to always
* use the 'textWithLanguage' and 'nameWithLanguage' forms
* and to delete the 'textWithoutLanguage' and 
* 'nameWithoutLanguage' forms.
*
* Please indicate your acceptance or rejection of this 
* proposal on the mailing list by Monday, Nov 2.
*************************************************************

This change will affect implementations that correctly implement the June
1998 Mode and Semantics specification.  Implementations that only support
the 'textWithoutLanguage' and 'nameWithoutLanguage' would need to be changed
to conform to either the June specification or this proposal (and changing
to this proposal would be easier than the June specification which requires
supporting both forms of 'text' and both forms of 'name').

Background:

Currently requests and responses that supply 'text' and 'name' attributes in
a different natural language than that supplied for the request or response
as a whole as indicated in the "attributes-natural-language" Operation
attribute MUST include the different natural language explicitly as an
override (and MAY include it explicitly even when they are the same --
according to the NLO 2 of 4 clarification).  

This proposal is to change the Natural Language Override mechanism so that
the 'text' attribute syntax is only 'textWithLanguage' and the 'name'
attribute syntax is only 'nameWithLanguage'.  In other words, each 'text'
and 'name' attribute would always contain the natural language explicitly as
part of the value.  (The Encoding and Transport specification - PRO -
specifies that 'textWithLanguage' and 'nameWithLanguage' values MUST be
encoded as 2 octets of length, the natural-language string, 2 octets of
length, and the text or name value.)

Eliminating one of the two forms of 'text' and one of the two forms of
'name' attribute syntax will simplify comparison in job validation, since
the "xxx" attribute syntax code would have to match the corresponding
"xxx-supported".

The PRO document would simply delete the 'textWithoutLanguage' and
'nameWithoutLanguage' attribute syntaxes.


This proposal does not change any other parts of the Model:

1. The "attributes-natural-language" operation attribute in requests MUST
still be supplied by the client to indicate its preference for natural
language to be returned in responses as currently specified in Section
3.1.4.1 and 3.2.1.1.  

Rationale:  So that an implementation that implements the OPTIONAL
"status-message" response attribute will know which natural language to use.

2.  For create operations, the IPP Printer MUST still copy the
"attributes-natural-language" operation attribute supplied by the client to
the job object as currently specified in Section 3.2.1.1. 

Rationale:  Subsequent communication with the submitting user, such as
operator messages, notification using e-mail, and the job-sheets MAY want to
use the natural language of the job submitter.

3.  All responses MUST return the "attributes-natural-language" operation
attribute as specified in 3.1.4.2, though it no longer has any effect on the
interpretation of any of the returned attributes. 

Rationale:  no need to change this behavior, since all implementations seem
to be doing it.  Removing it would save only 37-40 octets per response.



Tom Hastings
(310) 333-6413








More information about the Ipp mailing list