Include version in URI

[usnistgov]

Include version in URI

[atvassilev]

It is an interesting question. Looking at the ACVP spec, the protocol version is advertised explicitly in the registration step. Furthermore, each protocol message has a version attribute. It seems to me that once the server accepts the registration and assigns a session, implicitly all the exchanges in that session will be following that version of the protocol. A single URI would still work to support multiple ACVP versions, perhaps with a slightly different server architecture. I am thinking of a public-facing proxy that first detects the desired protocol version and forwards it to a corresponding back-end server, implicitly for the client. NIST could then deploy several back-end servers, each servicing a particular version of the protocol. In turn, each such server may rely on other supporting servers/resources that may or may not be protocol-dependent.

Bottom line: I don't see much of an advantage to add the version to the URI.

[jfigus]

The advantage would be flexibility in deployment. For instance, there could be two servers running. One for version 1.0 of the spec, and another for version 2.0. If the URI were different, it's easy to configure a proxy to send the requests to the appropriate server.

On the other hand, if all requests for v1.0 and v2.0 have to be handled by the same server, then the version branching logic based needs to be contained in a single server. When the version isn't in the URI, a proxy wouldn't be able to direct the request to a different server based on the version. This not only limits deployment options, it complicates to the server code.

There is a precedent for this approach. Please see section 2.1 in
https://tools.ietf.org/html/draft-lear-mud-framework-00

[atvassilev]

I see your point about the complexity of the proxy. Certainly, in the case of a single server detecting the protocol version that server would have to look into the messages to decide how to branch the traffic, which may be involved, like decrypting TLS traffic. I don't necessarily view this as a disadvantage though as it seems to allow for a stricter server-side checking of client input.

In this model, when a client v2.0 packet comes, it will get directed to a v2.0 server for processing. In your model a client may decide to send a v2.0 message to a v1.0 server either by mistake or a malice. The proxy will direct the packet directly to the server of client's choice by virtue of the URI. This may be tricky.

[atvassilev]

Closing this issue as we have settled on the approach to not include the version in the URI.