Subject: Re: Message Header w/Version

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

I think we've already agreed that profiles in particular should be signalled
at the beginning of the association (i.e with serviceChange), because they
are more in the way of a restriction on the sender of a message than
something a parser has to know about at the receiving end.  Our syntax
allows the signalling of extensions on a per-field basis, and they could
also be negotiated at start-up time.  Do we need more than that?  I assume
you're making the point that signalling of extensions should be treated the
same as the signalling of versions.

> -----Original Message-----
> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Wednesday, August 18, 1999 10:33 AM
> To:   Taylor, Tom-PT [CAR:B901-I:EXCH];
> [email-masked]
> Subject:      RE: Message Header w/Version
>
> What about profiles?  I believe they are required.
>
> Do vendors get to signal extension capability?
>
> You can't have your cake and eat it too.  I don't think you can get "short
> messages" and "easy parsing to determine what to expect" at the same time.
>
> One advantage of the serviceChange method is that it can be
> arbitrarily long (and informative).
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Wednesday, August 18, 1999 9:56 AM
> > To: [email-masked]
> > Subject: Re: Message Header w/Version
> >
> >
> > 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: Michael Thomas <[email-masked]>
Date: Wed, 18 Aug 1999 18:14:38 -0700

> same as the signalling of versions.

   This does sort of bring up an interesting
question though: when we add packages, how do they
get versioned? Are the locked to the main version
and cannot change between? Or will there just be
profiles where the protocol name changes?  Or will
they be independently versioned? If so, is it with
audit that the MGC can find out the rev level of
the packages? Should the packages be versioned
differently from the main protocol perhaps with
the restriction that within a major version they
be 100% backward compatible?
   I would assume that packages, almost by
definition, are the most likely thing to change
with MEGACO. It is, after all, where most of the
work happens. At a base, answers to these
questions would probably be an excellent thing to
go into the package definition annex that Mike
Kallas has been working on.

                Mike

---

From: Rex Coldren <[email-masked]>
Date: Wed, 18 Aug 1999 18:53:20 -0700

Mike,
   Good concern.  I think that a package registration must include a
specification of the base protocol revision that it maps to.  Subsequent
protocol revisions would automatically support that package registration
(assuming that we extend the protocol properly, that is).  You wind up
with the following example:
   Package X maps to protocol version 1.0.  By convention Package X
      would then map to any subsequent protocol version to 1.0.
   Package Y maps to protocol version 2.15.  By convention, Package
      Y would then map to any subsequent protocol version to 2.15.  If
      it were compatible with previous versions it would be registered as
      such.

   As long as we properly extend the base protocol and do not register
packages that do things not intended (whatever that is) by the base
protocol, we should be fine.

Rex

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Aug 1999 19:20:44 -0700

> protocol, we should be fine.

   That's one direction and I don't have any
problems with it, but what I'm concerned about are
packages that are rev'ed intra H.248 version. Say,
for example, that the line package needed to add a
new signal, AnnoyingTone. The H.248 version is
1.0, but the package needs to be rev'd to reflect
the change, and the whole thing needs to be
knowable to the MGC so that it can know that it
can take advantage of AnnoyingTone on the
MG. Also: if MGC doesn't care about AnnoyingTone,
it should affect interoperability.
   I'm not sure that the best thing would be to
rev the whole protocol, but I suppose that would
be one way to do it so long as there are rules
which say that "if the MG's version is less than
the MGC version, MG can still interoperate unless
condition xyz is true", where "condition" could be
"always".

                Mike