IPP> MOD - Tentative decision on natural language overri

IPP> MOD - Tentative decision on natural language overri

IPP> MOD - Tentative decision on natural language overri

Stuart Rowley Stuart.Rowley at kyocera.com
Fri Nov 6 11:57:28 EST 1998


Apparently the participants in the telecon and those "voting" on the 
mailing list are completely different groups of individuals! Except for Bob 
Herriott, no one expressed any con arguments for NLO 4 of 4. I only saw yes 
"votes" (about 10 or 15 of them). So why the telcon decision of No. There 
is not even any reasons given why this decision was reached. Where is the 
discussion on the mailing list?

This type of mass back on forth makes me wonder how many really have a 
clear understanding of these NLO issues (not that I do). Nearly everyone 
has expressed that the current mechanisms are overkill and very hard to 
understand.

I think the only really clearly articulated discussion of this on the 
mailing list has been Carl Kugler's emails. On Oct 9 Carl sent the 
following email titled IPP> Re: MOD OLD NEW Issue: Contradictory NLO req. 
This email suggests a very clear and to me appropriate solution. I never 
saw on the list anyone state why not to accept Carl's proposal. After this 
email, we received the issue broken into several inter-related issues by 
Tom (which I read over and over and over, trying to understand). 

I would now challenge those in the telecon who decided to keep name/text 
withoutLanguage to re-read Carl's email (below) and state in what ways his 
proposal is flawed. Until someone can adequately shoot down this clear 
proposal of Carl's, then his proposal is what I am in favor of.

Thanks,

Stuart

------------------------------------------------------------------------ 
Stuart Rowley                       Kyocera Technology Development, Inc. 
Network Product Dev. Mgr.           3675 Mt. Diablo Blvd. #330 
Printer Division                    Lafayette, CA 94549 
stuart.rowley at kyocera.com           925 299-7206    Fax: 925 299-2489 
------------------------------------------------------------------------

>From Carl Kugler, 10/9/98

IPP> Re: MOD OLD NEW Issue: Contradictory NLO req
-------------------------------------
Here is a proposal for simplifying IPP's natural language model.  It's 
basically an elaboration of a suggestion made by Keith Moore in 
http://www.egroups.com/list/ipp/3644.html
The idea is simple.  Eliminate the implicit language form of text and name 
attributes.  

Specifically:
1.  Eliminate "attributes-natural-language" operation attribute. 
2.  Eliminate "attributes-natural-language" job object attribute. 
3.  Eliminate "textWithoutLanguage" attribute syntax.  
4.  Eliminate "nameWithoutLanguage" attribute syntax.
5.  To allow client to specify desired natural language for 
Printer-generated text from multi-lingual Printers, add a new, OPTIONAL, 
"natural-language-requested" attribute to override Printer's 
"natural-language-configured".

Now every text and name attribute has an explicitly specified natural 
language.

Advantages:
1.  Constructing responses is simpler.  No need to consider a hierarchy of 
implicit language contexts.  Printer never needs to convert from 
xWithoutLanguage to xWithLanguage.
2.  Interpreting messages is simpler.  Currently the same message can take 
many forms, depending on use of redundant NLOs, etc.
2.  Comparing name and text values is simpler.  No need to search a 
three-level precedence hierarchy to find the language of a value being 
compared.  Name and text values can be compared out of context.
3.  Implementation is simpler.  Fewer attribute syntaxes required.  12 
fewer attributes have multiple syntaxes.  One less attribute in a special, 
reserved, required position.
4.  Bandwidth savings.  Using the examples from Section 9 of PRO:
9.1: save 30 bytes
9.2: save 23 bytes
9.3: save 30 bytes
9.4: save 30 bytes
9.5: save 37 bytes
9.6: save 37 bytes
9.7: save 60 bytes.
5.  No loss in functionality over the original model.    
6.  Easier to specify and understand.

Disadvantage:
1.  Reduced job security for IPP consultants ;-)

-Carl

------------------------------------------

______________________________ Reply Separator 
_________________________________ Subject: IPP> MOD - Tentative decision on 
natural language override (
Author:  "Hastings; Tom N" <hastings at cp10.es.xerox.com> at ~internet Date:   
 11/5/98 7:15 PM


At our IPP telecon, Wednesday, 11/04/1998, we tentatively agreed to the 
following decisions.  Please response to these tentative decisions on the 
mailing list so that we may make final decisions at the upcoming IPP WG 
meeting next week.

Decision 1: 
Yes for nlo 3 of 4. (Issue 1.47) 
A name/textWithoutLanguage does not get its implicit 
language from the attributes-natural-language attribute in the job attribute

group in a Get-Jobs response. It always gets the language for each job in 
the response from the attributes-natural-language operation attribute.  This 
is a change from the June draft by deleting a paragraph in section 3.2.6.2 
Get-Jobs response (that required the job-level natural language override to 
be returned for each job whose natural language differed from that of the 
response as a whole).

Decision 2:
No for nlo 4 of 4.  (Issue 1.48)
Keep both text/nameWithLanguage and 
text/nameWithoutLanguage attribute syntaxes for 'text'/'name' attributes as 
in the June draft. Thus, when a text/name attribute value's natural language 
is the same as the attributes-natural-language operation attribute, the 
value in the protocol can either contain text/nameWithLanguage or 
text/nameWithoutLanguage.


We also discussed nlo 2 of 4.  (Issue 1.46)
To clarify that a request or response MAY contain a redundant use of 
text/nameWithLanguage, i.e., the explicit natural language of an attribute 
value is the same as the natural language specified for the request or 
response as a whole in the attributes-natural-language operation attribute. 
We agreed that to make it simply a MAY (implementer option), since some 
implementers want to remove redundancy in their requests and response, while 
other implementers want to always pass name and text with explicit natural 
languages.  Thus we could not agree to make redundant NLO at the attribute 
level a SHOULD or a SHOULD NOT, but merely a MAY.


Tom Hastings
(310) 333-6413




More information about the Ipp mailing list