 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi Sebastien,
I think that incrementing the version number in the header does not mean we have to redesign and improve the whole protocol. It does not mean a "major update". It is simply a hint for implementations indicating what behavior is expected (state machine, ...)
I guess it's really a question of what the version number in the header indicates. So far, its the opinion of most folks that the version number means ONLY "major update and/or new significant features" and bis is merely an update/patch to an existing version.
* The version number in the diamter header may not help the TLS negotiation anyway because we only see the version number after the first diameter message. So a bis implementation and an original 3588 may not be able to inter operate regardless of whether the version number is reved-up.This is true for some situations, but there are also cases where a different version number would be very useful for an implementation that tries to be compatible with both specifications.
Typically yes. But 1) we should confine ourselves to the changes in bis because those are the only changes that exist/relevant. 2) If bis is treated as fix/patch to problems that renders certain features in 3588 as non-interoperable then why would an implementation need to support both version ?
regards, victor
On a technical point of view, changing the version number in the code is a trivial change, especially compared with all the other changes that are in the "bis" document. I don't see a reason why an implementor would complain about having to do this change on the version number -- if they are willing to deploy the changes from this revision, at least. On the contrary, on a marketing point of view, "We support Diameter 2" is more attractive IMO :) In any case, we will have to distinguish between the original Diameter or the revised version. Talking about "version 1" and "version 2" is more convenient and less error-prone. In my opinion, not incrementing the version number will add even more complexity to the protocol and implementations, leading to even less people understanding it and wanting to use it... Thank you for reading. Sebastien.