IPP> MOD - Tentative decision on natural language overri

IPP> MOD - Tentative decision on natural language overri

IPP> MOD - Tentative decision on natural language overri

Hugo Parra HPARRA at novell.com
Fri Nov 6 13:09:16 EST 1998


I second what Harry and Stuart wrote.  In retrospect, I can't believe the group voted to upheld the June 30th spec before we carried out any formal interoperability testing of the spec.  Why did the PWG gave its stamp of approval without formal proof that two independently-developed implementations interoperated in all areas.  I believe, the hours and hours of discussion trying to clarify what the spec means by language override disqualifies our implementations as "independent".  If, despite our poor decision in Monterrey, we still want to stick with the June 30th spec, so be it; but we should make formal interoperability testing part of the PWG process so history doesn't repeat itself.

-Hugo

>>> Harry Lewis <harryl at us.ibm.com> 11/06/98 10:39AM >>>
Stuart, you echo my sentiments exactly. I have tried, on the wire and in the
calls to bring the focus back to Carl's original (and much simpler)
observations. (See http://www.pwg.org/hypermail/ipp/1490.html).  I think the
problem is that some implementations are already using some of the (difficult
to understand) "features" in  striving for conformance to the June 30 drafts.
It's just unfortunate that we were not able to focus sooner on the problem
which was surfaced in May. I believe Tom tried to bend Carl's proposal into the
reality of the situation... looking for a compromise solution. I agree.. it
looks that much more complicated in this context.

It is fairly well agreed there is not much we can do with respect to Servers
(Printers?), at this point but some hope may still lay in the Clients. If we
can restrict client behavior (say, to always use textWithLanguage) it might
govern server response (to, similarly, always use textWithLanguage)... nearly
achieving Carl's proposal. But, some Servers already have decided to make use
of textWithoutLanguage in situations where Languages on the request and
response are identical (a common sense implementation given the absence of a
rule like Carl was proposing... "always use textWithLanguage").

So, we feel pretty boxed in. I agree, however, any reasoning discussed on the
call should be echoed on the DL for all to understand.

Harry Lewis - IBM Printing Systems
harryl at us.ibm.com 



owner-ipp at pwg.org on 11/05/98 10:07:44 PM
Please respond to owner-ipp at pwg.org 
To: hastings at cp10.es.xerox.com, ipp at pwg.org 
cc:
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




More information about the Ipp mailing list