Stuart,
First of all, let me emphasize the word "Tentative" in the subject of the
decision from the telecon. This decision is subject to:
1. Feed back from people like you who were not on the telecon.
2. Feed back from actually running the scripts that test what
implementations are actually doing.
We have sent new scripts to the Bake-Off participants on Wednesday and I
hope we will have results this week to help make the final decision next
week in Tucson, 11/10-12. Unfortunately, I have only heard from one of the
16 Bake-Off participants so far.
Let me try to explain why we didn't propose Carl's 5 simple changes to the
June draft. Bob, Carl, and I worked out the actual proposals together for
nlo 2 of 4, nlo 3 of 4, and nlo 4 of 4. We modified Carl's proposal so as
not to change anything that wasn't broken. The result was 3 changes instead
of 5.
Here are the 5 changes that Carl proposed:
>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".
Instead of Carl's 5 changes, nlo 3 of 4 and nlo 4 of 4 propose the following
3 changes:
nlo 3 of 4:
- Remove returning the job's "attribute-natural-language" in a Get-Jobs
response unless the requester asks for the job's
"attribute-natural-language" Job Description attribute.
nlo 4 of 4:
- Eliminate "textWithoutLanguage" attribute syntax
- Eliminate "nameWithoutLanguage" attribute syntax
Note: We can accomplish nlo 3 of 4 by deleting one paragraph in Get-Jobs
Response. Also this change can be done whether we agree to nlo 4 of 4 or
not.
Here is an attempt to explain why Bob, Carl and I came up with the 3 changes
proposed nlo 3 of 4 and nlo 4 of 4 instead of Carl's 5 original proposed
changes:
nlo 3 of 4 is similar to Carl's #2, but keeps "attributes-natural-language"
as a Job Description attribute, that we believe that all implementations are
currently copying from the operation attribute to the job (the new nlo test
scripts test this too). Keeping it is useful for an operator who has to
communicate with the user in a multi-lingual situation. Secondly, keeping
"attributes-natural-language" as a Job Description attribute is useful to
the Print system that has to print out a job start sheet in different
languages and would like to make it the language of the submitter of that
job. Finally, in our notification proposals, the Print system needs to know
what language to e-mail completion message in, so storing the submitter's
natural-language in the job seem very useful.
Instead nlo 3 of 4 simply removes returning the job's
"attribute-natural-language" in a Get-Jobs response unless the requester
asks for the job's "attribute-natural-language".
nlo 4 of 4 says Carl's #3 and #4. But instead of doing Carl's #1 and #5,
nlo 4 of 4 just keeps "attributes-natural-language" as an operation
attribute in requests, instead of deleting it from requests and introducing
a new (but more clearly named) attribute in requests, since everyone has
implemented it that way. No reason to rename an attribute that everyone is
already doing.
Since we mailed out nlo 4 of 4 we have had the email discussion that we
could make it a SHOULD NOT for returning "attributes-natural-language" as an
operation attribute in responses (Carl's proposal was to eliminate it as an
operation attribute in responses, since Carl's #1 proposed to eliminate it
altogether, but bring it back renames as an operation attribute in requests
only - Carl's # 5).
Sorry that this is so complicated. I think we all agree that we made a
mistake back in May when we didn't accept Carl's and Keith Moore's
suggestion to always use textWithLanguage and nameWithLanguage. We
mistakenly thought that it would help some implementations to have both.
Also, I'm sure some of us thought that it would decrease the number of bytes
on the wire too (though Carl has shown that it doesn't really and besides
such a savings, if there were any not important).
But now we have real implementations and products and so we don't want to
make changes to the standard that would invalidate them, unless they are
willing to change (or we work out some interoperability strategy that works
with them).
Tom
>-----Original Message-----
>From: Stuart.Rowley at kyocera.com [mailto:Stuart.Rowley at kyocera.com]
>Sent: Friday, November 06, 1998 08:57
>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
>