-Hugo
>>> "Hastings, Tom N" <hastings@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@cp10.es.xerox.com]=20
>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=20
>of the Natural
>Language Override in situations where implementers thought it=20
>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=20
>specification so that a
>request or response MAY contain a Natural Language Override=20
>for an attribute
>value, even when the natural language is the same as the=20
>natural language
>specified for the request or response in the=20
>"attributes-natural-language"
>Operation attribute. So the sender of a request or a response=20
>MAY include
>the 'textWithlanguage' or 'nameWithLanguage' data type even when it
>specifies a natural language that is the same as that=20
>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.
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=3D Please reply to this e-mail message if there is any disagreement=20
>=3D on this clarification. If no disagreements are returned by Monday,=20=
>=3D November 2, it will be considered an agreed clarification.
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Note: that the votes on e-mail messages (3 of 4) and (4 of 4)=20
>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=20
>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=20
>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=20
>language, if it
>is different from that reported in the "attributes-natural-language"
>operation attribute of the response. =20
>
>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=20
>message in the
>response that is in a different natural language than the=20
>value returned in
>the "attributes-natural-language" operation attribute, the IPP=20
>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
>
>
>
>
>