I think this matches your proposal. However, I am worried that if we
write examples with full names, implementors will start sending them
on the wire. And if we avoid full names in examples, does it make
sense to document full names at all? What do you think?
Perhaps we need a better term for "full name" and "abbreviated name"
to emphasize that only the latter can appear on the wire? "Command
name" and "command code"?
How about just calling the command with its full name and then only refering to
the abbreviation as the code in the technical description.
7.1 The connection-start command
command code: CS
anonymous parameters: none
Also, the named-parameter syntax allows only for one value. Do you
think we should change that to
anonym-parameters = values
named-parameter = CRLF name ":" values
values = 1*(SP value)
to better match MIME capabilities? Or is one value per name enough?
Preparing for value lists is a good idea.
But what about using a different list separator character? Comma?
That could also allow to introduce lists as values for anonym-parameters if
we'll ever need them.
If services is an optional xaction-start parameter, why not also
make it an optional parameter of connection-start? If OPES processor
wants to use the default service for a connection feature, it could
set it already with the connection-start message rather than sending
an extra connection-services message. Same for connection-priority?
I agree that the current specs are inconsistent. I am not sure what
the right fix is though. We can limit support to a dedicated message
for each state change (e.g., connection-priority) or we can have both
dedicated messages and message parameters (e.g., priority parameter in
a connection-start message). Note that dedicated messages are required
because sometimes you want to change the state in the middle of a
"process" (e.g., change priority or default services of an existing
Can you give me an example where changing of priority or default service is