Subject: Re: physical and ephemeral terminations

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Nov 2000 09:10:42 -0500

I have always been in favor of this approach.  I agree that implementing
it by process of elimination of termination characteristics is very hard.

Brian

> -----Original Message-----
> From: Nurit Shenhar [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 3:21 AM
> To: [email-masked]
> Subject: Re: physical and ephemeral terminations
>
>
> Tom and List
>
> The subject keeps coming again and again, and I fill that it
> because there
> is really a problem implemeting the current definition. The
> problem is, that
> choosing a termination according to the command parameters,
> means that you
> have to analyse all the parameters in order to decide upon
> the type. But the
> structure of the protocol being as it is, it is more natural
> to first pick
> up an existing termination, or create a new one, and then continue and
> assign it with the command parameters. As the MGC knows
> exectly which kind
> of termination it wants, why shouldn't he say so?
>
> one way to do it, is something that I found in John Segers answer from
> 14/11/2000  (RE: Use of CHOOSE):
>
> >Normally I would expect naming hierarchies where the first
> level in the
> >hierarchy identifies the class of the termination.  And I
> would expect
> >that MGCs use Add commands with partially specified names, e.g.
> >Add=TDMC/$, or Add=RTP/$.
>
> Can't we adopt it as a rull?
>
> Thenks
>
> Nurit
>
> -----Original Message-----
> From: Taylor, Tom-PT [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 9:01 PM
> To: [email-masked]
> Subject: Re: physical and ephemeral terminations
>
>
> [Old issue, apparently not closed.]
> Two cases:
> (1) The initial ADD does not specify enough properties to remove the
> ambiguity.  In this case, the termination chosen is a shell, ready to
> receive further information.  I do see a theoretical
> possibility that a
> termination is chosen according to one naming scheme, but has
> properties
> applied to it in a subsequent MODIFY which make that naming scheme
> inappropriate.  I suppose the MG could reject the ADD request
> on grounds of
> ambiguity, or else reject the MODIFY because of the
> contradiction.  In the
> latter case, the MGC would have to subtract the invalid
> termination and add
> another, this time with enough properties specified that an
> appropriate name
> is chosen.
>
> (2) The initial ADD specifies enough properties that the
> right termination
> can be assigned.  I would judge this to be the preferable way of doing
> things.
>
> > -----Original Message-----
> > From: Nitin Jain [mailto:[email-masked]]
> > Sent: Thursday, October 19, 2000 1:25 PM
> > To: [email-masked]
> > Subject: Re: physical and ephemeral terminations
> >
> >
> > Hi all,
> >
> > Sorry I am late into this discussion. From the archives, I could not
> > find out what the consensus was for creating an ephemeral
> termination
> > or selecting a physical termination for CHOOSE in an ADD command.
> >
> > If the physical termination can have the localDescriptor properties,
> > how do we distinguish between a CHOOSE for ephemeral termination or
> > Physical termination when "TermID=$" in an ADD command.
> >
> > Thanks.
> > Nitin
> >
> >
> > -----Orig. Message-------
> >
> > Any termination can have properties, defined by the packages
> > implemented on
> > it.
> > Look at the IPPhone packages for example.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Shlomo Kabaz ECItelecom [mailto:[email-masked]]
> > Sent: Tuesday, October 10, 2000 5:21 AM
> > To: [email-masked]
> > Subject: physical and ephemeral terminations
> >
> >
> > Hi , all !
> >
> > Does the physical termination have properties , because in
> > the examples
> > in
> > the Rfc all the
> > properties of the "connection" is given in the ephemeral
> > termination and
> > the elements that are given to
> > physical is events and signals .
> >
> > Thanks , Shlomo
> >
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Nov 2000 04:25:07 +1100

I think that what we currently have should stay. CHOOSE can be both
based on the termination ID and/or characteristics listed in the
command. It very much depends on how you want to set up your termination
ID structure. The MGC may not know or care what termination ID he wants.
All it wants is a termination ID with certain properties. This to me
sounds like a perfectly reasonable scenario. The MGC wants a termination
from a certain range, it also wants property x sounds reasonable to me.
By changing anything here it seems to me that we would be removing a
moderate amount of functionality. A little more than editorial.

Christian