OCP Core is not going to define many profiles that will need to be
negotiated. Yet, actual implementations will have to agree on many
things, including data and metadata format. We should expect other
folks to be able to specify profiles using mechanisms that we provide.
(Moreover, it is not unlikely that some application bindings will use
OCP syntax to encode metadata, increasing demand for flexible syntax).
We want to be able to list profiles to facilitate selection of the
best profile(s) out of several offered choices. Thus, each profile
needs to be a structure (not a stand-alone message):
{ uri [optional anonymous profile-specific parameters] }
Note that parameters have to be anonymous values because structures do
not have named parameters. This places rather heavy restrictions on
parameter choice. For example, it is not possible to have independent
optional parameters -- if one anonymous parameter is omitted, all
parameters after it must be omitted. There are two outcomes I can
imagine:
1. Acknowledge the problem but do nothing about it. This
implies that profiles will have to list virtually all
parameters all the time and invent special values
for "unspecified" parameters:
{ "15:example.com/xxh" 7 -1 -1 -1 13 "SSL" "" }
This "ignorance" may lead to folks defining their own
syntax and types inside a quoted-value to get what they
want by parsing that quoted value:
{ "15:example.com/xxh" "25:sid=7 max=13 lib="3:SSL"" }
2. Add explicit support for named values:
{ "15:example.com/xxh" sid=7 max=13 lib="3:SSL" }
Note that MIME does not document named values (AFAIK), but many
MIME-based protocols, including HTTP use them. For example,
Cache-Control: max-age=100
We can still keep our parser very simple, even if we add support for
optional value names. We would need to restrict atomic (integral)
values to start with a sign, digit, or a quote. This means that all
token values will have to be quoted, but that may actually be a good
thing:
parameter1: max-age=100 // named
parameter2: {"19:http://example.org/" 1234 } // anonymous
I hope the above does not cause any strong objections because it is a
simple and useful feature, but I may be missing something important.
Please comment.
Thanks,
Alex.
P.S. If you accept the above, you may want to start thinking
whether we should make named parameters identical to named
values, to further simplify OCP grammar.