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?
-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
>>>>>