IPP> MOD - Tentative decision on natural language overri

IPP> MOD - Tentative decision on natural language overri

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Fri Nov 6 12:17:47 EST 1998


Stuart,

The discussion in the phone conference was that NLO 4 contradicts what is 
in the June drafts, and hence could make implementations against the June 
drafts invalid. To clarify whether this is indeed a problem in early
implementations we have now circulated a new test suite to help verify how
much of a problem this really is. We hope to have the results of that
testing available as input for the discussion in next week's IPP meeting.

Carl-Uno

> -----Original Message-----
> From: Stuart.Rowley at kyocera.com [mailto:Stuart.Rowley at kyocera.com]
> Sent: Friday, November 06, 1998 8:57 AM
> To: ipp; Hastings; Tom N
> Subject: Re: IPP> MOD - Tentative decision on natural language overri
> 
> 
> 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