ietf-openproxy
[Top] [All Lists]

RE: Adding structures and lists to OCP

2003-05-23 08:03:31


On Fri, 23 May 2003, Martin Stecher wrote:

I agree to most what you wrote and explained. Structures and lists
are useful elements and marking them with (curly) brackets helps to
scan and parse them easily.

These syntax changes should appear in the next draft release then,
provided there are no further objections or improvements.

The motivation to add nesting is also reasonable to me but I would
like to restrict it to a smaller minimum than you do. The deeper
nesting example (3b) is already very complex (I always had problems
with programming in LISP)

As long as we do not have good examples why we need nesting deeper
than level 1, I would like to restrict it to that.

So only allowing a value to be

  an atom
  a list/structure of atoms
  a list/structure of lists/structures of atoms

Agreed.

By the way: What is the current status of atoms? Strings, integers
and floats?

Actually, there are no well-defined "types" for atoms yet, only syntax
rules and some comments accompanying parameter definitions. As of now,
one can parse OCP messages but cannot check for parameter validity
beyond a few known restrictions. This will change.

I suspect the following atomic types will be needed to accommodate
current OCP needs:

        uri
        numeric identifier
        size
        probability
        TBD

The last one, "TBD" (to-be-defined) can be used to describe parameters
that will be determined by other specs. For example, a security
negotiation profile may have some custom parameter types that we
cannot predict and that do not fit any known OCP types.

Note that I do not see much benefit of defining "generic" types such
as "string", "integer", or "float" because we are not documenting a
general purpose programming language. OCP applications will have
specific uses for "integer-looking" parameters and are unlikely to
benefit from being able to, say, perform arithmetic operations on two
fields without knowing that field true meaning. In other words, if a
parameter is useful for you, you should know its exact type. Note that
it is still possible to _parse_ any parameter, whether you know its
type or not.

Thank you,

Alex.

<Prev in Thread] Current Thread [Next in Thread>