Subject: Re: Profiles in Service Change

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 6 Sep 2000 10:10:45 -0400

What is wrong is that it promotes proliferation of
many overlapping profiles.  Profiles are supposed to be
a way of reducing the variability that Packages provide,
so that one could reasonably expect to be able to find
interoperable MGs and MGCs.

No one can legislate this (no protocol police...), but
we can encourage, or discourage proliferation of
many profiles that attempt to solve the same problem
different ways.  If you support 100 profiles, you may
as well just ignore the profile info and look at the
audited package list!

I want to make it HARD to have more than one profile
per MG (not MGC).  Not impossible, just hard.  I think
that will encourage coalescing around a small number of
profiles for specific purposes that all relevant MGs and
MGCs support, which in turn will make the protocol successful.

What I fear is balkanization by proliferation of profiles,
which leads to non-interoperable devices.  It would be non
interoperable because there were no common profiles, rather
that if you found a common one, it wouldn't work.  The
package mechanism is a wonderful way to have all sorts of
extensions and features in MGs.  The profile mechanism was
designed to provide a way to corral the easy expansion into
more limited groups of options.  Generally, successful
protocols are not easy "bent" in many different ways -> you
get ONE way, and everyone does it that way, and the world
is better for it.  The package thing is great, but it is
a danger.  The profile is the only way I know to limit it's
potential to undermine the effectiveness of the protocol.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 10:01 AM
> To: Michael P DiGioia
> Cc: [email-masked]; Christian Groves;
> Rosen, Brian
> Subject: Re: Profiles in Service Change
>
>
>
>
> Michael P DiGioia wrote:
>
> > Brian,
> >
> > > > So does that mean that nobody can make an MG which
> supports more than
> > > > one profile? :-)
> >
> > >One way to get around the limitation is to try to get
> > >service using the most "featurefull" profile.  If you fail
> > >to find an MGC that can serve that profile, try again with
> > >a different profile.
> >
> > I agree. I believe the point is that any one MG can support
> one or more
> > profile, however, once the most featurefull profile is
> found to be accepted
> > by an MGC, use it.
>
> I disagree as Brian's comments assumes a meaningful ordering
> relation between
> (at least a resonable subset of) profiles based on some set
> of features
> supported. I don't see that. Christian's proposal of allowing
> a listing of
> profiles seemed pretty good to me - what was wrong with this again ?
>
> -- Flemming
>
> >
> >
> > What we build into our IpPhone MG is our choice. I don't
> believe this limits
> > us in any way. If so, how?
> >
> > /mpd
>
> --
> Flemming Andreasen
> Cisco Systems
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 6 Sep 2000 10:28:19 -0400

OK - I'll buy that.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: John Segers <[email-masked]>
Date: Wed, 6 Sep 2000 16:47:38 +0200

I agree to the underlying idea that profiles could be used to restrict
fragmentation.  On the other hand, I think that Christian has a point.
His example may have been unfortunate because it mentioned a call
signaling protocol, but the point is valid.

Suppose that I want to build a MG that supports the IPphone profile, and
I also build in IP fax support.  If my MG signals that it supports the
IPphone profile, the MGC infers that this MG supports a certain set of
packages and maybe some things that are optional in the base megaco
protocol.  It doesn't have a reason to audit the MG and find out that it
can also do IP fax.  So how do I get the MGC to use the fax support
(other than by provisioning the MGC with this information)?

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 303
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Christian Groves <[email-masked]>
Date: Thu, 7 Sep 2000 10:59:24 +1100

G'Day Brian,

I completely agree that we want to make it HARD to have a multiplicity
of overlapping profiles.  But with the current text I see that we make
it impossible, its got one profile and only talks about a profile. That
is why I'd like to see : a technical change in the implementor's guide
or an implementation or "something" to say at least say how you cope
with the case where: the MG supports multiple profiles and/or the MGC
needs to access 2 profiles to complete a service. Its a real world issue
that we have to deal with as soon as we have 2 profiles defined.

Cheers, Christian