Subject: Re: Audit of packages

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Oct 2000 07:58:12 -0400

We probably need some words in the Implementer's Guide, I agree.

How about something like:
When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using the extended package
name.  For example, if Package A defines event e1, and Package B extends
Package A, then B/e1 is an event for a termination implementing Package B.
The MG MAY also "implement" the base Package.  If it does, then A would
be reported on the Package Descriptor in AuditValue as well as B, and
event A/e1 would be available on a termination.  If the MG does not
implement A, then only B/e1 would be available.  Of course, if implemented,
A/e1 and B/e1 are the same event.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 12:29 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Audit of packages
>
>
>
>
> Hello Brian,
>
> If this is the case as you are pointing out, then it should
> be clearly mentioned
> in the protocol. Because the protocol says only the following
> --- in context of
> Package B extending Package A --
>
> Sec 12.1.1 - " When a package
>      extends another package it shall only add additional Properties,
>      Events, Signals, Statistics and new possible values for an
>      existing parameter described in the original package. An extended
>      package shall not redefine or overload a name defined in the
>      original package."
>
> This seems to imply that Package B has to support all the
> events supported on
> Package A......
>
> What is your opinion on this....
> Chanchal....
>
>
>
>
>
> "Rosen, Brian" <[email-masked]> on 10/13/2000 01:32:21 AM
>
> Please respond to "Rosen, Brian" <[email-masked]>
>
> To:   [email-masked]
> cc:    (bcc: Chanchal Hassija/HSS)
>
> Subject:  Re: Audit of packages
>
>
>
>
> I don't think there is any change to the base understanding.
>
> Suppose Package A defines Event e1
> Suppose Package B extends Package A.
>
> Now, you can talk about A/e1 or B/e1.
>
> If you "expose" package A, then you would include A in the
> list of packages reported on an audit, and A/e1 as well as B/e1
> would be legal.
>
> If you don't expose package A, then you can only use B/e1.
>
> In both cases the extended package inherits the behavior of the
> base package.
>
> Brian
>
> > -----Original Message-----
> > From: Sachin Mittal [mailto:[email-masked]]
> > Sent: Thursday, October 12, 2000 11:55 AM
> > To: [email-masked]
> > Subject: Re: Audit of packages
> >
> >
> > The idea of supporting extending package but not supporting
> > base package
> > is not the basic philosophy of extension of packages which says that
> > extended package inherits the behaviour of base package.
> >
> > So do we need to change the basic understanding of package
> extensions.
> >
> >
> >
> >
> >
> >
> > Dave Sclarsky <[email-masked]> on 10/12/2000 07:44:17 PM
> >
> > Please respond to Dave Sclarsky <[email-masked]>
> >
> > To:   [email-masked]
> > cc:    (bcc: Sachin Mittal/HSS)
> >
> > Subject:  Re: Audit of packages
> >
> >
> >
> >
> > What do you think about the case where an MG can support pkg2
> > but NOT pkg3?
> >
> > Take the case of the Tone Detection Package and the DTMF
> > Detection Package
> > that extends it.  There are most certainly 'intelligent'
> > devices that are
> > capable of reporting DTMF digits, but do not offer the
> > granularity to report
> > 'Start tone' or 'End tone' detected.
> >
> > I would have assumed that an MG with such a device would
> > (should!) publish
> > dd but not tonedet, because it really cannot notify tonedet/std or
> > tonedet/etd.
> >
> > DaveS.
> >
> >
> > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Wednesday, October 11, 2000 10:25 PM
> > > To: [email-masked]
> > > Subject: Re: Audit of packages
> > >
> > >
> > > Perhaps we "should" say "SHALL", I can't think of a case of
> > when it is
> > > inappropriate and we have the rule saying that you can address
> > > properties by pkg3.
> > >
> > > But, I'm happy with Should if you can provide the text when it is
> > > inappropriate.
> > >
> > > Cheers, Christian
> > >
> > > Peter Blatherwick wrote:
> > --------------------------
> > >
> > > I agree in general, since "extends" basically means
> "clone the base
> > > package and add some more functionality" (no subsetting,
> over-riding
> > > etc allowed).  In example below pkg2 by definition
> implements pkg3.
> > > (Not the case with re-versioning of Packages though!)
> > >
> > > One clarification however.  It does not always make sense
> for a base
> > > package to be published as implemented by an MG.  There
> are examples
> > > where the base package is defined such that it acts similar to a
> > > virtual class, and has no function on its own, simply defining
> > > interface for one or more derived packages.  Annex E ToneGen and
> > > ToneDet as well as a few packages in Annex G are examples.
> > Therefore,
> > > implementer's guide MUST not make a hard and fast rule on
> this, but
> > > SHOULD say "SHOULD" with some words to describe where its
> > > inappropriate.
> > >
> > > -- Peter
> > >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Monday, October 09, 2000 16:03
> > > To: [email-masked]
> > > Subject: Re: Audit of packages
> > >
> > > We've been around this and basically, it is up to the MG.
> > > It does not HAVE to report pkg3, but it could.  Maybe SHOULD
> > > is a good word, and I wonder if text to that effect
> > > should go in the implementor's guide?
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Sachin Mittal [mailto:[email-masked]]
> > > Sent: Monday, October 09, 2000 5:12 AM
> > > To: [email-masked]
> > > Subject: Audit of packages
> > >
> > > Say a termination abc implements the following packages:
> > > 1. pkg1
> > > 2. pkg2
> > > where pkg2 extends pkg3 and pkg1 doesn't extend any other package
> > >
> > > If this termination is audited for packages implemented on it,
> > > should the reply include pkg3 with pkg1 and pkg2 (base
> package names
> > > are included)
> > >
> > > Sachin
> >
>
>
>
>
>
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 16 Oct 2000 17:14:10 +1100

G'Day all,

Below is the text which I propose to put into the implementor's guide.
Its a mix of Brian and Pete's proposed words. I note that I changed
Brian's MAY to Pete's SHOULD.

9.5     Package Extension and Referencing

Description:    The current text in H.248 Section 12.1 is ambiguous about
the usage of package names when referencing properties, events, signals
and statistics in a base package and an extended package.
Reference:      Subject: Re: Audit of packages
Date: Fri, 13 Oct 2000 07:58:12 -0400
From: "Rosen, Brian" <[email-masked]>
To: [email-masked]

Subject: RE: Audit of packages
Date: Fri, 13 Oct 2000 15:15:14 -0500
From: "Peter Blatherwick" <[email-masked]>
To: "'Christian Groves'" <[email-masked]>
CC: [email-masked], "'Rosen, Brian'"
<[email-masked]>

[Begin Clarification]
Section 12.1
When packages are extended, the properties, events, signals and
statistics defined in the base package can be referred to using the
extended package name.  For example, if Package A defines event e1, and
Package B extends Package A, then B/e1 is an event for a termination
implementing Package B. The MG SHOULD also "implement" the base
Package.  If it does, then A would be reported on the Package Descriptor
in AuditValue as well as B, and event A/e1 would be available on a
termination.  If the MG does not implement A, then only B/e1 would be
available.  If implemented, A/e1 and B/e1 are the same event.
An MG SHOULD publish all Packages supported by its Terminations,
including base Packages from which extended Packages are derived.  An
exception to this is in cases where the base Packages are expressly
designed to be extended by others, not directly controlled, and may not
have any function on their own or be nonsensical on their own.
[End Clarification]

Any problems with the text?

Cheers, Christian