Can a Get-Jobs response redundantly return a job-level
"attributes-natural-language" (when not requested) which has the same
natural language as the job? If yes, then it may be simpler for IPP Printer
implementations to ALWAYS add the "attributes-natural-language" in the
returned Job Attributes (first), whether the job is in that natural language
or not.
Since a client is supposed to be able to deal with job-level NLO according
to the June drafts, this redundancy would not be adding any more complexity
to the clients.
Comments?
Tom
>-----Original Message-----
>From: Hastings, Tom N [mailto:hastings@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
>
>
>
>
>