Re: comments on pvAccess spec

[Michael D. <mda...@bn...>]

So I read through

http://epics-pvdata.sourceforge.net/pvAccess_Protocol_Specification.html

Below are some specific comments.  Two (related) topics which I would
like to see addressed are forward compatibility, and how protocol
violations are handled.

Please don't feel the need to respond to this all at once.

Comments by section
===================

= Status of this Document

For a spec. the words 'must' and 'required' don't appear very often ;)

= Connection Establishment

> The connection remains active as long as there is at least one channel
active.

Initially there are no channels active.  How should this be handled?

= Flow Control

I'm still thinking about this section and how messages larger then the
Rx buffer size would be transmitted.  An example would really help.

My big question here is to what extent this should be enforced?  If a
peer sends too much too fast how should an implementation respond?  Can
it ignore the message, drop the connection, or does it have to handle it?

Specifying this will make it clearer how simple (or complex) an
implementation has to be.

= Channel Discovery

> In principle pvAccess uses the same channel disocvery mechanism
> as Channel Access

This needs to be expanded on.

Some description of the qosCode is required.  When "response required"
should not be honoured for example.


Scope of identifiers
====================

pvA is a stateful protocol with identifiers which must be remembered by
both parties.

Each identifier should have a defined scope in which is used and rules
for creating it.

= pvData Type ID

In what scope is this ID unique (global, per connection, per channel, or
per request)?

This is the only 16-bit identifier.  When can an ID be reused?  Can they
be exhausted?  (after many channelRPC responses?)

= searchSequenceId

Appears in search request and response.

Can two clients use the same ID?  Can the same client have two
outstanding requests with the same ID?  If not, when can an ID be reused?

= clientChannelID

Appears in search request, response, and channel create.

Does the server really use this in channel create?  If so, how long must
a server remember all the IDs which where sent back to each client?

= serverChannelID

Can the same server ID be given to several clients?

= requestID (get, put, ...)

Can a client use the same ID concurrently for different types of requests?