[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: OCP Core version head_sid6 available



> [...]
> 
> 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.
Example

    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
> connection).

Can you give me an example where changing of priority or default service is required?


Thanks
Martin