Subject: Audit of packages

From: Sachin Mittal <[email-masked]>
Date: Mon, 9 Oct 2000 14:42:00 +0530

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: "Rosen, Brian" <[email-masked]>
Date: Mon, 9 Oct 2000 16:02:53 -0400

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

Sachin

---

From: Dave Sclarsky <[email-masked]>
Date: Thu, 12 Oct 2000 10:14:17 -0400

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
> 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
>
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Monday, October 09, 2000 16:03
> Subject: Re: Audit of packages
>

---

From: Sachin Mittal <[email-masked]>
Date: Thu, 12 Oct 2000 21:25:18 +0530

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)

DaveS.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Oct 2000 16:02:21 -0400

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

> Sent: Thursday, October 12, 2000 11:55 AM

---

From: Chanchal Hassija <[email-masked]>
Date: Fri, 13 Oct 2000 09:58:42 +0530

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)

Brian

---

From: Peter Blatherwick <[email-masked]>
Date: Fri, 13 Oct 2000 15:15:14 -0500

I believe in SHOULD for this, at most.  Reason is to not require publishing
of packages which are not intended to be directly controlled.  Some examples
exist now (for example tonedet and tonegen, a few in Annex G).  I can
certainly see others defined in the future, some of which could actually be
functional but still intended to be used as base package only, and might be
nonsensical on their own.  Can't think of any good examples right now, but
we should allow for it.  The effect of having no rule at all is some MGs
would not publish base Packages and could suffer some non-backward
compatibility problems with some MGCs that only know about the base Packages
-- that's the MG implementer's decision really.

Possible starter text:
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.  (Steal some of Brian's words about valid
addressing of A or B, depending on what's published.)

-- Peter

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, October 11, 2000 22:25
To: Blatherwick, Peter [CAR:AT14:EXCH]
Cc: [email-masked]; 'Rosen, Brian'
Subject: Re: Audit of packages

Cheers, Christian

---

From: Peter Blatherwick <[email-masked]>
Date: Fri, 13 Oct 2000 15:01:34 -0500

Below is correct.  The reason to publish both A and B in this example is to
allow an MGC that only understands the base package (A) to be able to make
use of its capabilities.

In the previous example, further below, publishing dtmf tone detect (dd) but
not basic tone detect (tonedet) is also valid, but the description of the
result is not.  In this case, an MG publishing dd is required to support
*all* aspects of the base tonedet package from which dd is derived,
including start tone detected and end tone detected.  If it does not, it is
either a different package or incorrectly implemented.  In this case, it
does not make sense to publish support of tonedet since it has no
functionality on its own, just defines interface, and is intended
specifically as a base package from which other functional ones are derived
(even says so in the description).

-- Peter

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, October 12, 2000 16:02
To: [email-masked]
Subject: Re: Audit of packages

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Oct 2000 13:34:24 -0400

I agree with your interpretation: our intent was that if you support an
extension, you also support the complete base package.

> From: Chanchal Hassija [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 12:29 AM

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 23 Oct 2000 13:50:13 -0400

Yes, but you support the base parameters, events, signals and
statistics on the "new" package name (B/e1).  Support of the
base package is optional (A/e1).  Words to that effect would be a
good idea.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 1:34 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Oct 2000 12:43:25 -0500

I have a disagreement with the portion of text indicated below and suggest
that it be dropped.  The ambiguity is about names, not about implementation:
the standard leaves no ambiguity about the requirement to support all of the
base package.

> Sent: Monday, October 16, 2000 2:14 AM
> 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]>
> 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.

[PTT] <begin text proposed to be omitted>
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,
[PTT] <end text proposed to be omitted>

> 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
>
> "Rosen, Brian" wrote:
> >
> > 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
> >
> > > From: [email-masked] [mailto:[email-masked]]
> > > To: Rosen, Brian
> > > Cc: [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 23 Oct 2000 15:17:06 -0400

We all agree about the requirement to support the properties, events,
signals and
statistics of the base package under the package name of the new package.

What is unclear is what an implementation should do about the base package.
Should it support the base package names also?
The proposed text recommends that it SHOULD.  Is that a problem?
I think guidance is warranted.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, October 23, 2000 1:43 PM
To: [email-masked]
Subject: Re: Audit of packages

> From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ]

> > > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > From: Sachin Mittal [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > > > > From: Sachin Mittal [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Oct 2000 14:47:09 -0500

Do we agree on this logic, which was behind my intervention?
  (1) An MG publishes the packages it is prepared to understand in incoming
messages.
  (2) An MG does not publish packages which it is not prepared to understand
in incoming messages.

This is why I felt that the middle part of Christian's text was unnecessary
-- the final two sentences already capture the intent.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 23, 2000 3:17 PM
To: [email-masked]
Subject: Re: Audit of packages

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 23 Oct 2000 16:07:22 -0400

The problem is that an implementer reading the text does not know if he
should,
or should not, implement the base package under the base package name.
Whichever decision he makes, the text is clear on what he should do.
The question is should the implementer's guide offer advice on whether the
base package should be implemented.

Christian suggested that it should, further suggested that the advice should
be
that the implementer SHOULD (not SHALL) implement the base package, and
I agreed with him.  I actually had suggested MAY, which I'm still okay with.
It seems wrong to make it MUST or SHALL NOT.  Whichever way we agree on,
I want the text to say something on whether the base package should be
implemented.

Brian

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 23, 2000 3:17 PM
To: [email-masked]
Subject: Re: Audit of packages

Brian

---

From: Peter Blatherwick <[email-masked]>
Date: Mon, 23 Oct 2000 20:31:09 -0500

At risk of further continuing a thread that has already gone on for some
time...

I agree we should say something, and that Christian's proposed text gives
good advice and does no harm.  (If its also redundant, that's not really a
problem, as long as the advice is good.)

Tom's point 2) below leads me to think maybe the support of base packages
would be better as a "MAY", as this would allow some Packages to be
deprecated over time, and would also allow a vendor to take a really tight
focus if they saw fit and not be breaking any rules or advice implied.
Having pointed out what MAY be done, and specifically how, vendors would get
it right, and I expect almost all would publish base packages as described
as an aid to backward compatibility.

On a closer read I also notice the word "implement" (in quotes) used, where
it is actually not quite correct.  In reality, extended Packages MUST
implement their base -- that's how it works.  However it is optional to
publish this for use.

How about:
"
When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either 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. By definition, the MG MUST also implement the base Package, but
it optional to publish the base package as an allowed interface.  If it does
publish A, 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 publish A, then only B/e1 would be available.  If published through
AuditValue, A/e1 and B/e1 are the same event.

For the purpose of improved interoperability and backward compatibility, the
an MG MAY 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, in which case the MG SHOULD NOT publish the
base Packages.
"

-- Peter

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 23, 2000 16:07
To: [email-masked]
Subject: Re: Audit of packages

Brian

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 23, 2000 3:17 PM
To: [email-masked]
Subject: Re: Audit of packages

Brian

---

From: Peter Blatherwick <[email-masked]>
Date: Tue, 24 Oct 2000 10:08:03 -0400

Oops, a few minor glitches in proposed text I sent last night, repaired
below.  (Stupid fingers!)  Also missed that the description does not
specifically talk about signals, properties or statistics.  Below is still
longer than before, but is more specific and complete.

Try again:
"
When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended
package name or the base package name.  By definition, an MG implementing an
extended package MUST also implement all aspects of the base package, but it
is optional to publish the base package as an allowed interface.  For
example, if Package A defines event e1, and Package B extends Package A and
defines event e2, then B/e1 and B/e2 are events for a termination
implementing Package B.  If the MG does publish Package A, then Package A
would be reported in the PackageDescriptor returned by AuditValue as well as
Package B, and events A/e1, B/e1 and B/e2 would be available on the
termination.  If the MG does not publish A, then only B/e1 and B/e2 would be
available.  If published through AuditValue, A/e1 and B/e1 are the same
event. The same logic also applies to signals, properties and statistics.

For the purpose of improved interoperability and backward compatibility, an
MG MAY 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, in which case an MG SHOULD NOT publish the
base packages.
"

Enough fussing,
-- Peter

-----Original Message-----
From: Blatherwick, Peter [CAR:AT14:EXCH]
Sent: Monday, October 23, 2000 21:31
To: [email-masked]
Subject: Re: Audit of packages

On a closer read I also notice the word "implement" (in quotes) used, where
it is actually not quite correct.  In reality, extended Packages MUST
implement their base -- that's how it works.  However it is optional to
publish this for use.
How about:
"
When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended
package name or the base 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.   By definition, the MG MUST also
implement the base Package, but it  is optional to publish the base package
as an allowed interface.  If  the MG does publish A, then A would be
reported on the Package Descriptor in AuditValue as well as B, and  both
event A/e1 and B/e1 would be available on a termination.  If the MG does not
publish A, then only B/e1 would be available.  If published through
AuditValue, A/e1 and B/e1 are the same event.

-- Peter
-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 23, 2000 16:07
To: [email-masked]
Subject: Re: Audit of packages

Brian

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 23, 2000 3:17 PM
To: [email-masked]
Subject: Re: Audit of packages

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 24 Oct 2000 13:33:38 -0400

I'm happy with this.

-----Original Message-----
From: Blatherwick, Peter [CAR:AT14:EXCH]
Sent: Tuesday, October 24, 2000 10:08 AM
To: [email-masked]
Subject: Re: Audit of packages

Try again:
"

"

Enough fussing,
-- Peter

-----Original Message-----
From: Blatherwick, Peter [CAR:AT14:EXCH]
Sent: Monday, October 23, 2000 21:31
To: [email-masked]
Subject: Re: Audit of packages

How about:
"

"

-- Peter
-----Original Message-----

Brian
-----Original Message-----
From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, October 23, 2000 3:47 PM
To: Rosen, Brian; [email-masked]
Subject: RE: Audit of packages

-----Original Message-----

Brian
-----Original Message-----
From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, October 23, 2000 1:43 PM
To: [email-masked]
Subject: Re: Audit of packages