Subject: IPP> MOD/PRO - simple proposal for providing dictionary-like capability

From: Tom Hastings <[email-masked]>
Date: Tue, 24 Mar 1998 15:36:34 PST

For the IPP telecon, Wed, 3/25:

Roger, Bob, and I have been working on various dictionary proposals.

Last Friday, we had a teleconference on version 0.8.  After Roger
hung up, Bob and I came up with yet another simpler proposal which
is version 0.9.  I edited the document, but neither Bob nor Roger
have had the time to send me comments, since they are both away
at meetings this week.

However, Carl-Uno thought it would be good to at least discuss this
work in progress.  Send any comments before hand and/or I'll present
the ideas on the telecon.  I've posted:

ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-1setOf-1setOf.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-dict-1setof-1setof.pdf

Briefly, the scheme isn't really a dictionary at all (previous 
versions were).  Other earlier versions were adding a new addressing
mechanism for attributes in dictionaries.

This proposal adds no new addressing mechanisms,
but justs add a new out-of-band value to encode the new Model attribute
syntax of 1setOf 1setOf (doubly nested values).  Instead, we use the
idea of attributes with parallel values, like we already have for 
"printer-uri-supported" and "uri-security-supported".  

I fleshed out a real world example for "job-notify", "job-notify-default", 
and "job-notify-supported" to show how it works, along with a simpler 
"printer-resolution", "printer-resolution-default" and
"printer-resolution-supported" example.

I've left the rejected example that uses the 'dictionary' attribute syntax
in the document.  I've also listed the alternatives that we considered
and the reasons for rejecting them.

There are two issues remaining:

ISSUE 1:  If a 1setOf 1setOf value is a single value, does the sender need
to include the double nesting or not?  It would be nice if our encoding
would allow a single value, i.e.,:

    "job-notify-method-supported"	'mailto', { 'sense', 'tcp/ip-socket' }

for representing:

     job-notify-method-supported (1setOf 1setOf type2 keyword)

where the "{" indicates the begin and the "}" indicates the end.  Thus the
new begin and end construct is not needed for every use of 1setOf 1SetOf, 
only when there are actually more than one value for the second 1setOf.

Here is what I have for the encoding:

5 Encoding

In order to allow the 1setOf 1setOf to be represented as merely 1setOf when
there is only one value in a set of parallel attributes, we need a begin
and end indication of a set of values that are to be grouped together into
a 1setOf 1setOf.

The simplest and most compatible way to add simple begin and end markers
that can be ignored by existing parsers is to use an attribute to mean
begin of a 1setOf 1setOf and another attribute to flag the end of a 1setOf
1SetOf value.  Since the begin and end flags don't need any values, it is
simplest to add a single out-of-band value, say, 'value-marker' and then
introduce two new attributes that use it:  "begin-set-of-set" and
"end-set-of-set".

ISSUE 2:  Ok to use the same "out-of-band" with different attributes
to get the begin and end?

Tom

---

From: James Walker <[email-masked]>
Date: Wed, 25 Mar 1998 15:16:12 -0600

Tom Hastings wrote:
> ...

As discussed in the telecon today, I think that the parallel attribute
idea is a bad one... it does not scale well, it is difficult for users
to understand and get right, it is error-prone, etc.  Our experience
from the implementation of parallel attributes in DPA has not been a
good one.  All in all, I believe that data structures are a good idea,
but trying to describe data structures using parallel attributes does
not work.

> ...
> ...

I simply do not understand why the original concept of a dictionary
value tag (with its associated value length) would not work well.
This is the example that is shown in Tom's document.

...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: Robert Herriot <[email-masked]>
Date: Mon, 30 Mar 1998 17:51:25 -0800

Jim,

I have similar concerns about the use of attributes with parallel values.
I have this nagging feeling that we are going to regret this direction.
But thus far it has been the least bad solution that we have found.

We have arrived at this unfortunate point because the current binary
encoding has painted us into a corner. An XML encoding would 
allow a very simple solution for dictionaries.

We considered having dictionary members appear as normal attributes
surrounded by begin-dictionary and end-dictionary "values", but this solution
would potentially create name conflicts with names at the top level for
parsers

that don't know about dictionaries. This solution works if we force a version
change or all existing parsers add support  for it.

We considered having a dictionary structure which would be a new type
whose values are nested in an existing value. For small dictionaries, this
is the obvious and simple solution, but if we kept the existing limit
of 1023 octets per value, some dictionaries would be impossible.  Picking 
a value that is large enough for all likely dictionaries but doesn't burden
small implementations was difficult and didn't seem to solve the problem.
We looked at ways to keep the 1023 limit and instead chunk the dictionary
into multiple values. I had  a reasonable but very ugly solution which 
concatenated the chunks together and use "begin-dictionary" and 
"end-dictionary" "values" to indicate the structure.

By turning the dictionary problem into a naming problem, we seem to have
side stepped all of these issues, but as you point out data structures were
invented for a reason.

Do you have any suggestions for what we should do?

Bob Herriot