4.1.1.3
4.1.2.3 Added sections about comparing textWithLanguage and
textWithoutLanguage indicating that the explicit language MUST match the
implicit language. Same for comparing nameWithLanguage and
nameWithoutLanguage. A keyword value never matches either type of value,
even if the language is 'en-us'. (Issue 1.33 and 1.34)
The following text is to be added to make a new section under 4.1.1 'text':
4.1.1.3 Matching 'textWithLanguage' and 'textWithoutLanguage'
For purposes of matching 'text' values for equality in job validation, where
a client-supplied value for attribute "xxx" is checked to see if the value
is among the values of the Printer's corresponding "xxx-supported"
attribute, the following match criteria apply:
1. The attribute syntax and value of "xxx" supplied by the client MUST be
identical to the attribute syntax and value of one of the values of the
corresponding Printer's "xxx-supported" attribute. For example, the
client-supplied 'keyword' 'iso-a4-white' does not match the Printer's 'name'
'iso-a4-white', even if the Printer's "natural-language-configured" is
'us-en'.
2. For purposes of matching 'text' attributes, the attribute value
comparison SHOULD include a case-insensitive algorithm and MAY include other
equivalencies, such as accent-insensitive matching, depending on language
and implementation.
3. For purposes of matching 'text' attributes, the implicit or explicit
natural language of the "xxx" value supplied by the client MUST be the same
as the implicit or explicit natural language of the Printer's
"xxx-supported" attribute. For example, a client's nameWithoutLanguage
value with an 'en' "attributes-natural-language" will match either a
Printer's "xxx-supported value which is (1) 'en' textWithLanguage or (2)
textWithoutLanguage with an 'en' "natural-language-configured". Similarly,
a client's 'en' textWithLanguage value will match either a Printer's
"xxx-supported value which is (1) 'en' textWithLanguage or (2)
textWithoutLanguage with an 'en' "natural-language-configured".
4. Whether the country part of the natural language has to match depends on
implementation. So a client's 'en' MAY or MAY NOT match a Printer's 'en-us'
or 'en-gb'. Similarly, a client's 'en-us' MAY or MAY NOT match a Printer's
'en'. A client's 'en-gb' SHOULD NOT match a Printer's 'en-us'.
and add the following as a new section 4.1.2.3:
4.1.2.3 Matching 'nameWithLanguage' and 'nameWithoutLanguage'
For purposes of matching 'name' values for equality in job validation, where
a client-supplied value for attribute "xxx" is checked to see if the value
is among the values of the Printer's corresponding "xxx-supported"
attribute, the analogous rules apply to 'name' attribute values as described
in Section 4.1.1.3 for 'text' attribute values.
Thanks,
Tom
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Thursday, October 01, 1998 16:33
To: ipp@pwg.org
Subject: IPP> Keyword/Name matching
In Savannah, we weren't sure about one of Carl's questions. He has
elaborated
as follows...
The MOD doc says:
Some attributes are defined as 'type3 keyword | name'. These attributes
support values that are either type3 keywords or names. This dual-syntax
mechanism enables a site administrator to extend these attributes to legally
include values that are locally defined by the site administrator. Such
names
are not registered with IANA.
Example: job-hold-until (type3 keyword | name (MAX))
Printer administrator configures Printer such that (1setOf type3 keyword |
name)"job-hold-until-supported" contains two values:
(type3 keyword)'second-shift' and
(name)'one-of-these-days'.
Client request [with "attribute-fidelity" = (boolean)true] contains
"job-hold-until" attribute with value (name)'second-shift'.
Does the Printer reject the request and return "job-hold-until" attribute
with
value (name)'second-shift' in the unsupported attributes group? Or does it
accept (name)'second-shift' as a match for (type3 keyword)'second-shift' and
accept the request?
-Carl
Harry Lewis - IBM Printing Systems