This is a multi-part message in MIME format.
--------------03F1D2F48D1D31E99F75DE1F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Although compoundValue can be made to work, its complexity will lead to
> bugs. Also its type is determined by looking at all of the tags of
> values that it contains. This suggests that we should look for a
> simpler-to-implement option.
>> The most obvious solution is to add two new types text-language and
> name-language which are the langauge constrained versions of text and
> name.
>Since we still have 'compound-attribute' in the protocol, couldn't we represent
'textWithLanguage' and 'nameWithLanguage' using that mechanism?
(The 'textWithLanguage' attribute syntax is a compound attribute syntax, represented as an
OCTET_STRING consisting of 4 fields: a) a SIGNED-SHORT which is the number of octets in the
following field b) a value of type natural-language, c) a SIGNED-SHORT which is the number
of octets in the following field, d) a value of type text. The length of a
textWithLanguage value SHALL be 4 + the value of field a + the value of field c.).
I'm finding all these embedded lengths to be a pain to implement, and it seems redundant with
the logic we already have for compound-attribute.
-Carl Kugler
======================Original message=========================
> Re: IPP>MOD add another issue [encoding of CompoundValue]
>> Robert Herriot (Robert.Herriot at Eng.Sun.COM)
> Tue, 25 Nov 1997 18:54:45 -0800
>> * Messages sorted by: [ date ][ thread ][ subject ][ author ]
> * Next message: Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues"
> * Previous message: Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC"
>> I will try to explain the issue by giving more detail.
>> The compoundValue has an integer value which specifies the number of
> following values that compose the compound value. There are two
> obvious ways to implement compoundValue in a general way:
>> 1) recurse looking for additional values until the correct number
> is found or until a non-null attribute name is found or a delimiter
> tag is found. The latter two conditions are errors. This method
> works, but is tricky the "nested" values are really at the same
> level as other values in the protocol.
>> 2) continue picking up values, but make a note that a compoundValue
> is being built. In this case, there must be a check when a
> non-null name is encountered, and when a delimiter tag is found
> for the error of a compoundValue is still being built.
> At first glance, this seems simpler, but it is easy to forget the
> checks mentioned above.
>> Although compoundValue can be made to work, its complexity will lead to
> bugs. Also its type is determined by looking at all of the tags of
> values that it contains. This suggests that we should look for a
> simpler-to-implement option.
>> The most obvious solution is to add two new types text-language and
> name-language which are the langauge constrained versions of text and
> name. Attributes with text and name values could also have a value of
> type text-language or name-language. Tom and others have suggested
> that language and text/name be separated by a single-quote character.
> It would work, but is not in the spirit of the current protocol which
> uses lengths instead of delimiting characters. So I suggest the value
> be <language length> <language string> <text/name string>. The length
> of the text/name string is length of the value minus ( language-length
> + 2).
>> This solution is easier to parse because the components are contained
> with a single value.
>> If we believe that tags are in short supply and that we don't want to
> allocate two values for such obscure types, we could create a tag type
> of "typed-octets" where the first byte of the value contains the
> sub-tag value which in our case would be either text-language or
> name-language. We could also have 2 bytes for the sub-tag rather than
> 1.
>> > From hastings at cp10.es.xerox.com Mon Nov 24 10:46:48 1997
> >
> > 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
> >
> >
> >
> >
>> * Next message: Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues"
> * Previous message: Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC"
http://www.pwg.org/hypermail/ipp/2831.html
--------------03F1D2F48D1D31E99F75DE1F
Content-Type: text/html; charset=us-ascii; name="2831.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="2831.html"
Content-Base: "http://www.pwg.org/hypermail/ipp/2831.
html"
<!-- received="Tue Nov 25 21:55:45 1997 EST" -->
<!-- sent="Tue, 25 Nov 1997 18:54:45 -0800" -->
<!-- name="Robert Herriot" -->
<!-- email="Robert.Herriot at Eng.Sun.COM" -->
<!-- subject="Re: IPP>MOD add another issue [encoding of CompoundValue]" -->
<!-- id="199711260254.SAA28805 at woden.eng.sun.com" -->
<!-- inreplyto="IPP>MOD add another issue [encoding of CompoundValue]" -->
<title>IPP Mail Archive: Re: IPP>MOD add another issue [encoding of CompoundValue]</title>
<h1>Re: IPP>MOD add another issue [encoding of CompoundValue]</h1>
Robert Herriot (<i>Robert.Herriot at Eng.Sun.COM</i>)<br>
Tue, 25 Nov 1997 18:54:45 -0800
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#2831">[ date ]</a><a href="index.html#2831">[ thread ]</a><a href="subject.html#2831">[ subject ]</a><a href="author.html#2831">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="2832.html">Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues"</a>
<li> <b>Previous message:</b> <a href="2830.html">Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC"</a>
<!-- nextthread="start" -->
</ul>
<!-- body="start" -->
I will try to explain the issue by giving more detail.<br>
<p>
The compoundValue has an integer value which specifies the number of<br>
following values that compose the compound value. There are two<br>
obvious ways to implement compoundValue in a general way:<br>
<p>
1) recurse looking for additional values until the correct number<br>
is found or until a non-null attribute name is found or a delimiter<br>
tag is found. The latter two conditions are errors. This method<br>
works, but is tricky the "nested" values are really at the same<br>
level as other values in the protocol.<br>
<p>
2) continue picking up values, but make a note that a compoundValue<br>
is being built. In this case, there must be a check when a<br>
non-null name is encountered, and when a delimiter tag is found<br>
for the error of a compoundValue is still being built.<br>
At first glance, this seems simpler, but it is easy to forget the<br>
checks mentioned above. <br>
<p>
Although compoundValue can be made to work, its complexity will lead to<br>
bugs. Also its type is determined by looking at all of the tags of<br>
values that it contains. This suggests that we should look for a<br>
simpler-to-implement option.<br>
<p>
The most obvious solution is to add two new types text-language and<br>
name-language which are the langauge constrained versions of text and<br>
name. Attributes with text and name values could also have a value of<br>
type text-language or name-language. Tom and others have suggested<br>
that language and text/name be separated by a single-quote character.<br>
It would work, but is not in the spirit of the current protocol which<br>
uses lengths instead of delimiting characters. So I suggest the value<br>
be <language length> <language string> <text/name string>. The length<br>
of the text/name string is length of the value minus ( language-length<br>
+ 2). <br>
<p>
This solution is easier to parse because the components are contained<br>
with a single value.<br>
<p>
If we believe that tags are in short supply and that we don't want to<br>
allocate two values for such obscure types, we could create a tag type<br>
of "typed-octets" where the first byte of the value contains the<br>
sub-tag value which in our case would be either text-language or<br>
name-language. We could also have 2 bytes for the sub-tag rather than<br>
1.<br>
<p>
<i>> From hastings at cp10.es.xerox.com Mon Nov 24 10:46:48 1997</i><br>
<i>> </i><br>
<i>> As long as you've re-opened this issue, I'd like to add several</i><br>
<i>> other alternatives into the mix. (A committee is better able to</i><br>
<i>> pick between alternatives, than to design one on the fly).</i><br>
<i>> </i><br>
<i>> On the other hand, it may be better to live with the current scheme</i><br>
<i>> than to try to pick a new one.</i><br>
<i>> </i><br>
<i>> At 19:48 11/21/1997 PST, Robert Herriot wrote:</i><br>
<i>> ></i><br>
<i>> >As I am implementing the CompoundValue, I am finding problems that make</i><br>
<i>> >me think it should be changed. It requires too much special-casing and</i><br>
<i>> >in its current form it will introduce bugs where the value of the</i><br>
<i>> >CompoundValue exceeds the number of remaining attributes for the</i><br>
<i>> >attribute name or attribute group. To avoid those bugs, checks have to</i><br>
<i>> >be made in several places.</i><br>
<i>> </i><br>
<i>> Please explain this problem more.</i><br>
<i>> </i><br>
<i>> ></i><br>
<i>> >I suggest we reexamine the other possible solutions, one simple with </i><br>
<i>> >no room for extension, the other with room for extension.</i><br>
<i>> ></i><br>
<i>> > a) add two new value types: text-language and name-language each of which</i><br>
<i>> > is a single value in the protocol but which consists of 4 subfields:</i><br>
<i>> > a text/name length field, a text/name field, a language length field, </i><br>
<i>> > and a language field, .</i><br>
<i>> ></i><br>
<i>> > b) add a single new type: compound-value which consists of a single value</i><br>
<i>> > in the protocol but which consists of a value-tag field followed by </i><br>
<i>> > any number of groups-of-three subfields. Each group-of-three </i><br>
<i>> > consists of a value tag, a value length and a value. The text-language </i><br>
<i>> > solution of a) is represented by a text-language tag, a text tag, a </i><br>
<i>> > text length, a text value, a natural-language-tag, a natural-language</i><br>
<i>> > length and a natural-language value.</i><br>
<i>> ></i><br>
<i>> >I prefer b) because it offers room for extension and an implementation can</i><br>
<i>> >determine if it supports the compound value by examining the initial</i><br>
<i>> >tag in the compoundValue.</i><br>
<i>> </i><br>
<i>> Here are my additional alternatives:</i><br>
<i>> </i><br>
<i>> </i><br>
<i>> c) Amplify the 'text' and 'name' attribute syntaxes to allow a second</i><br>
<i>> natural language override value to precede the actual value which indicates </i><br>
<i>> the language of the immediately following value. The attribute syntax of </i><br>
<i>> the first value, when present, is: 'naturalLanguage' as defined in the</i><br>
<i>> current spec.</i><br>
<i>> </i><br>
<i>> Advantages: simple</i><br>
<i>> </i><br>
<i>> Disadvantages: a single-valued attribute sometimes has two values, making</i><br>
<i>> the validation of single-valued attributes more adhoc. Also counting</i><br>
<i>> attribute values is more adhoc. </i><br>
<i>> </i><br>
<i>> </i><br>
<i>> d) have two data types for each of 'text' and 'name': </i><br>
<i>> 'text' (same as current) and 'taggedText'</i><br>
<i>> 'name' (same as current) and 'taggedName'</i><br>
<i>> </i><br>
<i>> The 'taggedText' and 'taggedName' data types use the RFC 2184 tagging</i><br>
<i>> in the beginning of the data (but for language only, not charset)</i><br>
<i>> to indicate natural language override:</i><br>
<i>> </i><br>
<i>> en'...</i><br>
<i>> en-us'...</i><br>
<i>> </i><br>
<i>> to indicate English and U.S. English</i><br>
<i>> </i><br>
<i>> Those attributes which currently have 'text' and 'name' would</i><br>
<i>> be changed to require support of both 'text' and 'taggedText'</i><br>
<i>> and 'name' and 'taggedName'</i><br>
<i>> </i><br>
<i>> For example:</i><br>
<i>> </i><br>
<i>> job-name (name | taggedName)</i><br>
<i>> </i><br>
<i>> Advantages: most request/response instances would not need to use the </i><br>
<i>> taggedText and taggedName in most interchanges.</i><br>
<i>> </i><br>
<i>> Disadvantages: clients and IPP objects would still have to support both</i><br>
<i>> forms.</i><br>
<i>> </i><br>
<i>> </i><br>
<i>> e) Change the spec for 'text' and 'name' to always require the RFC 2184</i><br>
<i>> natural language prefix (but not charset).</i><br>
<i>> </i><br>
<i>> Advantages: simple, natural language tag is always stored with the data.</i><br>
<i>> Only one protocol value for each attribute value.</i><br>
<i>> </i><br>
<i>> Disadvantages: tag has to be skipped over when processing or displaying</i><br>
<i>> the data.</i><br>
<i>> </i><br>
<i>> </i><br>
<i>> f) Same as e) except include the charset tag as well, so in full compliance</i><br>
<i>> with RFC 2184 (same as we had in the Model document after the Atlanta </i><br>
<i>> meeting). Example:</i><br>
<i>> </i><br>
<i>> us-ascii'en'...</i><br>
<i>> utf-8'en-us'...</i><br>
<i>> </i><br>
<i>> Advantages: simple, charset and natural language tag is always stored </i><br>
<i>> with the data. Only one protocol value for each attribute value.</i><br>
<i>> IPP object doesn't need to charset convert data to a single charset.</i><br>
<i>> </i><br>
<i>> Disadvantage: tags have to be skipped over when processing or displaying</i><br>
<i>> the data.</i><br>
<i>> </i><br>
<i>> </i><br>
<i>> g) Add the dictionary attribute syntax that we postponed.</i><br>
<i>> </i><br>
<i>> Advantages: It is even more general than your alternative b) and is</i><br>
<i>> something we have agreed is something we want. I'd hate to see us</i><br>
<i>> put in something that is half a dictionary. I think that the dictionary</i><br>
<i>> also fixes the length checking problem that the current CompoundValue</i><br>
<i>> has, correct?</i><br>
<i>> </i><br>
<i>> Disadvantages: None.</i><br>
<i>> </i><br>
<i>> Tom</i><br>
<i>> </i><br>
<i>> </i><br>
<i>> </i><br>
<i>> </i><br>
<!-- body="end" -->
<p>
<ul>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="2832.html">Carl-Uno Manros: "Re: IPP>IPP Last Call - need advance list of issues"</a>
<li> <b>Previous message:</b> <a href="2830.html">Marcia Beaulieu: "IPP> Re: IPP conflict with TLS in DC"</a>
<!-- nextthread="start" -->
</ul>
--------------03F1D2F48D1D31E99F75DE1F--