>-----Original Message-----
>From: Hugo Parra [mailto:HPARRA at novell.com]
>Sent: Thursday, October 29, 1998 10:56
>To: hastings at cp10.es.xerox.com; ipp at pwg.org>Subject: RE: IPP> MOD - NLO 2 of 4: Clarification that Natural Language
>Override MAY be used redundantly
>>>Isn't support for the nameWithLanguage syntax mandatory in the
>June 30 spec? A client that doesn't support it is non
>compliant. Why should we be concerning ourselves with it?
Only for the practical reason that shipping a server/printer product that
breaks a large number of deployed clients, isn't a healthy strategy. If
everyone agrees to make sure their clients are conforming, then there is no
problem.
Unfortunately, we don't have a good test system for clients, as Paul Moore
as pointed out. We have been developing tests for server/printers.
However, the scripts that we are in the final stages of debugging
(currently, one bug remaining in the script, one in the test system, and one
in the implementation that we are testing against) could be used to test a
client. By running the script, it submits 3 different jobs in 3 different
languages to a June 30 compliant server. Then the client that you wanted to
test could be asked to query the jobs on that printer and see if the client
breaks or not.
Tom
>>-Hugo
>>>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 10/29/98 11:17AM >>>
>One problem with this clarification is that if an
>implementation starts to
>return nameWithLanguage, but the client doesn't support
>accepting that form,
>since it never generates that form, there will be a lack of
>interoperability.
>>I've talked to several implementers who are reluctant to take
>advantage of
>this clarification for fear the some clients will not be able
>to accept the
>nameWIthLanguage form.
>>For example, the client supplies the "job-name" operation
>attribute using
>nameWithoutLanguage, but the implementation returns it using
>nameWIthLanguage. If the client just blindly displays the
>value, it will be
>corrupted, since the value has two binary numbers and the
>natural language
>as well as the actual job name text.
>>Because we don't have a test tool that tests clients, we can
>verify that the
>clients will be able to accept nameWithLanguage on any attribute whose
>attribute syntax is 'name'.
>>Even if the client only supports one natural language, it
>could test itself
>with an IPP object that is configured for a different natural language,
>because then that IPP object would be forced into returning
>nameWIthLanguage. Of course, if all implementations are only
>supporting
>en-us, then even that test is impossible.
>>So before implementations start taking advantage of this proposed
>clarification, we need to verify that clients are conforming
>by supporting
>accepting in a response:
>>1. BOTH the nameWithoutLanguage and the nameWithLanguage
>forms for 'name'
>attributes
>2. BOTH the textWithoutLanguage and the textWithLanguage
>forms for 'text'
>attributes
>>Tom
>>>-----Original Message-----
>>From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
>>Sent: Wednesday, October 21, 1998 08:51
>>To: ipp
>>Subject: IPP> MOD - NLO 2 of 4: Clarification that Natural Language
>>Override M AY be used redundantly
>>>>>>The purpose of this clarification is to explicitly allow use
>>of the Natural
>>Language Override in situations where implementers thought it
>>couldn't be
>>used. Therefore, this clarification should not force any existing
>>conforming implementations to change.
>>>>There seems to be general agreement to clarify the
>>specification so that a
>>request or response MAY contain a Natural Language Override
>>for an attribute
>>value, even when the natural language is the same as the
>>natural language
>>specified for the request or response in the
>>"attributes-natural-language"
>>Operation attribute. So the sender of a request or a response
>>MAY include
>>the 'textWithlanguage' or 'nameWithLanguage' data type even when it
>>specifies a natural language that is the same as that
>>specified for that
>>request or response in the "attributes-natural-language" Operation
>>attribute. Therefore, an implementation could always use the
>>'xxxxWithLanguage' forms with all attributes.
>>>>================================================
>>= Please reply to this e-mail message if there is any disagreement
>>= on this clarification. If no disagreements are returned by Monday,
>>= November 2, it will be considered an agreed clarification.
>>================================================
>>>>Note: that the votes on e-mail messages (3 of 4) and (4 of 4)
>>may remove the
>>need for this (2 of 4) clarification. But please comment on these
>>clarifications assuming that the changes specified in the votes do NOT
>>happen.
>>>>>>The current text in Section 3.1.4.1 Request Operation Attributes, 5th
>>paragraph of "attributes-natural-language says:
>>>> For any 'text' or 'name' attribute in the
>>request that is in
>>a different natural language than the value supplied in the
>>"attributes-natural-language", the client MUST use the
>Natural Language
>>Override mechanism (see sections 4.1.1.2 and 4.1.2.2) for each such
>>attribute value supplied.
>>>>The clarification is to add the following sentence to the end of the
>>paragraph:
>>>> The client MAY use the Natural Language
>>Override mechanism
>>even when the value is in the same natural language.
>>>>The 7th paragraph says:
>>>> Whenever any client queries the Job object's "job-name"
>>attribute, the IPP object returns the attribute as stored and uses the
>>Natural Language Override mechanism to specify the natural
>>language, if it
>>is different from that reported in the "attributes-natural-language"
>>operation attribute of the response.
>>>>The clarification is to add the following sentence:
>>>> The IPP object MAY use the Natural Language Override
>>mechanism even when the value is in the same natural language.
>>>>The last paragraph of 3.1.4.2 contains the sentence:
>>>> For any 'text' or 'name' attribute or status
>>message in the
>>response that is in a different natural language than the
>>value returned in
>>the "attributes-natural-language" operation attribute, the IPP
>>object MUST
>>use the Natural Language Override mechanism (see sections 4.1.1.2 and
>>4.1.2.2) on each attribute value returned.
>>>>The clarification is to add the same following sentence:
>>>> The IPP object MAY use the Natural Language Override
>>mechanism even when the value is in the same natural language.
>>>>>>>>Tom Hastings
>>(310) 333-6413
>>>>>>>>>>>