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

From: Jay Martin <[email-masked]>
Date: Wed, 01 Apr 1998 15:19:57 -0500

Paul,

Sorry, but I wasn't able to attend the Maui meeting, so perhaps
you can clarify something about the perceptions of "IPP v2"
for me.

The way I read your message (below), IPP v2 will have a totally
different encoding than IPP v1 (ie, non-standard BER-like
quasi-binary encoding vs. structured text).

Is this correct?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Wed, 01 Apr 1998 15:21:14 -0500

Paul,

Sorry, but I forgot to include the message I referenced in
that last message.

	...jay

Paul Moore wrote:
> 
> I agree - this is one of the areas where we all agreed that XML won with no
> debate whatsoever.
> 
> We all know the history of this debate (XML or not XML). We decided to keep
> the current protocol for IPP1. The informal consensus in maui was that IPP2
> (which I think the dictionary discussion is aimed at) must be XML-based.
> 
> If we dont make that change then we will regret it for ever and ever.
> 
> > -----Original Message-----
> > From: Robert Herriot [SMTP:[email-masked]]
> > Sent: Monday, March 30, 1998 5:51 PM
> > To:   [email-masked]; Tom Hastings
> > Cc:   [email-masked]
> > Subject:      Re: IPP> MOD/PRO - simple proposal for providing
> > dictionary-like capability
> >
> > 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
> >
> >
> >
> >
> > At 01:16 PM 3/25/98 , James Walker wrote:
> > >Tom Hastings wrote:
> > >>
> > >> For the IPP telecon, Wed, 3/25:
> > >>
> > >> Roger, Bob, and I have been working on various dictionary proposals.
> > >>
> > >> ...
> > >>
> > >> 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".
> > >
> > >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'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.
> > >>
> > >> ...
> > >
> > >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
> > >