So the real issue is whether the NLO stuff has been properly implemented or
not according to the June drafts and/or do our implementations interoperate
in the NLO dimension. If our implementations don't interoperate, then its a
bug that we could fix in the spec (or our implementations). That is why it
is so important to get people to run the new scripts distributed on
Wednesday to see if we really do implement the June specs in the NLO area,
i.e., do our NLO interoperate or not.
If any Bake-Off participant is having trouble running the scripts, please
give me a call at : (310) 333-6413.
They should only take about 10-15 minutes to run. I'll help you interpret
the results over the phone, if you wish.
Thanks,
Tom
>-----Original Message-----
>From: Paul Moore [mailto:paulmo at microsoft.com]
>Sent: Friday, November 06, 1998 11:23
>To: 'Harry Lewis'; ipp at pwg.org>Cc: stuart.rowley at kyocera.com; HPARRA at novell.com>Subject: RE: IPP> MOD - Tentative decision on natural language overri
>>>Fixing bugs is certainly acceptable (and probably inevitable).
>>I am not sure whether the current NLO debate falls into the
>'bug' category
>or a 'we could have done it better if had thought about it
>more' category.
>These are not acceptable in the terms of the GA vote.
>>-----Original Message-----
>From: Harry Lewis [mailto:harryl at us.ibm.com]
>Sent: Friday, November 06, 1998 11:11 AM
>To: ipp at pwg.org>Cc: stuart.rowley at kyocera.com; HPARRA at novell.com; Paul Moore
>Subject: RE: IPP> MOD - Tentative decision on natural language overri
>>>I thought the direction established between Monterey and
>Savannah was to
>freeze
>the June 30 draft to any additional "new function" which was under
>consideration (IPP scheme, Security etc). I do not believe
>clarification was
>banned, otherwise, why did we Inteop test?
>>The motion - as recorded in the PWG Plenary (and my own)
>minutes clearly
>references "that we plan to update the June 30 drafts with corrections
>resulting from the Bake-off (and other experience)..." There
>was nothing in
>the
>"vote" that said we could not or would not address
>deficiencies in our own
>draft, in fact, I definitely understood this as the goal! Hugo clearly
>reminded
>us, in Savannah, that topics already on the "issues list" were
>(potentially)
>as
>significant as topics discovered at the bakeoff.
>>The decision how far to "go" with an implementation or when to
>"ship" is an
>individual one and we have all been very frustrated by the
>desire to "make
>good" on our IPP efforts. I think most PWG members are
>sensitive to the fact
>that we all ware similar shoes at some point... which fosters
>a cooperative
>demeanor worth preserving. I would like to continue to seek clean-cut
>resolution to the NL/NLO problems which have been on the table
>for 5 months
>while stepping on as few toes as possible.
>>>Harry Lewis - IBM Printing Systems
>harryl at us.ibm.com>>>>paulmo at microsoft.com on 11/06/98 11:38:29 AM
>Please respond to paulmo at microsoft.com>To: Harry Lewis/Boulder/IBM at ibmus, ipp at pwg.org, HPARRA at novell.com>cc: stuart.rowley at kyocera.com>Subject: RE: IPP> MOD - Tentative decision on natural language overri
>>>Hindsight is a wonderful thing (BTW it was Savanahh not
>Monterey where we
>finally really voted on the spec). We all had a vote, including Novell.
>Several people said - whoa, we havent tested localization, we
>havent tested
>security. Despite that the vote was unanimous (one abstention
>that was later
>change to yes). People have taken product decisions based on that vote.
>>What are you proposing - that the formally defined and agreed
>PWG voting
>process is not really binding and that we can all change our
>mind later. It
>may or may not have been a good result - but it was the result.
>>We could have another vote undoing the previous one. Why not put that
>forward as a motion in Tuscon.
>>-----Original Message-----
>From: Hugo Parra [mailto:HPARRA at novell.com]
>Sent: Friday, November 06, 1998 10:09 AM
>To: ipp at pwg.org; harryl at us.ibm.com>Cc: stuart.rowley at kyocera.com>Subject: Re: IPP> MOD - Tentative decision on natural language overri
>>>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
>>