Subject: Re: package versioning

From: Brian Rosen <[email-masked]>
Date: Thu, 19 Aug 1999 09:55:53 -0400

I can't tell from the messages whether anyone thinks that
that versioning the protocol to take into account packages
is intended.  Packages are not tied to the protocol version.

When you audit a termination and you get back a list of the
packages implemented on it.  It is actually there now,
in that you get all the parameter values, and they have the
package name in them.

For extra credit, the packages could have a version, and you
could get back that in a specialized audit info item.

To do this, we add a new descriptor packagesDescriptor
packagesDescriptor = PackageToken EQUAL version LBRKT
        packageItem *(COMMA packageItem)
packageItem = NAME COLON version

We would also add an item to the requestInfo descriptor.
I'm not entirely convinced that such a step is necessary.

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 9:15 PM
> To: [email-masked]
> Subject: package versioning
>
>
> 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
>

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 Aug 1999 11:58:03 -0700

> I'm not entirely convinced that such a step is necessary.

   This seems like a good idea to me. Unlike Tom's
optimism on getting packages correct the first
time, I somewhat skeptical that:

  1) we'll get it right the first time
  2) new features won't be the rule rather than
     the exception

   Versioning of packages is just a way to prevent
name space pollution. One important corollary is
that an MG MUST support ALL of the signals and
events of a package (with the implication that
there will be packages with overlapping
functionality).

                Mike