Subject: Re: package versioning

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 19 Aug 1999 09:29:45 -0400

I spent time with the people working on line-side package specifications
this week.  Their approach seems fairly general, to the point where once the
packages are defined, it may not be necessary to update them.  In
particular, there's a proposal for a general way to deal with tones so we
won't have to be constantly adding new ones to the standard.

> -----Original Message-----
> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Wednesday, August 18, 1999 10:21 PM
> To:   [email-masked]
> Subject:      Re: package versioning
>
> Rex Coldren writes:
>  > 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.
>
>    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
>  >
>  > Rex
>  >
>  > Michael Thomas wrote:
>  >
>  > > Tom-PT Taylor writes:
>  > >  > 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.
>  > >
>  > >    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
>  >