IPP Mail Archive: IPP> MOD/PRO - simple proposal for providing dictionary-like

IPP Mail Archive: IPP> MOD/PRO - simple proposal for providing dictionary-like

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

Tom Hastings (hastings@cp10.es.xerox.com)
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