Subject: IPP>MOD add another issue

From: [email-masked] (Robert Herriot)
Date: Fri, 21 Nov 1997 19:48:44 -0800

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.

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.

---

From: Tom Hastings <[email-masked]>
Date: Mon, 24 Nov 1997 09:22:21 PST

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.

>be made in several places.

Please explain this problem more.

>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