Subject: Re: Message Header w/Version

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 18 Aug 1999 09:55:42 -0400

I've seen Christian Grove's later message on this point, but I think based
primarily on David Oran's arguments I will make a call on this one.  We
should have a version number in each message.  However, I see no particular
need to have minor version and double digits for both major and minor, as
Abdallah illustrates below, so we can cut the overhead down to one digit
plus the separator character.

> -----Original Message-----
> From: Rayhan, Abdallah [CAR:5N00:EXCH]
> Sent: Tuesday, August 17, 1999 1:04 PM
> To:   [email-masked]
> Subject:      Re: Message Header w/Version
>
> Question: What are the pros and cons of Version ?
>
> pros:
> 1- Ability to change syntax and semantics of new versions of MEGACO
> with the possibility of maintaining backward compatibility.
> 2- Less semantic/syntax constraints on how to process  messages.
> 3- Ability to differentiate between unsupported versions and
> syntax/semantic
> errors
>
> cons:
> 1- Few extra bytes( MEGACO/xx.xx)
>
> It is obvious that pros of having Version in every message outweighs
> the cons.
>
> regards
> Abdallah Rayhan
>
>
> David Oran wrote:
>
> > A perhaps silly question:
> >
> > If the version number is only in the service change message, then if the
> MG
> > and MGC ever get mis-synchronized (perhaps due to an earlier parsing or
> > protocol error), how does a parser reasonably figure out when it gets
> > confused by a message whether its confusion is due to a version mismatch
> or
> > something else. It strikes me that there's at least the potential for
> better
> > debugging and error reporting if every message is entirely
> self-describing.
> >
> > Some (possibly debatable) philosophy:
> >
> > Some things about a protocol need to be "held fixed" across evolutionary
> > changes or you lose backward compatibility. Putting the version number
> in
> > every message effectively "fixes" the format of the protocol up to the
> > version-number field for all time. Conversely, depending on the version
> > number in the service-change message fixes some aspects of the protocol
> > state machine for all time (i.e. must see a service change message
> before
> > you can interpret any other message). Which of these two things do we
> feel
> > more comfortable keeping constant for the life of the protocol? I have
> my
> > personal preference; maybe you can guess?
> >
> > Dave.

---

From: Abdallah Rayhan <[email-masked]>
Date: Wed, 18 Aug 1999 15:32:14 -0400

We could borrow the Version specs from RFC2145 which
explains version ordering, compliance requirements, and
upgrading of version numbers for HTTP.  SIP borrows
the same specs from HTTP.

RFC2145 explains the differences between minor and major
releases of the protocol and how that affects Version. Also,
Version does not have leading zeros. So 01.10 should be written
as 1.1, two digits would be the max allowed width per each.
In addition to that it specifics the order of releases.

regards
Abdallah