As long as you've re-opened this issue, I'd like to add several
other alternatives into the mix. (A committee is better able to
pick between alternatives, than to design one on the fly).
On the other hand, it may be better to live with the current scheme
than to try to pick a new one.
At 19:48 11/21/1997 PST, Robert Herriot wrote:
>>As I am implementing the CompoundValue, I am finding problems that make
>me think it should be changed. It requires too much special-casing and
>in its current form it will introduce bugs where the value of the
>CompoundValue exceeds the number of remaining attributes for the
>attribute name or attribute group. To avoid those bugs, checks have to
>be made in several places.
Please explain this problem more.
>>I suggest we reexamine the other possible solutions, one simple with
>no room for extension, the other with room for extension.
>> a) add two new value types: text-language and name-language each of which
> is a single value in the protocol but which consists of 4 subfields:
> a text/name length field, a text/name field, a language length field,
> and a language field, .
>> b) add a single new type: compound-value which consists of a single value
> in the protocol but which consists of a value-tag field followed by
> any number of groups-of-three subfields. Each group-of-three
> consists of a value tag, a value length and a value. The text-language
> solution of a) is represented by a text-language tag, a text tag, a
> text length, a text value, a natural-language-tag, a natural-language
> length and a natural-language value.
>>I prefer b) because it offers room for extension and an implementation can
>determine if it supports the compound value by examining the initial
>tag in the compoundValue.
Here are my additional alternatives:
c) Amplify the 'text' and 'name' attribute syntaxes to allow a second
natural language override value to precede the actual value which indicates
the language of the immediately following value. The attribute syntax of
the first value, when present, is: 'naturalLanguage' as defined in the
current spec.
Advantages: simple
Disadvantages: a single-valued attribute sometimes has two values, making
the validation of single-valued attributes more adhoc. Also counting
attribute values is more adhoc.
d) have two data types for each of 'text' and 'name':
'text' (same as current) and 'taggedText'
'name' (same as current) and 'taggedName'
The 'taggedText' and 'taggedName' data types use the RFC 2184 tagging
in the beginning of the data (but for language only, not charset)
to indicate natural language override:
en'...
en-us'...
to indicate English and U.S. English
Those attributes which currently have 'text' and 'name' would
be changed to require support of both 'text' and 'taggedText'
and 'name' and 'taggedName'
For example:
job-name (name | taggedName)
Advantages: most request/response instances would not need to use the
taggedText and taggedName in most interchanges.
Disadvantages: clients and IPP objects would still have to support both
forms.
e) Change the spec for 'text' and 'name' to always require the RFC 2184
natural language prefix (but not charset).
Advantages: simple, natural language tag is always stored with the data.
Only one protocol value for each attribute value.
Disadvantages: tag has to be skipped over when processing or displaying
the data.
f) Same as e) except include the charset tag as well, so in full compliance
with RFC 2184 (same as we had in the Model document after the Atlanta
meeting). Example:
us-ascii'en'...
utf-8'en-us'...
Advantages: simple, charset and natural language tag is always stored
with the data. Only one protocol value for each attribute value.
IPP object doesn't need to charset convert data to a single charset.
Disadvantage: tags have to be skipped over when processing or displaying
the data.
g) Add the dictionary attribute syntax that we postponed.
Advantages: It is even more general than your alternative b) and is
something we have agreed is something we want. I'd hate to see us
put in something that is half a dictionary. I think that the dictionary
also fixes the length checking problem that the current CompoundValue
has, correct?
Disadvantages: None.
Tom