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
>